December 2014 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Sean is going to love this
by Barry Smith 28 Dec '14

28 Dec '14

Sean, brew install /homebrew/science/petsc brew install /homebrew/science/petsc --HEAD --with-x11 Is there any reason not to use home-brew for everything now? Should we be working with the homebrew/science guys to work out the rough edges? (Like their hypre build is sequential and they don't pass the MPI compiler wrappers properly to build packages and ... and ...) Barry > On Dec 24, 2014, at 12:22 PM, Sean Farley <sean.michael.farley(a)gmail.com> wrote: > > > Jose E. Roman writes: > >> El 23/12/2014, a las 20:38, Sean Farley escribió: >> >>> 4) Better coordination with dependent packages >>> >>> This item is hard to implement because it's out of the PETSc team's >>> control. For example, packages like SLEPc depend on PETSc but don't have >>> as good of a build system. SLEPc can't be built with a version of SLEPc >>> already installed in the prefix. This is unnecessarily cumbersome for >>> end-users. >> >> SLEPc issues a warning in this case, but does not prevent building. I have removed the warning, since it is no longer necessary. Please report any problems. > > Ah, great! Thanks!

1 0

Re: [petsc-dev] Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing
by Satish Balay 25 Dec '14

25 Dec '14

On Thu, 25 Dec 2014, Matthew Knepley wrote: > On Thu, Dec 25, 2014 at 12:35 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > On Wed, 24 Dec 2014, Matthew Knepley wrote: > > > > > On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > > > > > > Barry Smith <bsmith(a)mcs.anl.gov> writes: > > > > > > > > >> On Dec 24, 2014, at 12:26 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > > > >> > > > > >> In this case, it might be more reliable to compare "cc --version". > > > > > > > > > > Presumably this is trivial with the gnumake stuff? > > > > > > > > It's easy to run it and compare before proceeding with the build. > > > > > > > > > And the mythical petsc-config could do any number of sanity checks > > > > each time it is run. > > > > > > > > It might be desirable to have a > > > > > > > > petsc-config verify CC=cc CFLAGS='-m32 -mcmodel=large' > > > > CXXFLAGS=-std=c++11 ... > > > > > > > > that would check whether the given compiler configuration is > > > > binary-compatible with the way PETSc was built. It should be > > reasonably > > > > fast, but could actually run the compiler. > > > > > > > > > > I of course want these runtime checks. They are the biggest piece missing > > > from the > > > package model. > > > > Hm - most package models [fedora ecosystem or perhaps debian and > > similar] enforce uniform options [compilers, compiler options etc..] > > for all packages in that ecosystem - so such issues don't come up. > > > > And even if petsc were packaged as a 'module' in such a system [say > > cray-petsc] - these issues usually don't come up. I think when > > compiler modules get switched - the petsc libraries (via modules) also > > get switched to the ones compatible with the current compiler.. > > > > This is exactly the point of view I hate because it does not > describe our experience. People want the compilers they want, and > the packages. The best thing to do is check everything at build time > so that incompatibilities are caught early. Sure - different folks (petsc users) have different requirements that we would have to support - but thats a bit different than saying the packaging model has to support this.. [and shound't be a -ve for supporting distribution of PETSc via any of the packaging echo systems - in addition to supporting source distribution] Satish > > Matt > > > > This issue usually come up when user builds PETSc from source with one > > enviornment - but attempts to use it from a different one.. > > > > Satish > > > > > >

1 0

Re: [petsc-dev] Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing
by Matthew Knepley 25 Dec '14

25 Dec '14

On Thu, Dec 25, 2014 at 12:35 PM, Satish Balay <balay(a)mcs.anl.gov> wrote: > On Wed, 24 Dec 2014, Matthew Knepley wrote: > > > On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > > > > Barry Smith <bsmith(a)mcs.anl.gov> writes: > > > > > > >> On Dec 24, 2014, at 12:26 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > > >> > > > >> In this case, it might be more reliable to compare "cc --version". > > > > > > > > Presumably this is trivial with the gnumake stuff? > > > > > > It's easy to run it and compare before proceeding with the build. > > > > > > > And the mythical petsc-config could do any number of sanity checks > > > each time it is run. > > > > > > It might be desirable to have a > > > > > > petsc-config verify CC=cc CFLAGS='-m32 -mcmodel=large' > > > CXXFLAGS=-std=c++11 ... > > > > > > that would check whether the given compiler configuration is > > > binary-compatible with the way PETSc was built. It should be > reasonably > > > fast, but could actually run the compiler. > > > > > > > I of course want these runtime checks. They are the biggest piece missing > > from the > > package model. > > Hm - most package models [fedora ecosystem or perhaps debian and > similar] enforce uniform options [compilers, compiler options etc..] > for all packages in that ecosystem - so such issues don't come up. > > And even if petsc were packaged as a 'module' in such a system [say > cray-petsc] - these issues usually don't come up. I think when > compiler modules get switched - the petsc libraries (via modules) also > get switched to the ones compatible with the current compiler.. > This is exactly the point of view I hate because it does not describe our experience. People want the compilers they want, and the packages. The best thing to do is check everything at build time so that incompatibilities are caught early. Matt > This issue usually come up when user builds PETSc from source with one > enviornment - but attempts to use it from a different one.. > > Satish > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing
by Satish Balay 25 Dec '14

25 Dec '14

On Wed, 24 Dec 2014, Matthew Knepley wrote: > On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > > Barry Smith <bsmith(a)mcs.anl.gov> writes: > > > > >> On Dec 24, 2014, at 12:26 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > >> > > >> In this case, it might be more reliable to compare "cc --version". > > > > > > Presumably this is trivial with the gnumake stuff? > > > > It's easy to run it and compare before proceeding with the build. > > > > > And the mythical petsc-config could do any number of sanity checks > > each time it is run. > > > > It might be desirable to have a > > > > petsc-config verify CC=cc CFLAGS='-m32 -mcmodel=large' > > CXXFLAGS=-std=c++11 ... > > > > that would check whether the given compiler configuration is > > binary-compatible with the way PETSc was built. It should be reasonably > > fast, but could actually run the compiler. > > > > I of course want these runtime checks. They are the biggest piece missing > from the > package model. Hm - most package models [fedora ecosystem or perhaps debian and similar] enforce uniform options [compilers, compiler options etc..] for all packages in that ecosystem - so such issues don't come up. And even if petsc were packaged as a 'module' in such a system [say cray-petsc] - these issues usually don't come up. I think when compiler modules get switched - the petsc libraries (via modules) also get switched to the ones compatible with the current compiler.. This issue usually come up when user builds PETSc from source with one enviornment - but attempts to use it from a different one.. Satish

1 0

Re: [petsc-dev] Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing
by Matthew Knepley 24 Dec '14

24 Dec '14

On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown <jed(a)jedbrown.org> wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > > >> On Dec 24, 2014, at 12:26 PM, Jed Brown <jed(a)jedbrown.org> wrote: > >> > >> In this case, it might be more reliable to compare "cc --version". > > > > Presumably this is trivial with the gnumake stuff? > > It's easy to run it and compare before proceeding with the build. > > > And the mythical petsc-config could do any number of sanity checks > each time it is run. > > It might be desirable to have a > > petsc-config verify CC=cc CFLAGS='-m32 -mcmodel=large' > CXXFLAGS=-std=c++11 ... > > that would check whether the given compiler configuration is > binary-compatible with the way PETSc was built. It should be reasonably > fast, but could actually run the compiler. > I of course want these runtime checks. They are the biggest piece missing from the package model. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing
by Jed Brown 24 Dec '14

24 Dec '14

Barry Smith <bsmith(a)mcs.anl.gov> writes: > Plenty of things are desirable, some are even achievable, but even fewer are worth doing. Well, this sort of checking is what we're talking about because it costs a lot of human time (both users and developers/support). I proposed an organization that would allow arbitrarily precise testing without asking the user to roll it themselves. The first implementation should probably do only the most cursory checking.

1 0

Re: [petsc-dev] Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing
by Barry Smith 24 Dec '14

24 Dec '14

Plenty of things are desirable, some are even achievable, but even fewer are worth doing. > On Dec 24, 2014, at 3:48 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > Barry Smith <bsmith(a)mcs.anl.gov> writes: > >>> On Dec 24, 2014, at 12:26 PM, Jed Brown <jed(a)jedbrown.org> wrote: >>> >>> In this case, it might be more reliable to compare "cc --version". >> >> Presumably this is trivial with the gnumake stuff? > > It's easy to run it and compare before proceeding with the build. > >> And the mythical petsc-config could do any number of sanity checks each time it is run. > > It might be desirable to have a > > petsc-config verify CC=cc CFLAGS='-m32 -mcmodel=large' CXXFLAGS=-std=c++11 ... > > that would check whether the given compiler configuration is > binary-compatible with the way PETSc was built. It should be reasonably > fast, but could actually run the compiler.

1 0

Re: [petsc-dev] Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing
by Jed Brown 24 Dec '14

24 Dec '14

Barry Smith <bsmith(a)mcs.anl.gov> writes: >> On Dec 24, 2014, at 12:26 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> >> In this case, it might be more reliable to compare "cc --version". > > Presumably this is trivial with the gnumake stuff? It's easy to run it and compare before proceeding with the build. > And the mythical petsc-config could do any number of sanity checks each time it is run. It might be desirable to have a petsc-config verify CC=cc CFLAGS='-m32 -mcmodel=large' CXXFLAGS=-std=c++11 ... that would check whether the given compiler configuration is binary-compatible with the way PETSc was built. It should be reasonably fast, but could actually run the compiler.

1 0

Re: [petsc-dev] Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing
by Barry Smith 24 Dec '14

24 Dec '14

> On Dec 24, 2014, at 12:26 PM, Jed Brown <jed(a)jedbrown.org> wrote: > >> > > > In this case, it might be more reliable to compare "cc --version". Presumably this is trivial with the gnumake stuff? And the mythical petsc-config could do any number of sanity checks each time it is run. Barry > Modules was never intended as a robust solution. It was a disgusting > hack that probably seemed okay at the time, but ended up as an > established methodology and now we have to live with its many points of > failure, horrible debugability, and lack of an API.

1 0

Re: [petsc-dev] Sean is going to love this
by Jed Brown 24 Dec '14

24 Dec '14

Satish Balay <balay(a)mcs.anl.gov> writes: > Or just have the data in bin/petsc-config? [since this is likely to be > a different file for each petsc variant thats installed?] Sure, accessible with something like petsc-config --raw configure.log

1 0