[petsc-dev] New Year's renaming: DMComplex

[Jed Brown]

On Sat, Jan 5, 2013 at 8:49 PM, Tim Tautges <tautges at engr.wisc.edu> wrote:

> Too late to matter, but I wonder why there's such aversion to longer
> names.  Going from DMComplex to DMPlex goes from misleading to
> neutral/useless.  If you had to field questions about DMComplex, I don't
> think DMPlex is going to get rid of those questions much.  To me,
> DMCellComplex is the clear choice, or if you just can't bear the extra few
> characters, then DMMesh would be almost as good.


There was/is a DMMesh that DMPlex will eventually replace. "Mesh" is an
extremely generic and overloaded name, but DMPlex is really one (quite
general) mesh-related interface. It seems like every project has a
different idea about what the "mesh" is responsible for, so I think that
name is best avoided.

One reason for not-too-long names is that C [1] only guarantees
significance in the first 31 characters of an external identifier. Using a
long prefix reduces the number of meaningful characters left.

PETSc has quite few user-visible classes and we consider DMPlex to be a
building block for more "helpful"/specific DMs. These can usually be
moderately thin layers containing a DMPlex. For example, we're using DMPlex
in a finite volume CFD/heat transfer project and in PyLith (finite elements
with internal faults). It's important that the name be unique and
distinctive, but not that the name be a stand-alone explanation of the
component.

[1] Yes, C++ supports much longer identifiers (namespaces and argument
types are all mangled in), though this slows down the linker and dynamic
loader.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130105/487334b0/attachment.html>