dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #00719
Re: [PETSC #13286] Make pcimpl.h a public API and [PETSC #13287] Re: installation of DOLFIN 0.5.7 on Debia
These are two related issues, so I have merged them.
I have always been uncomfortable with the "make install" model
with PETSc; as you could guess from our incomplete attempt to
implement it with PETSc :-(.
I've aways wanted to have PETSc users
have the EXACT same experience (debugging, makefiles, rules etc) if they
used a "compiled" version of an "installed" version of PETSc. I never could
see how to do this, so I wrote a simple "make install" to pander to those
who want it :-).
1) If "make getincludedirs" and "make getlinklibs" do not work properly for
installed versions of PETSc that is a bug we need to fix! I can change the
install process to also copy over the top level makefile, but this does not
make sense because having ${INSTALL_DIR}/makefile makes no sense if
${INSTALL_DIR} is something like /usr/local! I could copy it into the bmake
subdirectory BUT then it is inconsistent with a "non installed" built PETSc.
Is there a good solution? Maybe most of what is in makefile should really
be in bmake/makefile?
2) We could keep the XXXXimpl.h files in a subdirectory of include, instead
of "where they belong with each component :-)" or have the "make all" and
"make install" make copies down to a subdirectory of include (I'm inclined to
do the later) so everyone can link against them in the same place.
What do you think? Suggestions?
Barry
Of course, this does not resolve the neverending problem of not being
able to debug installed code :-(
On Mon, 4 Jul 2005, Johan Jansson wrote:
> Hi!
>
> We've implemented a PetSc preconditioner in DOLFIN, but it seems the
> preconditioner implementation API (pcimpl.h) isn't a public API
> (i.e. user code cannot see it). We've solved this by copying pcimpl.h
> into DOLFIN, but this is not a good solution. Could you consider
> making the preconditioner implementation API public?
>
> The reason the preconditioner is implemented in DOLFIN and not in
> PetSc is because the preconditioner depends on DOLFIN. The idea is to
> solve a nonlinear system in a time-stepping method for ODEs by
> Newton's method with a Krylov solver preconditioned with a fixed-point
> solver. The fixed-point solver is part of DOLFIN. There are likely
> other such applications of externally implemented preconditioners.
>
> Thank you,
> Johan
>
>
> On Mon, Jul 04, 2005 at 11:44:47PM -0400, Faheem Mitha wrote:
> >
> >
> > On Mon, 4 Jul 2005, Faheem Mitha wrote:
> >
> > >On Mon, 4 Jul 2005, Anders Logg wrote:
> >
> > >>Look through the PETSc makefile and
> > >>see if you find the target "getincludedirs".
> > >>
> > >>In my petsc-2.2.1/makefile:
> > >>
> > >> include ${PETSC_DIR}/bmake/common/base
> > >
> > >Yes, it's there.
> >
> > Just to clarify, this is in the sources, but not in the installed library.
> > You weren't expecting it to be there, were you?
>
> Yes, I was. DOLFIN needs to figure out where to find PETSc and it then
> uses the getincludedirs flag with make to get the correct flags.
>
> If possible, I would rather do a 'make install' in PETSc like with any
> other library (without needing to set PETSC_DIR to something special),
> but then I don't know how to get compiler flags and link libraries
> correctly. It would be nice to have a petsc-config script (like
> gtk-config, xml2-config, dolfin-config, etc) that spits out the flags.
Follow ups
References