>> 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.
I actually came across this when doing AMR on the BIO problem with refinement at every time step. It was somewhat related in that I found often you could call mesh_refinement.refine... and due to maximum element refinement levels the mesh would not actually change, hence you need not reinit the equation systems. note the function prototype: bool MeshRefinement::refine_and_coarsen_elements (const bool maintain_level_one = true) Pretty sure this already does what you want, you just need to catch the return value? -Ben ------------------------------------------------------------------------------ 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
