← Back to team overview

dolfin team mailing list archive

Re: [PETSC #13286] Make pcimpl.h a public API and [PETSC #13287] Re: installation of DOLFIN 0.5.7 on Debia

 

On Tue, Jul 05, 2005 at 01:23:24PM -0500, Barry Smith wrote:
> 
>   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 :-).

Yes, I understand. But I think you may overestimate the desire of a
user to use PETSc makefiles to compile their programs. I want to use
my own system of choice (which happens to be GNU autotools for now)
and compile against PETSc. Including makefiles and rules from PETSc
into my own configuration scripts and makefiles will just make a mess.

A user just needs a simple way to get the cflags and libs. It
shouldn't be hard to generate this script at compile-time (we do it in
DOLFIN, see src/config/). Many large projects like GTK use this:

galerkin:~> gtk-config 
Usage: gtk-config [OPTIONS] [LIBRARIES]
Options:
        [--prefix[=DIR]]
        [--exec-prefix[=DIR]]
        [--version]
        [--libs]
        [--cflags]
Libraries:
        gtk
        gthread

galerkin:~> gtk-config --cflags
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include

galerkin:~> gtk-config --libs
-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib
-ldl -lXi -lXext -lX11 -lm

This script could provide different options for compiling against an
installed version of PETSc (in $prefix/include, $prefix/lib and then
PETSC_DIR should not be needed) or to compile against the PETSc
source tree. DOLFIN has options for this:

galerkin:~> dolfin-config 
Usage: dolfin-config [options]

       --version  (get version number)
       --cflags   (get compiler flags)
       --libs     (get libraries for linking)
       --compiler (get compiler)

       --cflags_dolfin (for demo programs in the source tree)
       --libs_dolfin   (for demo programs in the source tree)

> 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?

It doesn't matter to me as long as we can access it.

>     Barry
> 
>   Of course, this does not resolve the neverending problem of not being 
> able to debug installed code :-(

I think the majority of users would rather send an email to the
maintainers than debugging PETSc themselves, so I don't think it's a
big issue. Someone who knows how to debug can easily download the
source and compile against it.

/Anders

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

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/



Follow ups

References