Re: [Libmesh-devel] libmesh-0.5.0

[John P. <pet...@cf...>]

Roy Stogner writes:
 > On Tue, 1 Mar 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote:
 > 
 > > It's high-time for out next release, but I don't want to be too hasty.
 > 
 > Neither do the sourceforge mailing list servers, apparantly... am I
 > the only one who occasionally gets libmesh-* 12 or 24 hours late?

I do as well.  Not all the time, as you say, but sometimes.  I usually
get two copies of everything too, but I think I might have two email
addresses subscribed to the list on accident.


 > > Roy has made some significant changes & getting these out in a
 > > "blessed" release would be a *good thing*.  There are a couple of
 > > other things that should happen before this release as well:
 > 
 > "Blessed" release?  What good is a blessed release?  I only uploaded
 > two crippling bugs to CVS this week, and I had those each fixed within
 > a day or so; surely Real Programmers would have been able to work
 > around them anyway.  ;-)

You provided good customer support though.  Those are the kind of bugs I
don't mind so much :)  BTW, where do I sign up for the "Real Programmers"
class??


 > > 1.) Settle on improved UI for implementing solvers.  We had a good
 > > discussion about deriving classes that implement the assemble() method, but
 > > we need to firm this up.
 > 
 > This is definitely important, but probably not necessary for the next
 > release.  Getting the UI just right the first time might be unlikely,
 > and it would be nicer to users if we got the UI right before it left
 > CVS.
 > 
 > I'm not sure just how easy we can make things for the user, for
 > example.  I've got a little framework on top of deal.II that abstracts
 > away most of the assembly function into common code and gives 
 > problem-specific code the option to write element residual and
 > Jacobian functions... and even those are provided and can be reused
 > for common operators, or you can just write the element residual and
 > then let my framework use finite differencing for the Jacobian.  It
 > would nice to have something similarly easy to use in libMesh, but my
 > deal.II code isn't as well-designed or nearly as efficient as it
 > should be, and figuring out a better interface may take a while.

I agree that this is not super-important.  In "most" cases, having access
to the EquationSystems object gives you enough information, e.g. just
pulling values out of the parameters object is usually sufficient.  I can
understand the need to possibly access class member functions in your assembly
routine for a well-written C++ application, but I take the stance that
people can use global functions for a little while until we work out
the more important issues.


 > > 2.) Handle solution restriction/prolongation for non-Lagrange element types.
 > 
 > This is IMHO the most important thing we need before any of my
 > adaptivity code can go in a new release - right now I think if you try
 > to do a time-dependent adaptive problem with non-Lagrange elements and
 > you coarsen any elements it'll just silently introduce errors.

As far as release goes, I guess I don't mind if errors are introduced for
non-Lagrange elements ... as long as they aren't silent.  How much work
would it be to print warnings/errors in these cases?  If we aren't worried
about meeting a specific release date, I'd say just wait until we have this
working for 0.5.