Re: [Libmesh-devel] Reorganization in libMesh SVN head

[Roy S. <roy...@ic...>]

On Mon, 2 Nov 2009, Roy Stogner wrote:

> In other words, the next time I break libMesh ("svn blame"...
> "roystgnr thought it was a good idea to break aclocal.m4 into a bunch
> of files in an m4/ subdirectory??") for no short-term benefit, I'm
> blaming peer pressure.

And folks are already using and even updating the new m4 files with
nary a complaint, huh?

In case anyone wants to stop me before I go mad with power, here's
some of what's in the more distant future in Roy's Crazy Ideas List:

Deprecating START_LOG/STOP_LOG and putting their functionality into
the constructor/destructor for some new logging class.  Same
justification as for the libMesh::init()->LibMeshInit change: RAII is
neat.  This would prevent the sort of bugs where the strings you hand
to STOP_LOG don't match the ones you gave to START_LOG, as well as the
ones where you miss doing a STOP_LOG at every return point from a
function.  It would also make logging exception-safe, in case we or
any users want to make more sophisticated use of exceptions than
the present "clean up more nicely before dying".

Does anyone use any of the Linear, Nonlinear, Adaptive, or Solver
classes?  They look like a good idea which nobody's bothered to finish
implementing for years, excepting for the parts that have been
implemented in other classes which make them redundant.  I'd like to
just remove them entirely.

Boost integration.  I assume people might have objections to seeing a
new external dependency added and a bunch of incompatible API changes
made, just because I think boost::shared_ptr is really neat?  We'll
stick with raw pointers in places like Elem where performance is
critical, but for Strategy Pattern type stuff both raw pointers and
auto_ptrs are often a hassle.  I could write a simple SharedPtr to
give us something to automatically fall back on when boost isn't
available.  Likewise, Array2D could fall back on an implementation
like the std::vector<std::vector> data we've got all over, but would
be typedef'ed to boost::multi_array<T, 2> when boost is available.

Giving phi, dphi, etc their own data types instead of vector<vector>.
I was recently told that we might be able to speed up assembly a bit
via loop reordering and changing the storage order of those arrays,
and if that turns out to be true then it might be worth the API
breakage.  Switching to our own typedef or even just to a multi_array
would break the API once, but would allow us to retweak the internals
at compile time in the future without any subsequent API breakage.
---
Roy