From: Kirk, B. (JSC-EG311) <ben...@na...> - 2010-03-30 20:31:48
|
Thanks. 3.1 was released 4 days ago, so I expect we will have support for it in about a week or so. -Ben ----- Original Message ----- From: Liang <goe...@gm...> To: libmesh-devel <lib...@li...> Sent: Tue Mar 30 15:28:04 2010 Subject: [Libmesh-devel] PETSc v3.1 doesn't cooperate libmesh 0.6.4 well Hi Developers and Users, I did install the libmesh 0.6.4 on a new computer today, it conflicts with the lastest PETSc v3.1. The libmesh can't find the /bmake/linux-gnu-c-debug/package. When I downgrade the PESTs to the v.3.0. the installation goes smoothly. So the PETSc v3.0 will be a good choice if installing the libmesh v0.6.4 currently. Liang ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Libmesh-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2010-04-02 20:48:41
|
Thank you, works for me on my leopard laptop. -Ben ----- Original Message ----- From: Roy Stogner <roy...@ic...> To: Kirk, Benjamin (JSC-EG311) Cc: 'goe...@gm...' <goe...@gm...>; 'lib...@li...' <lib...@li...> Sent: Fri Apr 02 15:15:54 2010 Subject: Re: [Libmesh-devel] PETSc v3.1 doesn't cooperate libmesh 0.6.4 well I had reason to build PETSc 3.1 this week - 3.0.0p8 was giving me some wonky behavior which I hoped (correctly, as it turns out) that 3.1 might fix. Anyway, I added a couple more special cases to our Make.common for it. No big API changes that affect us this time as far as I can tell, but one of our tests for PETSc version was broken (we were looking for 3.0.x instead of 3.x.x) and there's a linker change (everything's been bundled into one libpetsc now, apparently) that I added a new special case for. If anyone else has the chance to try out the SVN head with PETSc 3.1 (or even just to try out the SVN head and make sure I haven't broken us with any older PETSc...), I'd appreciate it. Our svn tree is pretty stable at the moment (modulo one patch from Lorenzo which is still on my todo list), and once we're sure we've got compatibility with the latest PETSc that's probably worth releasing a libMesh 0.6.5. --- Roy On Tue, 30 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: > Thanks. 3.1 was released 4 days ago, so I expect we will have support for it in about a week or so. > > -Ben > > > ----- Original Message ----- > From: Liang <goe...@gm...> > To: libmesh-devel <lib...@li...> > Sent: Tue Mar 30 15:28:04 2010 > Subject: [Libmesh-devel] PETSc v3.1 doesn't cooperate libmesh 0.6.4 well > > Hi Developers and Users, > > I did install the libmesh 0.6.4 on a new computer today, it conflicts > with the lastest PETSc v3.1. The libmesh can't find the > /bmake/linux-gnu-c-debug/package. When I downgrade the PESTs to the > v.3.0. the installation goes smoothly. So the PETSc v3.0 will be a good > choice if installing the libmesh v0.6.4 currently. > > Liang > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2010-04-20 20:34:14
|
John's recollection parallels mine. I have no problem using the approach where we can, provided we don't blow away the current capability for dealing with makefile-less petsc installations. -Ben ----- Original Message ----- From: John Peterson <pet...@cf...> To: Roy Stogner <roy...@ic...> Cc: lib...@li... <lib...@li...> Sent: Tue Apr 20 15:28:56 2010 Subject: Re: [Libmesh-devel] PETSc v3.1 doesn't cooperate libmesh 0.6.4 well On Tue, Apr 20, 2010 at 3:19 PM, Roy Stogner <roy...@ic...> wrote: > > On Sat, 3 Apr 2010, Jed Brown wrote: > >> Note that an alternative to all the version checking is to snarf the >> output of "make getlinklibs" > > We used to use this in our Make.common.in - looks like it was > commented out in r2089. The changelog doesn't say why we started > trying to do things manually, except that whatever it was might have > annoyed Ben enough to produce the freudian typo "pestc". ;-) I think not all PETSc installs (at the time) had a Makefile installed with them, so we couldn't use make getlinklibs reliably everywhere. -- John ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2010-04-20 20:59:19
|
> I think not all PETSc installs (at the time) had a Makefile installed > with them, so we couldn't use make getlinklibs reliably everywhere. > -- > John On Tue, 20 Apr 2010, Kirk, Benjamin (JSC-EG311) wrote: > John's recollection parallels mine. Ah! That would definitely rule out "make getlinklibs", then! > I have no problem using the approach where we can, provided we don't > blow away the current capability for dealing with makefile-less > petsc installations. I was actually suggesting using $PETSC_SNES_LIB, on the theory that that can get snarfed from the same {packages,petscconf,petscvariables} file that we're currently including. But it turns out that $PETSC_SNES_LIB is not in $PETSC_ARCH/conf/petscvariables, it's in conf/variables (or bmake/common/variables), which we don't currently include. I'm not sure what else a makefile-less petsc installation might have missing. --- Roy |
From: Roy S. <roy...@ic...> - 2010-05-11 20:06:21
|
On Tue, 20 Apr 2010, Roy Stogner wrote: > On Tue, 20 Apr 2010, Kirk, Benjamin (JSC-EG311) wrote: > >> I have no problem using the approach where we can, provided we don't >> blow away the current capability for dealing with makefile-less >> petsc installations. > > I was actually suggesting using $PETSC_SNES_LIB, on the theory that > that can get snarfed from the same {packages,petscconf,petscvariables} > file that we're currently including. But it turns out that > $PETSC_SNES_LIB is not in $PETSC_ARCH/conf/petscvariables, it's in > conf/variables (or bmake/common/variables), which we don't currently > include. This seems to be working on PETSc 3.1, 3.0, and 2.3.3 for me. I'm going to commit it now to let it get a little wider exposure. > I'm not sure what else a makefile-less petsc installation > might have missing. And I'm still not sure - so everyone feel free to scream at me if you have trouble building or linking after your next svn update. --- Roy |
From: Liang <goe...@gm...> - 2010-03-30 20:43:37
|
Kirk, Benjamin (JSC-EG311) wrote: > Thanks. 3.1 was released 4 days ago, so I expect we will have support for it in about a week or so. > > -Ben > > > Thanks for your great FEA package, so that I can survive in the my group, and I plan to use libmesh to do my thesis, it is pretty powerful and flexiable software, hope someday I may do some contribution on it also. Liang |
From: Roy S. <roy...@ic...> - 2010-04-02 20:16:01
|
I had reason to build PETSc 3.1 this week - 3.0.0p8 was giving me some wonky behavior which I hoped (correctly, as it turns out) that 3.1 might fix. Anyway, I added a couple more special cases to our Make.common for it. No big API changes that affect us this time as far as I can tell, but one of our tests for PETSc version was broken (we were looking for 3.0.x instead of 3.x.x) and there's a linker change (everything's been bundled into one libpetsc now, apparently) that I added a new special case for. If anyone else has the chance to try out the SVN head with PETSc 3.1 (or even just to try out the SVN head and make sure I haven't broken us with any older PETSc...), I'd appreciate it. Our svn tree is pretty stable at the moment (modulo one patch from Lorenzo which is still on my todo list), and once we're sure we've got compatibility with the latest PETSc that's probably worth releasing a libMesh 0.6.5. --- Roy On Tue, 30 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: > Thanks. 3.1 was released 4 days ago, so I expect we will have support for it in about a week or so. > > -Ben > > > ----- Original Message ----- > From: Liang <goe...@gm...> > To: libmesh-devel <lib...@li...> > Sent: Tue Mar 30 15:28:04 2010 > Subject: [Libmesh-devel] PETSc v3.1 doesn't cooperate libmesh 0.6.4 well > > Hi Developers and Users, > > I did install the libmesh 0.6.4 on a new computer today, it conflicts > with the lastest PETSc v3.1. The libmesh can't find the > /bmake/linux-gnu-c-debug/package. When I downgrade the PESTs to the > v.3.0. the installation goes smoothly. So the PETSc v3.0 will be a good > choice if installing the libmesh v0.6.4 currently. > > Liang > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Jed B. <je...@59...> - 2010-04-04 00:01:58
|
> 3.1.x PETSc is all in one library? 3.1 introduced a configure option --with-single-library. This is the default because it simplifies linking, but we still support keeping the libraries separate (--with-single-library=0). I think most of the PETSc developers have them separate just because it keeps us honest about module decoupling, and presumably there are some users that do this as well. If you want to support --with-single-library=0, then you can check PETSC_USE_SINGLE_LIBRARY (will not be defined in this case) and link as before, but with -lpetscsys for the core stuff. Jed Note that an alternative to all the version checking is to snarf the output of "make getlinklibs" or the value of PETSC_TS_LIB (or PETSC_SNES_LIB since you don't currently use TS) which is guaranteed to work with all versions of PETSc, in all configurations, including with static libs and arbitrary third-party dependencies. |
From: Roy S. <roy...@ic...> - 2010-04-20 20:20:05
|
On Sat, 3 Apr 2010, Jed Brown wrote: > Note that an alternative to all the version checking is to snarf the > output of "make getlinklibs" We used to use this in our Make.common.in - looks like it was commented out in r2089. The changelog doesn't say why we started trying to do things manually, except that whatever it was might have annoyed Ben enough to produce the freudian typo "pestc". ;-) > or the value of PETSC_TS_LIB (or PETSC_SNES_LIB since you don't > currently use TS) which is guaranteed to work with all versions of > PETSc, in all configurations, including with static libs and > arbitrary third-party dependencies. This seems to work pretty reliably for me. Unless anyone jumps in to object, I'll make this the default way Make.common.in works in the future; it sounds much better than trying to add a new test every time PETSc adds a new link configuration. --- Roy |
From: John P. <pet...@cf...> - 2010-04-20 20:29:25
|
On Tue, Apr 20, 2010 at 3:19 PM, Roy Stogner <roy...@ic...> wrote: > > On Sat, 3 Apr 2010, Jed Brown wrote: > >> Note that an alternative to all the version checking is to snarf the >> output of "make getlinklibs" > > We used to use this in our Make.common.in - looks like it was > commented out in r2089. The changelog doesn't say why we started > trying to do things manually, except that whatever it was might have > annoyed Ben enough to produce the freudian typo "pestc". ;-) I think not all PETSc installs (at the time) had a Makefile installed with them, so we couldn't use make getlinklibs reliably everywhere. -- John |
From: Jed B. <je...@59...> - 2010-04-23 13:44:19
|
On Tue, 20 Apr 2010 15:28:56 -0500, John Peterson <pet...@cf...> wrote: > I think not all PETSc installs (at the time) had a Makefile installed > with them, so we couldn't use make getlinklibs reliably everywhere. "prefix" installs don't have one, but you can use your own makefile that consists of just two lines include $(PETSC_DIR)/conf/variables include $(PETSC_DIR)/conf/rules and $ make -f my-makefile getlinklibs Jed |