dolfin team mailing list archive

[Faheem Mitha <faheem@xxxxxxxxxxxxx>]

Hi Johan,

So you use Debian as well?

On Sun, 17 Jul 2005, Johan Jansson wrote:

> On Sat, Jul 16, 2005 at 04:53:49PM -0400, Faheem Mitha wrote:

> I discovered I had old PETSc libraries in /usr/lib. When I removed
> them everything worked like it should. Please check if you have the
> same situation. The linker must select those libraries first, perhaps
> because "-L /usr/lib" occurs before the correct PETSc path.

I've traced the problem to the presence of lam4-dev. If this is installed, 
the compilation of all the demo examples I've tried go straight to hell. 
See if you can reproduce this. I've verified this on another machine.

Without lam4-dev installed, the demos I've tried compile and run Ok.

I'm not sure what to do about this, but clearly it qualifies as a problem. 
Please advise.

> > These packages still cannot be used to successfully compile the demos 
> > in src/demos. The problem is that not all the header file are installed 
> > by make install.

> > I am currently testing this, and see at the moment that (at least)
> > dolfin_navierstokes.h, dolfin/NSEMomentum.h, dolfin/NSEContinuity.h,
> > dolfin/NSESolver.h are not installed.
>
> This module has been disabled (because it doesn't work yet). So it has
> been commented out from for example src/modules/Makefile.am, which is
> why it doesn't get installed. Your fix is probably ok for now, in
> future releases we will make sure that the makefiles are consistent,
> i.e. if the module is disabled it should not be used anywhere. Of
> course the best solution would be if the module worked and could be
> installed :).

I'm not completely sure I follow this. Why is it being used in the compile 
if it is disabled?

> > The following list of build dependencies was generated with the help of
> > pbuilder. Build, wait for failure, add to build-depends. Repeat.
> >
> > debhelper (>= 4.0.0), libxml2-dev, libpetsc, libncurses5-dev, mpich-bin,
> > libmpich1.0-dev, lapack3-dev, refblas3-dev | atlas3-base-dev
> >
> > Note that the configure script does not look for anything after PETSc, as
> > far as I can tell. Adding tests for the other things should be easy.
>
> Apart from debhelper (which I don't understand why it's included),

Debhelper is a Build Depends since the rules files uses it, and so the 
package will not build without it.

> all libraries following libncurses5-dev are dependencies of
> PETSc. So if DOLFIN finds a working PETSc, then they must
> exist. There are no explicit dependencies on those libraries from
> DOLFIN. Shouldn't it be enough then to only check for PETSc?

It is true that the Build-Depends of petsc include these packages. 
However, this is not the same as the runtime dependencies ('Depends' for 
short). I don't see why any of these dev packages should be runtime 
dependencies of PETSc, and they are not currently listed as such.

In other words, the Build-Depends of petsc cannot be guaranteed to be 
available at the build time of dolfin, since there is nothing pulling them 
in (as far as I can see). If I am missing something, please enlighten me.

I repeat, the configure script ought to look for these.

> > Can you specify which parts of DOLFIN require these? I'll hold off
> > packaging these till I've experimented a little bit with DOLFIN.
>
> FFC is a compiler which can generate a C++ header file (which contains
> the implementation as well) from a form (.form) file. For example, the
> file src/modules/poisson/dolfin/Poisson.h has been generated from
> src/modules/poisson/dolfin/Poisson.form . The same holds for the other
> modules. So if one wants to create a new module (i.e. solve a new PDE)
> or modify the existing forms, then FFC is needed. There are some form
> files in src/kernel/fem/dolfin as well for the forms for a mass matrix
> and stiffness matrix.
>
> FIAT is used by FFC to evaluate basis functions, it's not used
> explicitly by DOLFIN and is only needed by FFC.

Ok. I'll hold off on packaging FFC and FIAT till later.

> > > Something for visualization (MATLAB, Octave, OpenDX, GiD, Tecplot or
> > > Paraview/VTK). This is more post run-time.
> >
> > Most of these look proprietary. Perhaps Octave in a suggests?
>
> Yes, definitely. Open Inventor (inventor-clients) should also be a
> suggests since it's used in some visualization scripts (pdeplot.m).

Ok. Should I add inventor-clients and octave to suggests of libdolfin or 
libdolfin-dev? If there is only going to be libdolfin-dev (see below) then 
there is nothing to decide.

> > One (fairly important) question with regard to this. If I link against the
> > DOLFIN static libraries, then should I still require these libraries at
> > runtime? I'd have thought not, but based on preliminary evidence, this
> > does not appear to be the case.

> No, this cannot be the case. When linking, the contents of a static 
> library is included in the executable and no reference to the library is 
> kept. The linking problem must have been because of the old PETSc 
> libraries or something similar. If it isn't, please post the errors you 
> get and let's try to find the problem.

Ok, thanks for the confirmation.

As for the linking problem, see above. The culprit is different versions 
of MPI. I guess I should move the static libraries into libdolfin-dev as 
per Debian policy. So there will be no libdolfin package till shared 
dolfin libraries are generated. Any objections to this?

Ok, just a couple more things.

It appears at least some of the demos do not compile without mpich1.0-dev 
being installed. What should be the status of this? Should it be a 
recommends or a suggests?

libpetsc is too big. Please suggest how its size could be reduced. Also, 
do you have any suggestions on how the runtime and dev libraries could be 
split up?

I also notice that the executables in demo are linking against 
/usr/lib/petsc-2.2.1/lib/libg_c++. Remind me what this is, and why do we 
also need /usr/lib/petsc-2.2.1/lib/libO_c++?

Thanks for your feedback.

                                                                Faheem.