July 2011 - petsc-dev - mailman3.cels.anl.gov

programming with PETSc options
by Barry Smith 09 Jul '11

09 Jul '11

Jungho and I have implemented a simple geometric multigrid method for a saddle point problem variational inequalities that works (so far) surprisingly well using the PETSc options programming language. Because it is a fun example of programming a compossible hierarchical nested solver I thought I would share the command line. This is essentially multigrid on the entire matrix with a Schur complement smoother on each level. Changing the options a bit would give you a Schur complement solver on the entire matrix with multigrid on the A00 block. ./ex55 -ksp_type fgmres -pc_type mg -mg_levels_ksp_type fgmres -mg_levels_pc_type fieldsplit -mg_levels_pc_fieldsplit_detect_saddle_point -mg_levels_pc_fieldsplit_type schur -mg_levels_pc_fieldsplit_factorization_type full -mg_levels_pc_fieldsplit_schur_precondition user -mg_levels_fieldsplit_1_ksp_type gmres -mg_levels_fieldsplit_1_pc_type none -mg_levels_fieldsplit_0_ksp_type preonly -mg_levels_fieldsplit_0_pc_type sor -mg_levels_fieldsplit_0_pc_sor_forward -snes_vi_monitor -ksp_monitor_true_residual -pc_mg_levels 5 -pc_mg_galerkin -mg_levels_ksp_monitor -mg_levels_fieldsplit_ksp_monitor -mg_levels_ksp_max_it 2 -mg_levels_fieldsplit_ksp_max_it 5 -snes_atol 1.e-11 -mg_coarse_ksp_type preonly -mg_coarse_pc_type svd -da_grid_x 65 -da_grid_y 65 Run flexible GMRES with 5 levels of multigrid as the preconditioner -------------- ./ex55 -ksp_type fgmres -pc_type mg -pc_mg_levels 5 -da_grid_x 65 -da_grid_y 65 Use the Galerkin process to compute the coarse grid operators ---------------- -pc_mg_galerkin Use SVD as the coarse grid saddle point solver --------------- -mg_coarse_ksp_type preonly -mg_coarse_pc_type svd Use 2 iterations of flexible GMRES with a Schur complement preconditioner as the smoother --------------- -mg_levels_ksp_type fgmres -mg_levels_ksp_max_it 2 -mg_levels_pc_type fieldsplit -mg_levels_pc_fieldsplit_detect_saddle_point -mg_levels_pc_fieldsplit_type schur -mg_levels_pc_fieldsplit_factorization_type full -mg_levels_pc_fieldsplit_schur_precondition diag Iterate on the Shur complement with GMRES with no preconditioner for 5 iterations in the Schur complement smoother -------------- -mg_levels_fieldsplit_1_ksp_type gmres -mg_levels_fieldsplit_1_pc_type none -mg_levels_fieldsplit_ksp_max_it 5 Approximate the action of the Shur complement by using only the lower diagonal part of A00 -------------- -mg_levels_fieldsplit_0_ksp_type preonly -mg_levels_fieldsplit_0_pc_type sor -mg_levels_fieldsplit_0_pc_sor_forward The bulk of the computation is just forward Gauss-Seidel on the non-saddle point part of the matrix. (I've removed the monitoring of the inner linear iterations) 0 SNES VI Function norm 3.976439267245e-05 Active constraints 2315 0 KSP unpreconditioned resid norm 3.976439267245e-05 true resid norm 3.976439267245e-05 ||r(i)||/||b|| 1.000000000000e+00 1 KSP unpreconditioned resid norm 3.543930653675e-05 true resid norm 3.543930653676e-05 ||r(i)||/||b|| 8.912321842479e-01 2 KSP unpreconditioned resid norm 4.005676188871e-08 true resid norm 4.005676188723e-08 ||r(i)||/||b|| 1.007352538166e-03 3 KSP unpreconditioned resid norm 1.073296617426e-10 true resid norm 1.073296621498e-10 ||r(i)||/||b|| 2.699139982696e-06 1 SNES VI Function norm 8.882771573091e-03 Active constraints 2201 0 KSP unpreconditioned resid norm 8.882771573091e-03 true resid norm 8.882771573091e-03 ||r(i)||/||b|| 1.000000000000e+00 1 KSP unpreconditioned resid norm 2.591449737029e-07 true resid norm 2.591449737028e-07 ||r(i)||/||b|| 2.917388695301e-05 2 KSP unpreconditioned resid norm 6.018436991709e-10 true resid norm 6.018436991512e-10 ||r(i)||/||b|| 6.775404435417e-08 2 SNES VI Function norm 6.604821607805e-10 Active constraints 2203 0 KSP unpreconditioned resid norm 6.604820670139e-10 true resid norm 6.604820670139e-10 ||r(i)||/||b|| 1.000000000000e+00 1 KSP unpreconditioned resid norm 5.516796916907e-10 true resid norm 5.516796916907e-10 ||r(i)||/||b|| 8.352682370089e-01 2 KSP unpreconditioned resid norm 2.370052538357e-12 true resid norm 2.370052538361e-12 ||r(i)||/||b|| 3.588367734308e-03 3 KSP unpreconditioned resid norm 4.953732708209e-14 true resid norm 4.953732708254e-14 ||r(i)||/||b|| 7.500177454704e-05 4 KSP unpreconditioned resid norm 2.777240109831e-16 true resid norm 2.777239994389e-16 ||r(i)||/||b|| 4.204868130554e-07 3 SNES VI Function norm 3.519585974269e-13 Active constraints 2204 Eventually we'll program all our solvers with command line options :-) Barry

1 0

Re: [petsc-dev] new configuration/compile system for PETSc
by Barry Smith 09 Jul '11

09 Jul '11

Ok, here's the current list of requirements. What is missing? Requirements: X 1) Portability to Windows, Cygwin, Unix (all versions) 2) Compatible with GUI development systems (Xcode, Eclipse, Emacs, ...) 3) Able to run parallel configures and builds (on shared memory system enough?, distcc?) 4) Able to work with batch systems 5) Able to handle dependencies between packages (given dependencies between packages builds everything in the correct order) 6) Able to utilize clang and similar systems 7) Works seamlessly with GNU autoconf, Cmake, pkconfig packages (that is will build these packages automatically and maybe generate them) 8) Can download and install packages by given URL 9) Easy to add configurations for packages such as SuperLU, etc that have no decent configuration x 10) Can test for available functionalities (include files, etc) X 11) Easy to add new types of compilers, new tests 12) Does dependency analysis and rebuilds only what needs to be rebuilt 13) Able to manage test suites 14) Compatible with and able to use revision control systems 15) Completely command-line controlled but also with a GUI frontend that gives one full control as well 16) Able to build for bizarre-assed systems like the iPAD and GPUs. 17) Able to manage the concept of abstract packages such as MPI and BLAS/LAPACK and particular implementations 18) Able to handle already installed packages and detect if that package uses something incompatable with other packages: for example HDF5 installed with OpenMPI and someone building other packages with MPICH. 19) Able to manage several different compilers of the same type (for example 2 C compilers) being used for different packages. 20) Incrementable builds, that is more packages can be installed later based on packages already installed. Say add SLEPc later. X - does, x - does some On Jul 9, 2011, at 7:45 PM, Dmitry Karpeev wrote: > Observe that PETSc's configure deals with the problem of consistently > configuring MULTIPLE > packages, while most tools I have heard of typically deal with a > SINGLE package. That's a > qualitative difference, in my opinion. > > Separately, I would suggest having the new build system allow the user > to install PETSc in one > go. Something like 'cll install --with-clanguage=c++ ...', because > it's rare for users to stop after > configuring, and then end up executing an easily automatable sequence of steps: > configure --with-clanguage=c++ ... > make PETSC_DIR= ... all > make PETSC_DIR= ... PETSC_ARCH=... test > > Of course, we should provide intermediate stages as well -- 'cll > configure' -- etc. > In particular, if cll were able to configure "arbitrary" collections > of packages, it may be desirable > to leave the "top" package configured, but not built, as it has to be > built repeatedly (as part of > a development cycle) using make or cmake, etc. > > Dmitry. > > On Sat, Jul 9, 2011 at 7:37 PM, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: >> On Sat, Jul 9, 2011 at 7:18 PM, Harald Pfeiffer >> <pfeiffer(a)cita.utoronto.ca> wrote: >>> We happen to use Petsc with our own makefiles. PETSc is compiled entirely >>> separately (or we use system-provided PETSc-modules). We then manually set >>> the appropriate include- and library-paths in our makefiles, for example: >>> >>> PETSC_INCLUDE = -I$(PETSC_DIR)/include -I$(PETSC_DIR)/$(PETSC_ARCH)/include >>> PETSC_LIB = -L$(PETSC_DIR)/$(PETSC_ARCH)/lib -lpetsc -lX11 >>> ... >>> other stuff here >>> ... >>> ARCH_INCLUDE = $(PETSC_INCLUDE) ... >>> ARCH_LIB_PARALLEL = $(HDF_LIB) $(FFTW_LIB) $(PETSC_LIB) .... >>> >>> >>> Not elegant, but has been working like a charm for the last 12 years. >> >> I'm not saying it can't be made to work. >> I'm saying it might not be trivial for someone just starting to use >> PETSc and not even necessarily >> that familiar with make: there are a lot of potential users like that. >> And even for more sophisticated >> users it might take a while to work out the kinks. >> >> Dmitry. >> >>> >>> >>> Harald >>> >>> >>> >>> >>> >>> >>> On 7/10/11 1:02 AM, Dmitry Karpeev wrote: >>>> >>>> On Sat, Jul 9, 2011 at 6:42 PM, Jed Brown<jedbrown(a)mcs.anl.gov> wrote: >>>>> >>>>> On Sat, Jul 9, 2011 at 18:30, Dmitry Karpeev<karpeev(a)mcs.anl.gov> wrote: >>>>>> >>>>>> If a user could write a >>>>>> simple foo.py that configured/built their >>>>>> favorite package with PETSc as a dependency, they could then proceed >>>>>> to modify the FOO code and jack >>>>>> PETSc into it. >>>>> >>>>> But this just a different form of asking them to adopt our build system, >>>>> except that makefiles are a de-facto standard and our system won't be >>>>> familiar to anyone. Any system has to be easily usable from other systems >>>>> (at least makefiles, automake, and cmake). >>>> >>>> Yes, but there is also a practical problem: an engineer or a scientist, >>>> not >>>> intimately familiar with automake, cmake, etc., has taken the effort >>>> to understand >>>> PETSc so that our linear solvers can be substituted for FOO's. How can we >>>> make it easier for these people to insert PETSc into their code? Here >>>> I only mean >>>> the build process. Maybe making them write foo.py is not the right >>>> approach, >>>> but we should have a usable approach (and, maybe, an example of doing it). >>>> >>>> In particular, is it sufficient to export linklibs, or do we also need >>>> to export the >>>> compiler (e.g., to ensure consistent Fortrant name mangling)? There are >>>> a good number of Fortran users that want to use PETSc too. >>>> >>>> Dmitry. >>> >>> -- >>> Harald Pfeiffer >>> Assistant Professor >>> Cdn. Institute for Theoretical Astrophysics >>> University of Toronto >>> pfeiffer(a)cita.utoronto.ca >>> Tel. ++1 416-978-8497 >>> >>> >>

1 0

Re: [petsc-dev] new configuration/compile system for PETSc
by Dmitry Karpeev 09 Jul '11

09 Jul '11

Observe that PETSc's configure deals with the problem of consistently configuring MULTIPLE packages, while most tools I have heard of typically deal with a SINGLE package. That's a qualitative difference, in my opinion. Separately, I would suggest having the new build system allow the user to install PETSc in one go. Something like 'cll install --with-clanguage=c++ ...', because it's rare for users to stop after configuring, and then end up executing an easily automatable sequence of steps: configure --with-clanguage=c++ ... make PETSC_DIR= ... all make PETSC_DIR= ... PETSC_ARCH=... test Of course, we should provide intermediate stages as well -- 'cll configure' -- etc. In particular, if cll were able to configure "arbitrary" collections of packages, it may be desirable to leave the "top" package configured, but not built, as it has to be built repeatedly (as part of a development cycle) using make or cmake, etc. Dmitry. On Sat, Jul 9, 2011 at 7:37 PM, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > On Sat, Jul 9, 2011 at 7:18 PM, Harald Pfeiffer > <pfeiffer(a)cita.utoronto.ca> wrote: >> We happen to use Petsc with our own makefiles. PETSc is compiled entirely >> separately (or we use system-provided PETSc-modules). We then manually set >> the appropriate include- and library-paths in our makefiles, for example: >> >> PETSC_INCLUDE = -I$(PETSC_DIR)/include -I$(PETSC_DIR)/$(PETSC_ARCH)/include >> PETSC_LIB = -L$(PETSC_DIR)/$(PETSC_ARCH)/lib -lpetsc -lX11 >> ... >> other stuff here >> ... >> ARCH_INCLUDE = $(PETSC_INCLUDE) ... >> ARCH_LIB_PARALLEL = $(HDF_LIB) $(FFTW_LIB) $(PETSC_LIB) .... >> >> >> Not elegant, but has been working like a charm for the last 12 years. > > I'm not saying it can't be made to work. > I'm saying it might not be trivial for someone just starting to use > PETSc and not even necessarily > that familiar with make: there are a lot of potential users like that. > And even for more sophisticated > users it might take a while to work out the kinks. > > Dmitry. > >> >> >> Harald >> >> >> >> >> >> >> On 7/10/11 1:02 AM, Dmitry Karpeev wrote: >>> >>> On Sat, Jul 9, 2011 at 6:42 PM, Jed Brown<jedbrown(a)mcs.anl.gov> wrote: >>>> >>>> On Sat, Jul 9, 2011 at 18:30, Dmitry Karpeev<karpeev(a)mcs.anl.gov> wrote: >>>>> >>>>> If a user could write a >>>>> simple foo.py that configured/built their >>>>> favorite package with PETSc as a dependency, they could then proceed >>>>> to modify the FOO code and jack >>>>> PETSc into it. >>>> >>>> But this just a different form of asking them to adopt our build system, >>>> except that makefiles are a de-facto standard and our system won't be >>>> familiar to anyone. Any system has to be easily usable from other systems >>>> (at least makefiles, automake, and cmake). >>> >>> Yes, but there is also a practical problem: an engineer or a scientist, >>> not >>> intimately familiar with automake, cmake, etc., has taken the effort >>> to understand >>> PETSc so that our linear solvers can be substituted for FOO's. How can we >>> make it easier for these people to insert PETSc into their code? Here >>> I only mean >>> the build process. Maybe making them write foo.py is not the right >>> approach, >>> but we should have a usable approach (and, maybe, an example of doing it). >>> >>> In particular, is it sufficient to export linklibs, or do we also need >>> to export the >>> compiler (e.g., to ensure consistent Fortrant name mangling)? There are >>> a good number of Fortran users that want to use PETSc too. >>> >>> Dmitry. >> >> -- >> Harald Pfeiffer >> Assistant Professor >> Cdn. Institute for Theoretical Astrophysics >> University of Toronto >> pfeiffer(a)cita.utoronto.ca >> Tel. ++1 416-978-8497 >> >> >

1 0

Re: [petsc-dev] new configuration/compile system for PETSc
by Dmitry Karpeev 09 Jul '11

09 Jul '11

On Sat, Jul 9, 2011 at 7:18 PM, Harald Pfeiffer <pfeiffer(a)cita.utoronto.ca> wrote: > We happen to use Petsc with our own makefiles. PETSc is compiled entirely > separately (or we use system-provided PETSc-modules). We then manually set > the appropriate include- and library-paths in our makefiles, for example: > > PETSC_INCLUDE = -I$(PETSC_DIR)/include -I$(PETSC_DIR)/$(PETSC_ARCH)/include > PETSC_LIB = -L$(PETSC_DIR)/$(PETSC_ARCH)/lib -lpetsc -lX11 > ... > other stuff here > ... > ARCH_INCLUDE = $(PETSC_INCLUDE) ... > ARCH_LIB_PARALLEL = $(HDF_LIB) $(FFTW_LIB) $(PETSC_LIB) .... > > > Not elegant, but has been working like a charm for the last 12 years. I'm not saying it can't be made to work. I'm saying it might not be trivial for someone just starting to use PETSc and not even necessarily that familiar with make: there are a lot of potential users like that. And even for more sophisticated users it might take a while to work out the kinks. Dmitry. > > > Harald > > > > > > > On 7/10/11 1:02 AM, Dmitry Karpeev wrote: >> >> On Sat, Jul 9, 2011 at 6:42 PM, Jed Brown<jedbrown(a)mcs.anl.gov> wrote: >>> >>> On Sat, Jul 9, 2011 at 18:30, Dmitry Karpeev<karpeev(a)mcs.anl.gov> wrote: >>>> >>>> If a user could write a >>>> simple foo.py that configured/built their >>>> favorite package with PETSc as a dependency, they could then proceed >>>> to modify the FOO code and jack >>>> PETSc into it. >>> >>> But this just a different form of asking them to adopt our build system, >>> except that makefiles are a de-facto standard and our system won't be >>> familiar to anyone. Any system has to be easily usable from other systems >>> (at least makefiles, automake, and cmake). >> >> Yes, but there is also a practical problem: an engineer or a scientist, >> not >> intimately familiar with automake, cmake, etc., has taken the effort >> to understand >> PETSc so that our linear solvers can be substituted for FOO's. How can we >> make it easier for these people to insert PETSc into their code? Here >> I only mean >> the build process. Maybe making them write foo.py is not the right >> approach, >> but we should have a usable approach (and, maybe, an example of doing it). >> >> In particular, is it sufficient to export linklibs, or do we also need >> to export the >> compiler (e.g., to ensure consistent Fortrant name mangling)? There are >> a good number of Fortran users that want to use PETSc too. >> >> Dmitry. > > -- > Harald Pfeiffer > Assistant Professor > Cdn. Institute for Theoretical Astrophysics > University of Toronto > pfeiffer(a)cita.utoronto.ca > Tel. ++1 416-978-8497 > >

1 0

Re: [petsc-dev] new configuration/compile system for PETSc
by Harald Pfeiffer 09 Jul '11

09 Jul '11

We happen to use Petsc with our own makefiles. PETSc is compiled entirely separately (or we use system-provided PETSc-modules). We then manually set the appropriate include- and library-paths in our makefiles, for example: PETSC_INCLUDE = -I$(PETSC_DIR)/include -I$(PETSC_DIR)/$(PETSC_ARCH)/include PETSC_LIB = -L$(PETSC_DIR)/$(PETSC_ARCH)/lib -lpetsc -lX11 ... other stuff here ... ARCH_INCLUDE = $(PETSC_INCLUDE) ... ARCH_LIB_PARALLEL = $(HDF_LIB) $(FFTW_LIB) $(PETSC_LIB) .... Not elegant, but has been working like a charm for the last 12 years. Harald On 7/10/11 1:02 AM, Dmitry Karpeev wrote: > On Sat, Jul 9, 2011 at 6:42 PM, Jed Brown<jedbrown(a)mcs.anl.gov> wrote: >> On Sat, Jul 9, 2011 at 18:30, Dmitry Karpeev<karpeev(a)mcs.anl.gov> wrote: >>> If a user could write a >>> simple foo.py that configured/built their >>> favorite package with PETSc as a dependency, they could then proceed >>> to modify the FOO code and jack >>> PETSc into it. >> But this just a different form of asking them to adopt our build system, >> except that makefiles are a de-facto standard and our system won't be >> familiar to anyone. Any system has to be easily usable from other systems >> (at least makefiles, automake, and cmake). > Yes, but there is also a practical problem: an engineer or a scientist, not > intimately familiar with automake, cmake, etc., has taken the effort > to understand > PETSc so that our linear solvers can be substituted for FOO's. How can we > make it easier for these people to insert PETSc into their code? Here > I only mean > the build process. Maybe making them write foo.py is not the right approach, > but we should have a usable approach (and, maybe, an example of doing it). > > In particular, is it sufficient to export linklibs, or do we also need > to export the > compiler (e.g., to ensure consistent Fortrant name mangling)? There are > a good number of Fortran users that want to use PETSc too. > > Dmitry. -- Harald Pfeiffer Assistant Professor Cdn. Institute for Theoretical Astrophysics University of Toronto pfeiffer(a)cita.utoronto.ca Tel. ++1 416-978-8497

1 0

Re: [petsc-dev] new configuration/compile system for PETSc
by Dmitry Karpeev 09 Jul '11

09 Jul '11

On Sat, Jul 9, 2011 at 6:42 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Sat, Jul 9, 2011 at 18:30, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: >> >> If a user could write a >> simple foo.py that configured/built their >> favorite package with PETSc as a dependency, they could then proceed >> to modify the FOO code and jack >> PETSc into it. > > But this just a different form of asking them to adopt our build system, > except that makefiles are a de-facto standard and our system won't be > familiar to anyone. Any system has to be easily usable from other systems > (at least makefiles, automake, and cmake). Yes, but there is also a practical problem: an engineer or a scientist, not intimately familiar with automake, cmake, etc., has taken the effort to understand PETSc so that our linear solvers can be substituted for FOO's. How can we make it easier for these people to insert PETSc into their code? Here I only mean the build process. Maybe making them write foo.py is not the right approach, but we should have a usable approach (and, maybe, an example of doing it). In particular, is it sufficient to export linklibs, or do we also need to export the compiler (e.g., to ensure consistent Fortrant name mangling)? There are a good number of Fortran users that want to use PETSc too. Dmitry.

1 0

Re: [petsc-dev] new configuration/compile system for PETSc
by Jed Brown 09 Jul '11

09 Jul '11

On Sat, Jul 9, 2011 at 18:30, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > If a user could write a > simple foo.py that configured/built their > favorite package with PETSc as a dependency, they could then proceed > to modify the FOO code and jack > PETSc into it. > But this just a different form of asking them to adopt our build system, except that makefiles are a de-facto standard and our system won't be familiar to anyone. Any system has to be easily usable from other systems (at least makefiles, automake, and cmake).

1 0

Re: [petsc-dev] new configuration/compile system for PETSc
by Dmitry Karpeev 09 Jul '11

09 Jul '11

On Sat, Jul 9, 2011 at 6:13 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Sat, Jul 9, 2011 at 18:00, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: >> >> I frequently get this question: I have a code "blah", which has its >> own build system (e.g., wmake), and I want to use PETSc solvers in it. >> How can I build the two together? The usual answer I give that they >> either have to (a) build their application using our >> makefiles, or (b) include $PETSC_DIR/conf/variables, etc. > > These are both makefile-based solutions, That's right. And that's my point: what we offer now for incorporating PETSc into other codes is somewhat limited. > and "make getlinklibs" is a better > ways to snarf the variables. But only marginally. > We could easily write a pkgconfig file for > PETSc. Some people would like that, but pkgconfig doesn't really care about > supporting multiple installs (different PETSC_ARCH). As I've suggested > before, I think we should have a pure Python script that provides the > information in a machine-readable way (listing library paths without > "-Wl,-rpath," flags that may need to be adjusted if the user is not linking > exactly the same way that PETSc was, correctly handle shared versus static > linking, etc). I think another way would be to simplify the writing of "configure modules" for libraries built using some set of standard tools (e.g., GNU packages built with configure/make, etc). We already configure these packages internally (e.g., mpich). If a user could write a simple foo.py that configured/built their favorite package with PETSc as a dependency, they could then proceed to modify the FOO code and jack PETSc into it. At the same time they couldn't have to parse the output of make getlinklibs, etc. Dmitry.

1 0

Re: [petsc-dev] new configuration/compile system for PETSc
by Jed Brown 09 Jul '11

09 Jul '11

On Sat, Jul 9, 2011 at 18:00, Dmitry Karpeev <karpeev(a)mcs.anl.gov> wrote: > I frequently get this question: I have a code "blah", which has its > own build system (e.g., wmake), and I want to use PETSc solvers in it. > How can I build the two together? The usual answer I give that they > either have to (a) build their application using our > makefiles, or (b) include $PETSC_DIR/conf/variables, etc. > These are both makefile-based solutions, and "make getlinklibs" is a better ways to snarf the variables. We could easily write a pkgconfig file for PETSc. Some people would like that, but pkgconfig doesn't really care about supporting multiple installs (different PETSC_ARCH). As I've suggested before, I think we should have a pure Python script that provides the information in a machine-readable way (listing library paths without "-Wl,-rpath," flags that may need to be adjusted if the user is not linking exactly the same way that PETSc was, correctly handle shared versus static linking, etc).

1 0

Re: [petsc-dev] new configuration/compile system for PETSc
by Dmitry Karpeev 09 Jul '11

09 Jul '11

On Sat, Jul 9, 2011 at 11:47 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Jul 9, 2011, at 10:41 AM, Jed Brown wrote: > >> On Fri, Jul 8, 2011 at 16:48, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> X 1) Portability to Windows, Cygwin, Unix (all versions) >> 2) Compatible with GUI development systems (Xcode, Eclipse, Emacs, ...) >> >> We can support the systems that we use, but I fear that this task will become endless. > > Sadly we only use Emacs and don't even support that (besides crappy etags) very well. > >> >> 3) Able to run parallel configures and builds (on shared memory system enough?) >> >> Probably, distcc can also be used if distributed-memory is needed. > > I think we can steal ideas from distcc but I'd like to keep a pure Python environment. > >> >> 5) Able to handle dependencies between packages (given dependencies between packages builds everything in the correct order) >> >> This is important and also quite tricky, especially when dependencies vary based on configuration options. >> >> I think we need to be more precise about how to handle packages that depend on PETSc relative to packages that PETSc (optionally) depends on. And how central would PETSc be in this new package management system? > > PETSc should be no different than any other package. It has dependencies on other packages and other packages have dependencies on PETSc (SLEPc, MeshLib,...). In theory BuildSystem is independent of PETSc but in practice our build infra-structure treats PETSc as a first among equals and that should be changed. I frequently get this question: I have a code "blah", which has its own build system (e.g., wmake), and I want to use PETSc solvers in it. How can I build the two together? The usual answer I give that they either have to (a) build their application using our makefiles, or (b) include $PETSC_DIR/conf/variables, etc. This problem stems from the fact that in the dependency graph we always treat PETSc as the source and topologically sort from it. Then we configure/build the other packages using their own crappy configure/make systems by feeding them a controlled set of options. In principle, we could allow PETSc to be an "interior vertex" so that it is built before some other packages. Dmitry. > > Barry > > >

1 0