On Sep 15, 2009, at 12:45 PM, John Peterson wrote: > MeshRefinement::refine_and_coarsen_elements() and friends return a > boolean which is true if the Mesh changed. Is that of any use to you?
Not really... it's not trivial to pass around a bool to every piece that does caching to tell it to invalidate it's cache and recache. It would be better if each place that did that could just do a test to see if it's cache should be invalidated. But the bool from refine_and_coarsen _will_ help with the use-case I specified where we need to know to start a new Exodus file... so thanks (to you and Ben) for the tip! > 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. How about instead of a "mesh changed" counter... we provide a "mesh changed because of a call to refine_and_coarsen" counter. Then it's obvious that it only covers that case... and if you are doing something more advanced you need to deal with it on your own. But... like you say... this is getting a bit specific so maybe it's not a good candidate for library code. What I might do instead is abstract this out with my own function that calls refine_and_coarsen and increments a counter... and then get all of my applications to use that. Not fool proof... but better than the current situation. Derek ------------------------------------------------------------------------------ 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
