Re: [Libmesh-devel] Detect Mesh Changed

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

On Tue, Sep 15, 2009 at 12:19 PM, Derek Gaston <fri...@gm...> wrote:
> Guys,
>
> I've been struggling for a while now with a way to detect (reliably)
> that the mesh has changed.  What I do now is force all of the
> applications that use my code to call a function anytime they call one
> of the refinement/coarsening functions.  As you can imagine this
> relies on them doing the correct thing... which isn't always the best
> idea.

MeshRefinement::refine_and_coarsen_elements() and friends return a
boolean which is true if the Mesh changed.  Is that of any use to you?


> Could we add a counter to the mesh that says the number of times it's
> changed?  And have that counter get incremented every time one of the
> refine / coarsen functions gets called on a mesh?  This way different
> parts of the code could query to see if the number of times the mesh
> has changed... has changes. (hmmm).
>
> BTW: I'm of course doing these types of activities in the name of
> speed.  There are certain things that I can cache... but are dependent
> on the mesh staying the same.
>
> Thoughts?

I've thought about doing this before, but unfortunately it's very hard
to get absolutely correct in the library (at least, without a major
re-design of the Mesh).  You can try and cover all the most common
cases, or at least the ones that crop up in your own code, but it's
very difficult to catch every possible way a user can change the Mesh.

One example:  Mesh::node(unsigned).  We have to assume the user could
do anything with the Node& returned, and therefore we have to mark the
mesh as changed, but then what if he doesn't actually change it?  All
our caching goes out the window...  Another good example is the
AutoPtr<BoundaryInfo> which sits there as a public data member of the
Mesh.  Anything could happen to it and therefore technically change
the Mesh, but we won't know because we don't control access to it in
any way.  Any non-const iteration over the elements or nodes could
lead to a change....

Therefore I don't know if this is something appropriate for library
code...I usually err on the side of lacking functionality when the
alternative is very useful looking but incompletely implemented
functionality that can lead to bugs later when people (rightfully!)
use the code in new and unexpected ways.  This could be *very* useful
in applications, though, since presumably an application writer has
the closest control over when he actually changes the Mesh, regardless
of what calls are made internally in the library.


-- 
John