On Tue, Sep 15, 2009 at 12:19 PM, Derek Gaston <[email protected]> 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 ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
