dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Oct 31, 2007 at 08:43:54AM +0100, Alessio Quaglino wrote:
> > On Tue, Oct 30, 2007 at 07:52:00PM +0100, Alessio Quaglino wrote:
> >> > On Wed, Oct 24, 2007 at 04:58:56PM +0200, Alessio Quaglino wrote:
> >> >> > On Sat, Oct 20, 2007 at 01:12:14PM +0200, Alessio Quaglino wrote:
> >> >> >> > On Fri, Oct 12, 2007 at 12:53:50PM +0200, Alessio Quaglino
> >> wrote:
> >> >> >> >> I've compiled dolfin using PETSc. After some work, everything
> >> >> finally
> >> >> >> >> compiles, but there was no way to make those working inside
> >> >> >> PETScVector:
> >> >> >> >>
> >> >> >> >> /// Return value of maximum component of vector
> >> >> >> >> real max() const;
> >> >> >> >>
> >> >> >> >> /// Return value of minimum component of vector
> >> >> >> >> real min() const;
> >> >> >> >
> >> >> >> > What do you mean? Do you need to remove those two in order to
> >> >> compile?
> >> >> >>
> >> >> >> Thank you for the reply.
> >> >> >> Yes, I needed to remove them in order to compile.
> >> >> >>
> >> >> >>
> >> >> >> >> I thought you wanted to know it, just in case you want to dump
> >> >> them
> >> >> >> (max
> >> >> >> >> is just the linf norm so it's not even necessary).
> >> >> >> >
> >> >> >> > Yes, I think they can be removed. Any objections?
> >> >> >> >
> >> >> >> > (Or we should add them to the GenericMatrix interface.)
> >> >> >> >
> >> >> >> >> I have also another question: why is uBlas necessary for
> >> >> compiling?
> >> >> >> >> Wouldn'it be (at least in theory) possible to use just PETSc?
> >> >> >> >
> >> >> >> > It would break the ODE solvers since they assume the uBlas
> >> >> interface.
> >> >> >> > Since uBlas is fairly standard, part of boost, just a collection
> >> of
> >> >> >> > header files and is part of Debian, it's generally not a problem
> >> to
> >> >> >> > rely on uBlas.
> >> >> >>
> >> >> >> Ok thanks I was just thinking how to speedup the "code generation"
> >> >> phase
> >> >> >> (after compiling and linking) in Visual Studio which takes about 5
> >> >> >> minutes. Compiling is quite fast because I'm using dolfin as a
> >> static
> >> >> >> library, but then the code generation is bloody slow (the full
> >> dolfin
> >> >> >> .lib
> >> >> >> was about 120 mb which became 90mb after some "cutting", but it
> >> seems
> >> >> >> that
> >> >> >> the rest is sort of linked together). I've been told that boost
> >> could
> >> >> be
> >> >> >> a
> >> >> >> cause, so I just considered to experiment.
> >> >> >>
> >> >> >> Alessio
> >> >> >
> >> >> > Sounds very strange. What "code generation phase" do you mean?
> >> >> > Compiling your program, or generating code with FFC?
> >> >> >
> >> >> > I'm not sure what your compiler does, but I'm looking a
> >> libdolfin.so
> >> >> > which weights in at 15 MB. Stripped from comments etc (command
> >> strip),
> >> >> > it's down to 3.2 MB
> >> >>
> >> >> Usually when I compile the solver with Visual Studio there are three
> >> >> phases: compiling, linking and generation of code (I think Visual
> >> Studio
> >> >> means the generation of the executable). The first two are pretty
> >> fast
> >> >> (faster than in linux), but the third one is extremely slow, probably
> >> >> because the static library libdolfin.lib I generate putting all the
> >> >> dolfin
> >> >> source files in a project and compiling is about 120 MB.
> >> >>
> >> >> Alessio
> >> >
> >> > Sounds like a lot of fun... How about using gcc?
> >>
> >> I wish I could but (unfortunately) I must use the Windows compiler
> >> which,
> >> however, is much faster in pure compiling and produces slightly more
> >> optimized code.
> >>
> >> By the way, I've seen that you modified the PETScMatrix mat() function
> >> but
> >> it looks like still "const". As I said, though it compiles with the
> >> "const" definition, wouldn't it be better to leave the user the
> >> possibility to use all the functions that PETSc has available and not
> >> only
> >> those implemented in dolfin?
> >>
> >> Alessio
> >
> > There is no such limitation. The user is free to use any function
> > available in PETSc. For example, try the following:
> >
> >   PETScMatrix A(2, 2);
> >
> >   int rows[2] = {0, 1};
> >   int cols[2] = {0, 1};
> >   double block[4] = {1.0, 2.0, 3.0, 4.0};
> >
> >   MatSetValues(A.mat(), 2, rows, 2, cols, block, INSERT_VALUES);
> >   MatAssemblyBegin(A.mat(), MAT_FINAL_ASSEMBLY);
> >   MatAssemblyEnd(A.mat(), MAT_FINAL_ASSEMBLY);
> >
> >   A.disp();
> >
> > You should get the following output:
> >
> >   row 0: (0, 1)  (1, 2)
> >   row 1: (0, 3)  (1, 4)
> 
> For many of PETSc functions the required mat is of the type Mat* and that
> won't work, for example in:
> 
> MatMatMult(Mat A,Mat B,MatReuse scall,PetscReal fill,Mat *C)

You mean the Mat *C argument? This is an object that will be created
by PETSc so you shouldn't send in something like A.mat() (or &A.mat())
for that argument.

> MatLUFactorSymbolic(Mat mat,IS row,IS col,MatFactorInfo *info,Mat *fact)
> or at least my compiler refuses to pass a reference of a constant object.

Calling PETScMatrix::mat() returns a PETSc Mat object which does not
have any const qualifier on it so you should be able to use it in
whatever way you like.

/Anders