On Sep 15, 2009, at 11:40 AM, Roy Stogner wrote: > Is this a sufficient definition of "mesh has changed" for you? You > guys are trying to cache out some collision/intersection detection > info, IIRC? In which case moving nodes would be just as much of a > change as creating new nodes is.
Nah - this isn't for collision / intersection purposes. One place this comes up is with Exodus output. You can continue to write transient timesteps to the same Exodus file... UNTIL THE MESH CHANGES. Then you have to start a new file. Currently, there's not an easy way for my output routines to know that the mesh has changed since the last time a solution was output. There are some other things we do as well... but this is one use case that others might utilize. > This sounds reasonable. I'd worry about non-MeshRefinement objects > trying to directly do refinement/coarsening, but there's already loads > of stuff that might break if someone tried that. Yeah - I don't think people are really manipulating the mesh data structure directly very often. The only place that I could see that coming up is "element death" where you delete elements if the solution on them reaches a certain criteria (like too much stress for fracturing). But I'm not aware of anyone doing that with libMesh.... I might work something up for this... 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
