← Back to team overview

dolfin team mailing list archive

Re: PETScVector

 

> 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


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




Follow ups

References