dolfin team mailing list archive

["Alessio Quaglino" <alessio@xxxxxx>]

> 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)
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.

Alessio


> /Anders
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>