Just realized I forgot to Cc: this to the list...
On Wed, 31 Oct 2007, Benjamin Kirk wrote:
> The MeshCommunication class can now restore (serialize) a ParallelMesh which
> has been previously split up amongst processors. I still need to implement
> serializing the BCs, but this is not a big deal.
Our next real step ought to be parallelizing DofMap::reinit; but as an
interim measure we might wrap the bulk of EquationSystems::reinit in a
"if mesh is parallel, serialize it, do my thing, and parallelize it
again" loop. This would allow people who are interested to start
saving a bit of memory immediately (if we clear sparse matrices before
serialization, that is), and it would make it easier to start testing
> Next the EquationSystems needs to be reworked to take a MeshBase instead of
> a Mesh. Roy, were you working on this? I seem to recall you mentioned this
> would require a slight API change.
Yes; most of the work didn't require an API change and has already
been committed; I'll commit the MeshBase-using equation_systems.h
> While we are on the subject of API change, there is one longstanding one I
> would like to implement before the next release.
> In general I don't really like the 'class Foo : public FooBase' habit we
> seem to be in, but maybe I am being picky.
I like your new naming habit better in general, but I don't think it's
worth breaking people's code over. Here's my thoughts in descending
order of politeness:
> current SerialMesh --> SerialUnstructuredMesh ?? maybe
> current ParallelMesh --> ParallelUnstructuredMesh ?? Maybe
I just chose shorter names because I think that unstructured meshes
are the only ones for which a serial/parallel distinction makes
perfect sense. For the hypothetical cartesian mesh class, etc. that
we've talked about, when we're recreating Elem objects on the fly
there's just no data storage to parallelize.
On the other hand, it's conceivable that we'd one day want block
structured meshes or a "coarse mesh + refinement tree saved" mesh
class with on the fly fine Elem creation, and either of those might be
usefully parallelized. Changing these names is fine by me.
> current PointLocatorBase --> PointLocator
I suppose only "power users" are
handling PointLocator objects, so a name change there is relatively
> current Mesh --> UnstructuredMesh (already done).
Not exactly; this was more of a refactoring than a name change. An
UnstructuredMesh has pure virtuals, so obviously it's not an exact
equivalent of the old Mesh. The exact equivalent of the old Mesh is
Mesh, actually, and I went to a little annoying trouble to keep
typedefs compatible to make that work. It was an ABI-breaking but not
an API-breaking change.
> current MeshBase --> Mesh
This change I'm totally against. Renaming MeshBase->Mesh would break
everybody's application code, wouldn't it? MeshBase is an abstract
base class, but constructing a Mesh object is practically the first
thing every program does.