From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-25 21:58:26
|
Im thrilled with all the recent trunk activity, and I've got some major changes id like to implement soon, but first - anything outstanding before we create a new release? -Ben |
From: Roy S. <roy...@ic...> - 2012-10-25 22:10:07
|
On Thu, 25 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: > Im thrilled with all the recent trunk activity, and I've got some > major changes id like to implement soon, but first - anything > outstanding before we create a new release? If you're still planning to merge automake before the next release, I'd like that to sit in trunk for a while first to see how loud everybody screams. There's some ParallelMesh+AMR issues that are tripping failures for us. Not new bugs, just newly-exposed bugs, though, so I wouldn't say this is a showstopper. It is something I'm close to fixing, though, if that's worth the wait. There's bugfixes for the no-MPI and --enable-complex configurations that I need to get in and test; shouldn't take more than a day or two. There's a barebones-configuration test failure that I haven't looked into yet. That's it for me. --- Roy |
From: Cody P. <cod...@gm...> - 2012-10-25 22:31:27
|
On Oct 25, 2012, at 4:10 PM, Roy Stogner <roy...@ic...> wrote: > > On Thu, 25 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: > >> Im thrilled with all the recent trunk activity, and I've got some >> major changes id like to implement soon, but first - anything >> outstanding before we create a new release? > > If you're still planning to merge automake before the next release, > I'd like that to sit in trunk for a while first to see how loud > everybody screams. Are there plans to distribute a prebuilt "default" Makefile? Users could always generate there own, especially if they want out of tree builds or have an odd system. The reason I ask is because without a default Makefile, this changes the baseline requirements a bit. Users now need auto tools installed which aren't always installed on systems by default. OS X falls in that category. Cody > > There's some ParallelMesh+AMR issues that are tripping failures for > us. Not new bugs, just newly-exposed bugs, though, so I wouldn't say > this is a showstopper. It is something I'm close to fixing, though, > if that's worth the wait. > > There's bugfixes for the no-MPI and --enable-complex configurations > that I need to get in and test; shouldn't take more than a day or two. > > There's a barebones-configuration test failure that I haven't looked > into yet. > > That's it for me. > --- > Roy > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-25 22:35:56
|
>> Im thrilled with all the recent trunk activity, and I've got some >> major changes id like to implement soon, but first - anything >> outstanding before we create a new release? > > If you're still planning to merge automake before the next release, > I'd like that to sit in trunk for a while first to see how loud > everybody screams. I'm not. Specifically, my plan 1.) this release 2.) merge automake 3.) move to github if that is the consensus It is easy to sync trunk and its complete revision history to github, but with complex branches and tags it gets difficult. So I like Cody's suggestion that just came in > Are there plans to distribute a prebuilt "default" Makefile? Users > could always generate there own, especially if they want out of tree > builds or have an odd system. but that can be after this release. > There's some ParallelMesh+AMR issues that are tripping failures for > us. Not new bugs, just newly-exposed bugs, though, so I wouldn't say > this is a showstopper. It is something I'm close to fixing, though, > if that's worth the wait. > > There's bugfixes for the no-MPI and --enable-complex configurations > that I need to get in and test; shouldn't take more than a day or two. > > There's a barebones-configuration test failure that I haven't looked > into yet. Thanks. I'll see if I can snoop the PECOS buildbot results and help where I can. But basically I'd like to freeze features for a bit to clean up for a release (your request ongoing in parallel, Dave.) -Ben |
From: Paul T. B. <ptb...@gm...> - 2012-10-25 22:36:04
|
On Thu, Oct 25, 2012 at 5:31 PM, Cody Permann <cod...@gm...> wrote: > > Are there plans to distribute a prebuilt "default" Makefile? Users > could always generate there own, especially if they want out of tree > builds or have an odd system. > IMO, it should ship with a configure (built from the bootstrap) and the bootstrap script (really just autoreconf). configure will generate the Makefiles and the user doesn't need autotools, but if user wants to monkey with the build system, they can then bootstrap, configure, etc. Should be very similar to the current trunk from the user stand point. |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-25 22:40:17
|
On Oct 25, 2012, at 5:35 PM, "Paul T. Bauman" <ptb...@gm...> wrote: > On Thu, Oct 25, 2012 at 5:31 PM, Cody Permann <cod...@gm...> wrote: > > Are there plans to distribute a prebuilt "default" Makefile? Users > could always generate there own, especially if they want out of tree > builds or have an odd system. > > IMO, it should ship with a configure (built from the bootstrap) and the bootstrap script (really just autoreconf). configure will generate the Makefiles and the user doesn't need autotools, but if user wants to monkey with the build system, they can then bootstrap, configure, etc. Should be very similar to the current trunk from the user stand point. Oh - now I understand the question… Cody, try 'make dist' - that packages up exactly what I would expect to distribute in the future, which does not require autotools… But still after this release. -Ben |
From: Roy S. <roy...@ic...> - 2012-10-25 22:43:23
|
On Thu, 25 Oct 2012, Paul T. Bauman wrote: > IMO, it should ship with a configure (built from the bootstrap) and > the bootstrap script (really just autoreconf). configure will > generate the Makefiles and the user doesn't need autotools, but if > user wants to monkey with the build system, they can then bootstrap, > configure, etc. Should be very similar to the current trunk from the > user stand point. For release versions, we ought to be able to upload the output of "make dist", right? That has configure and everything.in pregenerated, yet it ought to still include the .ac and .am files for anyone who wants to monkey with the build system. What do we do about people who want to follow svn, though? I'd vote for our current "check in the results of ./bootstrap" policy, despite the results being slightly more voluminous. The only alternative would seem to be insisting that users work on the "buddy" system, wherein if you can't build autotools yourself you find someone who can to ship you a "make dist" when you need an update... --- Roy |
From: Derek G. <fri...@gm...> - 2012-10-25 22:46:30
|
On Thu, Oct 25, 2012 at 4:43 PM, Roy Stogner <roy...@ic...>wrote: > > What do we do about people who want to follow svn, though? I'd vote > for our current "check in the results of ./bootstrap" policy, despite > the results being slightly more voluminous. I vote for this. Anyone should be able to checkout a revision and get a normal build through: ./configure make Then if you need more than that you can handle that yourself. Derek |
From: Paul T. B. <ptb...@gm...> - 2012-10-25 22:47:11
|
On Thu, Oct 25, 2012 at 5:43 PM, Roy Stogner <roy...@ic...>wrote: > > For release versions, we ought to be able to upload the output of > "make dist", right? That has configure and everything.in > pregenerated, yet it ought to still include the .ac and .am files for > anyone who wants to monkey with the build system. > Yeah, I should've put it this way. make dist will supply everything needed for working with and without autotools. > What do we do about people who want to follow svn, though? I'd vote > for our current "check in the results of ./bootstrap" policy, despite > the results being slightly more voluminous. > This seems very reasonable to me. |
From: Roy S. <roy...@ic...> - 2012-10-25 22:49:22
|
On Thu, 25 Oct 2012, Roy Stogner wrote: > The only alternative would seem to be insisting that users work on > the "buddy" system, wherein if you can't build autotools yourself > you find someone who can to ship you a "make dist" when you need an > update... On second thought, this idea gets less stupid if your "buddy" isn't a human being. We could always do what a lot of other projects do and auto-upload a "nightly" snapshot. The last thing BuildBot could do after a revision passes all tests is "make dist", date stamp the tarball, and scp it to the public server. I'd still prefer just checking in autotools output, but as long as there's some way for autotools-bereft users to build a recent snapshot I'm happy. --- Roy |
From: Paul T. B. <ptb...@gm...> - 2012-10-25 22:53:56
|
On Thu, Oct 25, 2012 at 5:36 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > > But basically I'd like to freeze features for a bit to clean up for a > release Of the several features/changes I've worked on the past few months, here's the current status of incomplete stuff (that I can remember): 1. FEMContext work - Finish off hiding public members and putting in accessors. I can get this done pretty quickly so I don't think it would hold up a release, but nothing is broken at the moment. We are storing redundant FE info (not much) until we decide to break backward compatibility. 2. Vector FE - C1 constraints in DirichletConstraint need to be put in/completed/fixed, periodic constraints and adaptivity constraints are not in at all. This will take some time for me so I would say this will need to wait. 3. Nedelec FE - Dirichlet constraints, periodic constraints, and adaptivity constraints all need to go in. Also currently limited to 2D, first order. 3D first order will go in soon, but not before the release. 2D vs. 3D is a real PITA for the constraints for HCURL continuity and will take some time to get right. |
From: Roy S. <roy...@ic...> - 2012-10-25 22:58:01
|
On Thu, 25 Oct 2012, Paul T. Bauman wrote: > 1. FEMContext work - Finish off hiding public members and putting in > accessors. I can get this done pretty quickly so I don't think it > would hold up a release, but nothing is broken at the moment. We are > storing redundant FE info (not much) until we decide to break > backward compatibility. Oh, I forgot about this. I'd definitely like such simple API improvements to make it into the next release. I'd also like the DiffPhysics refactoring to be finished the way the DiffQoI refactoring was, but hopefully this time without me slacking off so long that Paul has to do it. I wouldn't be able to get to this until next week, though. --- Roy |
From: Cody P. <cod...@gm...> - 2012-10-25 23:29:05
|
Ah, yes my mistake. I didn't mean Makefile, but I think you all figured out what I meant. Just wanted to maintain old behavior as much as possible from the user perspective. I don't particularly have any strong opinions on exactly how we generate those files (something akin to our current bootstrap process is fine with me as others have pointed out). I think we are all on the same page. Cody Sent from my iPhone On Oct 25, 2012, at 4:58 PM, Roy Stogner <roy...@ic...> wrote: > > On Thu, 25 Oct 2012, Paul T. Bauman wrote: > >> 1. FEMContext work - Finish off hiding public members and putting in >> accessors. I can get this done pretty quickly so I don't think it >> would hold up a release, but nothing is broken at the moment. We are >> storing redundant FE info (not much) until we decide to break >> backward compatibility. > > Oh, I forgot about this. I'd definitely like such simple API > improvements to make it into the next release. > > I'd also like the DiffPhysics refactoring to be finished the way the > DiffQoI refactoring was, but hopefully this time without me slacking > off so long that Paul has to do it. I wouldn't be able to get to this > until next week, though. > --- > Roy > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Vikram G. <sim...@gm...> - 2012-10-26 00:43:02
|
We have the following support for adjoints. Roy/Paul please correct/add/expand as you see fit. Fully coupled or single-physics problems: 1) Adjoint refinement based error estimators (Global bounds for | Q(u) - Q(u_h) |, Adjoint Example 4 ) 2) Adjoint refinement based error indicators (Adjoint Example 4) 3) Adjoint Residual based error indicators (Has been there for a while) 4) Adjoint parameter sensitivity analysis and Hessians (Been there for a while as well) Future work: 1) Proper scaling for local error indicators for the Adjoint Refinement indicator (this is almost done, needs some refactoring in the library to be finally implemented) 2) Support for user specified adjoint boundary conditions + DirichletBoundary (for boundary flux type QoIs) 3) We probably want something better than 'store primal solution' at every timestep for time dependent adjoint problems (This might become a high priority for me soon, so I might try implementing some kind of checkpointing algorithm in the coming weeks.) 4) For one-way coupled problems, right now we force the user to write the system as one block. We might want to allow the user more flexibility here. Thanks. On Thu, Oct 25, 2012 at 7:28 PM, Cody Permann <cod...@gm...> wrote: > Ah, yes my mistake. I didn't mean Makefile, but I think you all > figured out what I meant. Just wanted to maintain old behavior as > much as possible from the user perspective. I don't particularly have > any strong opinions on exactly how we generate those files (something > akin to our current bootstrap process is fine with me as others have > pointed out). I think we are all on the same page. > > Cody > > Sent from my iPhone > > On Oct 25, 2012, at 4:58 PM, Roy Stogner <roy...@ic...> wrote: > > > > > On Thu, 25 Oct 2012, Paul T. Bauman wrote: > > > >> 1. FEMContext work - Finish off hiding public members and putting in > >> accessors. I can get this done pretty quickly so I don't think it > >> would hold up a release, but nothing is broken at the moment. We are > >> storing redundant FE info (not much) until we decide to break > >> backward compatibility. > > > > Oh, I forgot about this. I'd definitely like such simple API > > improvements to make it into the next release. > > > > I'd also like the DiffPhysics refactoring to be finished the way the > > DiffQoI refactoring was, but hopefully this time without me slacking > > off so long that Paul has to do it. I wouldn't be able to get to this > > until next week, though. > > --- > > Roy > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_sfd2d_oct > > _______________________________________________ > > Libmesh-devel mailing list > > Lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > -- > Vikram Garg > PhD Candidate > Institute for Computational and Engineering Sciences > The University of Texas at Austin > > <https://lists.sourceforge.net/lists/listinfo/libmesh-devel> > <https://lists.sourceforge.net/lists/listinfo/libmesh-devel> > http://users.ices.utexas.edu/~vikram/ > http://www.runforindia.org/runners/vikramg > > > |
From: Boyce G. <gri...@ci...> - 2012-10-26 00:53:47
|
On 10/25/12 6:49 PM, Roy Stogner wrote: > On second thought, this idea gets less stupid if your "buddy" isn't a > human being. We could always do what a lot of other projects do and > auto-upload a "nightly" snapshot. The last thing BuildBot could do > after a revision passes all tests is "make dist", date stamp the > tarball, and scp it to the public server. I'd still prefer just One advantage of this is that you have the build system built by a consistent autotools. Re-bootstrapping with different autotools could generate a lot of changes in svn. -- Boyce |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-26 01:30:13
|
On Oct 25, 2012, at 7:53 PM, Boyce Griffith <gri...@ci...> wrote: > On 10/25/12 6:49 PM, Roy Stogner wrote: >> On second thought, this idea gets less stupid if your "buddy" isn't a >> human being. We could always do what a lot of other projects do and >> auto-upload a "nightly" snapshot. The last thing BuildBot could do >> after a revision passes all tests is "make dist", date stamp the >> tarball, and scp it to the public server. I'd still prefer just > > One advantage of this is that you have the build system built by a > consistent autotools. Re-bootstrapping with different autotools could > generate a lot of changes in svn. definitely a good point. As it stands now, our bootstrap will *build* autotools on systems where the prerequisites are not met, so that's another approach. Regardless, the nightly 'make diet' tarball is not a bad idea either… I can remember a long time ago feeling a little hesitant checking out people's svn repos just to try building a code. I'm sure there will be plenty more discussion on the implementation after I merge the branch, which I reiterate will be after we polish the next release. -Ben |
From: Boyce G. <gri...@ci...> - 2012-10-26 01:41:56
|
On 10/25/12 9:30 PM, Kirk, Benjamin (JSC-EG311) wrote: > > On Oct 25, 2012, at 7:53 PM, Boyce Griffith <gri...@ci...> wrote: > >> On 10/25/12 6:49 PM, Roy Stogner wrote: >>> On second thought, this idea gets less stupid if your "buddy" isn't a >>> human being. We could always do what a lot of other projects do and >>> auto-upload a "nightly" snapshot. The last thing BuildBot could do >>> after a revision passes all tests is "make dist", date stamp the >>> tarball, and scp it to the public server. I'd still prefer just >> >> One advantage of this is that you have the build system built by a >> consistent autotools. Re-bootstrapping with different autotools could >> generate a lot of changes in svn. > > definitely a good point. As it stands now, our bootstrap will *build* autotools on systems where the prerequisites are not met, so that's another approach. Regardless, the nightly 'make diet' tarball is not a bad idea either… I can remember a long time ago feeling a little hesitant checking out people's svn repos just to try building a code. You might want to set it up *always* to build autotools, regardless of the installed version. Although I don't know if the same version of autotools generates consistent files on different systems... (You would hope so, but I've never checked. I wouldn't be surprised either way.) -- Boyce |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-09 20:16:03
|
On Oct 25, 2012, at 5:57 PM, Roy Stogner <roy...@ic...> wrote: > > On Thu, 25 Oct 2012, Paul T. Bauman wrote: > >> 1. FEMContext work - Finish off hiding public members and putting in >> accessors. I can get this done pretty quickly so I don't think it >> would hold up a release, but nothing is broken at the moment. We are >> storing redundant FE info (not much) until we decide to break >> backward compatibility. > > Oh, I forgot about this. I'd definitely like such simple API > improvements to make it into the next release. > > I'd also like the DiffPhysics refactoring to be finished the way the > DiffQoI refactoring was, but hopefully this time without me slacking > off so long that Paul has to do it. I wouldn't be able to get to this > until next week, though. OK, reviving this thread. I've got one more change I'd like to roll in of 0.8.0 - the RB I/O optimization - but beyond that it looks like we are pretty close. What else is still outstanding before a feature freeze/release? -Ben |
From: Roy S. <roy...@ic...> - 2012-11-09 20:25:04
|
On Fri, 9 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote: > OK, reviving this thread. I've got one more change I'd like to roll > in of 0.8.0 - the RB I/O optimization - but beyond that it looks > like we are pretty close. > > What else is still outstanding before a feature freeze/release? I've got a tragic fix for the --enable-singleprecision problems that one of Paul's examples just uncovered - basically the new VectorValue constructors in r5772 have turned out to be more trouble than they were worth. I was going to wait a BuildBot cycle or two to make sure that reversion doesn't break any --enable-complex or other odd cases, but I can run those manually if it's the only thing blocking 0.8.0-rc1. I've got a few fixes for ParallelMesh bugs still in testing. They're all for distributed-repartitioning-enabled cases, though, and there's still enough outstanding bugs there that we won't be enabling distributed repartitioning this release, so no need to wait on this stuff. --- Roy |
From: John P. <pet...@cf...> - 2012-11-09 20:33:40
|
On Fri, Nov 9, 2012 at 1:15 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > OK, reviving this thread. I've got one more change I'd like to roll in of > 0.8.0 - the RB I/O optimization - but beyond that it looks like we are > pretty close. > > What else is still outstanding before a feature freeze/release? > Well, trunk is not in great shape at the moment on Lion/Mountain Lion, since -flat_namespace is hard-coded in compiler.m4. At this point, I'm fairly convinced that the only way to do shared library linking **portably** is with libtool, but I haven't started on this patch yet...and it will likely take a few iterations to get correct. -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-09 20:47:59
|
On Nov 9, 2012, at 2:33 PM, John Peterson <pet...@cf...> wrote: > At this point, I'm fairly convinced that the only way to do shared library linking **portably** is with libtool, but I haven't started on this patch yet...and it will likely take a few iterations to get correct. FWIW, Roy and I were having some offline discussion, and as soon as 0.8.0 is tagged I plan to merge automake. Like the next day… So keep that in mind, if automake is working for you then you might hedge how much effort you put into the current trunk. -Ben |
From: John P. <pet...@cf...> - 2012-11-09 21:02:16
|
On Fri, Nov 9, 2012 at 1:47 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > FWIW, Roy and I were having some offline discussion, and as soon as 0.8.0 > is tagged I plan to merge automake. Like the next day… > > So keep that in mind, if automake is working for you then you might hedge > how much effort you put into the current trunk. > Understood. We might persist on pre-automake trunk here for a while before switching over all our users. I'll put some effort into fixing the flat_namespace thing today, but I'll be at SC next week so not sure how much work will get done -- if you want to tag before that then I guess go for it. BTW: anyone else going to Salt Lake City for SC? -- John |
From: Derek G. <fri...@gm...> - 2012-11-09 22:10:58
|
On Fri, Nov 9, 2012 at 1:47 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > > FWIW, Roy and I were having some offline discussion, and as soon as 0.8.0 > is tagged I plan to merge automake. Like the next day… > The current plan is still to distribute a "prebuilt" configure script right? So that anyone checking out the code can just run ./configure, make and (optionally) make install? Also - did the the whole "opt and dbg" in the same tree thing get figured out yet? Derek |
From: Vikram G. <sim...@gm...> - 2012-11-09 20:51:37
|
Roy, Should we shoot for some kind of time dependent adjoint support before the release ? I think we have a first iteration of how to add that functionality figured out. Thanks. On Fri, Nov 9, 2012 at 3:47 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > > On Nov 9, 2012, at 2:33 PM, John Peterson <pet...@cf...> > wrote: > > > At this point, I'm fairly convinced that the only way to do shared > library linking **portably** is with libtool, but I haven't started on this > patch yet...and it will likely take a few iterations to get correct. > > FWIW, Roy and I were having some offline discussion, and as soon as 0.8.0 > is tagged I plan to merge automake. Like the next day… > > So keep that in mind, if automake is working for you then you might hedge > how much effort you put into the current trunk. > > -Ben > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > -- Vikram Garg PhD Candidate Institute for Computational and Engineering Sciences The University of Texas at Austin http://users.ices.utexas.edu/~vikram/ http://www.runforindia.org/runners/vikramg |
From: Roy S. <roy...@ic...> - 2012-11-09 20:56:15
|
On Fri, 9 Nov 2012, Vikram Garg wrote: > Roy, Should we shoot for some kind of time dependent adjoint support > before the release ? I think we have a first iteration of how to add that > functionality figured out. If we can get the first-pass stuff done and debugged before John's fixed that OSX weirdness, we should definitely get it in (since so far it looks like we'll only need to add a few new APIs, not change any existing code paths); if not then it can wait until 0.8.1 or 0.9.0. --- Roy |