From: Roy S. <roy...@ic...> - 2010-09-28 19:50:32
|
The SVN head's currently pretty stable from my perspective, with the exception of rbOOmit stuff, which David tells me is now in shape for an immediate release. Does anyone else have anything they want to get added/fixed before we put out a tarball? I'll try to skim over the svn log to put together a changes list to announce, but if people could email me a summary of their modifications since 0.6.4 that would be helpful. --- Roy |
From: John P. <pet...@cf...> - 2010-09-28 19:58:20
|
On Tue, Sep 28, 2010 at 2:50 PM, Roy Stogner <roy...@ic...> wrote: > > The SVN head's currently pretty stable from my perspective, with the > exception of rbOOmit stuff, which David tells me is now in shape for > an immediate release. Hi Roy, I have a local change fixing the setting of the time variable in the FEM/DiffContext. In order to do that, I needed access to the "deltat" variable from the System which created the FEMContext. The approach I'm currently using requires the creating System be derived from a FEMSystem, so that the existence of deltat is guaranteed. We discussed moving deltat to System itself so that this assumption is no longer required, but IIRC correctly you weren't super-enthusiastic about that solution, since forcing a deltat parameter on the base System class (which may represent a steady set of equations) was less than desirable. Should I go ahead and move deltat to System, or did you have something else in mind? Alternatively we could wait until after the release, but this does fix a potential bug in FEMContext so it might be good to get out now. -- John |
From: Roy S. <roy...@ic...> - 2010-09-28 20:18:31
|
On Tue, 28 Sep 2010, John Peterson wrote: > I have a local change fixing the setting of the time variable in the > FEM/DiffContext. > > In order to do that, I needed access to the "deltat" variable from the > System which created the FEMContext. > > The approach I'm currently using requires the creating System be > derived from a FEMSystem, so that the existence of deltat is > guaranteed. We discussed moving deltat to System itself so that this > assumption is no longer required, but IIRC correctly you weren't > super-enthusiastic about that solution, since forcing a deltat > parameter on the base System class (which may represent a steady set > of equations) was less than desirable. > > Should I go ahead and move deltat to System, or did you have something > else in mind? Alternatively we could wait until after the release, > but this does fix a potential bug in FEMContext so it might be good to > get out now. Damn, I'd forgotten about that one. I'd rather fix it now, certainly; otherwise we're killing higher-order time discretization accuracy for anyone whose FEMSystem physics depends directly on t and not just on d/dt. Double damn. I just realized I was describing an undiagnosed problem that Paul Bauman saw; I'll Cc: this to him. But although a bad fix would be better than no fix, I'd still like to avoid an aesthetically bad fix, so let's try to brainstorm other options first. Perhaps give DiffContext a Real* _delta_t member variable, default NULL, with setter/getter options? build_context() in a DiffSystem would assign that to the system delta_t, users with their own transient systems could assign it instead to their own time step, and we'd just have to test for NULL before using it within DiffContext or a subclass. David, any thoughts? You and the other RB folks are probably the only ones currently using DiffContext in transient systems other than DiffSystem. --- Roy |
From: David K. <dknez@MIT.EDU> - 2010-09-28 20:33:05
|
> On Tue, 28 Sep 2010, John Peterson wrote: > >> I have a local change fixing the setting of the time variable in the >> FEM/DiffContext. >> >> In order to do that, I needed access to the "deltat" variable from the >> System which created the FEMContext. >> >> The approach I'm currently using requires the creating System be >> derived from a FEMSystem, so that the existence of deltat is >> guaranteed. We discussed moving deltat to System itself so that this >> assumption is no longer required, but IIRC correctly you weren't >> super-enthusiastic about that solution, since forcing a deltat >> parameter on the base System class (which may represent a steady set >> of equations) was less than desirable. >> >> Should I go ahead and move deltat to System, or did you have something >> else in mind? Alternatively we could wait until after the release, >> but this does fix a potential bug in FEMContext so it might be good to >> get out now. > > Damn, I'd forgotten about that one. I'd rather fix it now, certainly; > otherwise we're killing higher-order time discretization accuracy for > anyone whose FEMSystem physics depends directly on t and not just on > d/dt. > > Double damn. I just realized I was describing an undiagnosed problem > that Paul Bauman saw; I'll Cc: this to him. > > > But although a bad fix would be better than no fix, I'd still like to > avoid an aesthetically bad fix, so let's try to brainstorm other > options first. > > Perhaps give DiffContext a Real* _delta_t member variable, default > NULL, with setter/getter options? build_context() in a DiffSystem > would assign that to the system delta_t, users with their own > transient systems could assign it instead to their own time step, and > we'd just have to test for NULL before using it within DiffContext or > a subclass. > > David, any thoughts? You and the other RB folks are probably the only > ones currently using DiffContext in transient systems other than > DiffSystem. Your Real* _delta_t idea would work fine in the RB context too, so I'd be happy with that. David |
From: Derek G. <fri...@gm...> - 2010-09-28 20:32:43
|
We're working on a small patch to System::add_vector() to allow adding ghosted vectors. It might be nice if that made it in the release but it isn't critical. I'll check and see if we have other outstanding libmesh patches lying around and try to get them shape and committed. Derek Sent from my iPad On Sep 28, 2010, at 2:50 PM, Roy Stogner <roy...@ic...> wrote: > > The SVN head's currently pretty stable from my perspective, with the > exception of rbOOmit stuff, which David tells me is now in shape for > an immediate release. > > Does anyone else have anything they want to get added/fixed before we > put out a tarball? > > I'll try to skim over the svn log to put together a changes list to > announce, but if people could email me a summary of their > modifications since 0.6.4 that would be helpful. > --- > Roy > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2010-09-28 20:36:00
|
On Tue, 28 Sep 2010, Derek Gaston wrote: > We're working on a small patch to System::add_vector() to allow adding > ghosted vectors. It might be nice if that made it in the release but > it isn't critical. I'll check and see if we have other outstanding > libmesh patches lying around and try to get them shape and committed. Thanks! No rush; we're not on a deadline. If we're ready to release by next week it would be nice, but if it takes longer we can always branch the tree; let people get back to new work on the trunk while the branch gets cleaned up for release. --- Roy |
From: Cody P. <cod...@gm...> - 2010-09-28 21:25:31
|
I have one! David, Derek and I have all been working to get libMesh working with the Apple supplied GCC compilers. Apple has forked GCC and is forging ahead full steam and will probably continue to diverge from the normal GCC tree. Derek discovered that the R project is maintaining GFORTRAN in lockstep with XCode on the Mac and it is possible to install that package and then build the full stack underneath libMesh (MPICH2, HYPRE, and PETSC) with a few modifications. We haven't succeeded with this task since Snow Leopard was introduced so this is really good news. There are a few additional fixes and hacks (yes both) that need to be added and tested in the m4 scripts. First we found that some of the flags in the "gcc debug" sections do not work with the Apple compilers. Specifically -D_GLIBCXX_DEBUG and -D_GLIBCXX_DEBUG_PEDANTIC. These flags cause memory corruption/seg fault issues in _some_ of the libMesh examples when running the debug version of the code. Hum - I think we saw something like this on the mailing list last week. What's interesting is that that user was using the HPC compilers which I haven't seen affected by this issue. I'm curious, why are these flags specifically added here? Are the regular debug flags not enough or do we really need these more esoteric flags? The second issue has already been discussed on the mailing list: http://www.mail-archive.com/lib...@li.../msg02436.html These flags are still necessary to successfully run libMesh examples that use RTTI (example 13). This does appear to be a bug in Apple's linker so perhaps we need those extra cases in the configure scripts anyway, since Apple will most likely eventually fix that bug. As it stands now, libMesh HEAD does not run on Mac OS 10.6 without third party compilers or hackery in the Make files so this should be solidified before the next point release. I'm more than happy to commit changes to the m4 scripts, I just want to understand the debug compiler flags being used and why they are there. Thanks, Cody On Sep 28, 2010, at 2:35 PM, Roy Stogner wrote: > > On Tue, 28 Sep 2010, Derek Gaston wrote: > >> We're working on a small patch to System::add_vector() to allow adding >> ghosted vectors. It might be nice if that made it in the release but >> it isn't critical. I'll check and see if we have other outstanding >> libmesh patches lying around and try to get them shape and committed. > > Thanks! > > No rush; we're not on a deadline. If we're ready to release by next > week it would be nice, but if it takes longer we can always branch the > tree; let people get back to new work on the trunk while the branch > gets cleaned up for release. > --- > Roy > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2010-09-28 21:58:24
|
On Tue, 28 Sep 2010, Cody Permann wrote: > First we found that some of the flags in the "gcc debug" sections do > not work with the Apple compilers. Specifically -D_GLIBCXX_DEBUG > and -D_GLIBCXX_DEBUG_PEDANTIC. These flags cause memory > corruption/seg fault issues in _some_ of the libMesh examples when > running the debug version of the code. Hum - I think we saw > something like this on the mailing list last week. What's > interesting is that that user was using the HPC compilers which I > haven't seen affected by this issue. Interesting but not surprising; it's a broken compiler/libstdc++ specific issue. > I'm curious, why are these flags specifically added here? Are the > regular debug flags not enough or do we really need these more > esoteric flags? The regular debug flags aren't enough. In cases where they would be enough, usually METHOD=devel is what you want instead. Using -O0 and the GLIBCXX_DEBUG options makes METHOD=debug hideously slow, and apparently it's not an option with broken gcc forks, but it's absolutely invaluable in general. Those flags turn on STL validity checks (including bounds checking on std::vector!), and they've found countless bugs for us. I caught an application bug thanks to those options just two days ago. But on the other hand, if broken gcc forks are going to be an issue on one of the most popular supported libMesh platforms, then that's an issue we ought to work around. Let's see if we can detect Apple-specific gcc versions in compiler.m4, then disable the GLIBCXX_DEBUG defines when necessary? > The second issue has already been discussed on the mailing list: > http://www.mail-archive.com/lib...@li.../msg02436.html > These flags are still necessary to successfully run libMesh examples > that use RTTI (example 13). This does appear to be a bug in Apple's > linker so perhaps we need those extra cases in the configure scripts > anyway, since Apple will most likely eventually fix that bug. Yeah, but it would be good to avoid that bug in the meantime. I don't much mind our having to work around system-level deficiencies, as long as the workarounds don't interfere with other systems. > As it stands now, libMesh HEAD does not run on Mac OS 10.6 without > third party compilers or hackery in the Make files so this should be > solidified before the next point release. Definitely. --- Roy |
From: Derek G. <fri...@gm...> - 2010-10-11 18:41:41
|
I just committed our changes to System::add_vector().... which as far as I know was the last remaining thing I wanted to see in this release... Derek On Tue, Sep 28, 2010 at 2:32 PM, Derek Gaston <fri...@gm...> wrote: > We're working on a small patch to System::add_vector() to allow adding > ghosted vectors. It might be nice if that made it in the release but > it isn't critical. I'll check and see if we have other outstanding > libmesh patches lying around and try to get them shape and committed. > > Derek > > Sent from my iPad > > On Sep 28, 2010, at 2:50 PM, Roy Stogner <roy...@ic...> wrote: > > > > > The SVN head's currently pretty stable from my perspective, with the > > exception of rbOOmit stuff, which David tells me is now in shape for > > an immediate release. > > > > Does anyone else have anything they want to get added/fixed before we > > put out a tarball? > > > > I'll try to skim over the svn log to put together a changes list to > > announce, but if people could email me a summary of their > > modifications since 0.6.4 that would be helpful. > > --- > > Roy > > > > > ------------------------------------------------------------------------------ > > Start uncovering the many advantages of virtual appliances > > and start using them to simplify application deployment and > > accelerate your shift to cloud computing. > > http://p.sf.net/sfu/novell-sfdev2dev > > _______________________________________________ > > Libmesh-devel mailing list > > Lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Roy S. <roy...@ic...> - 2010-10-11 20:13:36
|
On Mon, 11 Oct 2010, Derek Gaston wrote: > I just committed our changes to System::add_vector().... which as > far as I know was the last remaining thing I wanted to see in this > release... I've fixed some bugs in the GetPot UFO detection and in the NonlinearImplicitSystem adjoints integration... I'm still getting a segfault when I try to use the new rbOOmit example with Trilinos, but I don't have time to figure that out right now, so let's call this 0.7.0-rc1. I'll get a tarball up shortly. --- Roy |