dolfin team mailing list archive

[Matthew Knepley <knepley@xxxxxxxxxxx>]

Anders Logg <logg@xxxxxxxxx> writes:

> On Tue, Jul 05, 2005 at 02:08:19PM -0500, Matthew Knepley wrote:
>> Anders Logg <logg@xxxxxxxxx> writes:
>> 
>>        I think this is a really bad model. First, the examples below assume
>> a single build, whereas PETSc can have many builds with vastly different
>> flags. How would petsc-config distinguish these? Whatever the mechanism, it
>> would still be new since no standard exists.
>
> Couldn't you just add an extra flag or two? Should be possible since
> there is a finite set of ways to compile PETSc.

  I guess this is where we have aesthetic differences. You see no problem with
introducing something new into the model you like (petsc-config), but everything wrong with
the equally simple model we like (make). We are the same in this. I think if the
package maintainer wants to include petsc-config, that is fine with me.

>>        Moreover, these options become a single text string with all
>> semantics stripped out. All this information is in the pickled configure
>> along with the smenatics in bmake/$PETSC_ARCH/RDict.db. It would be
>> possible to get all the information from Python that you get from the
>> make system. No one does it yet, but I like this model. Eventually, our
>> build will be all Python since make is notoriously limited and not portable.
>
> But all I need to compile against PETSc is a single text string and I get
> the same string every time I do 'make getincludedirs'.

  No, you get a different string depending on the value of PETSC_ARCH.

>>       However, we have compromised and provided a simple way to get the
>> flags. Does it matter whether the script is called makefile or petsc-config?
>> You would still need all the bmake stuff to get the right answer anyway. Right?
>
> It matters since if it were called petsc-config I wouldn't have had to
> ask you how to do it.

  make <option>   <-->    petsc-config <option>

and you would will need all the bmake directories.

       Matt

> /Anders
>
>>     Matt
>> 
>> > 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/
>
>
>

-- 
"Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness