From: Derek G. <fri...@gm...> - 2012-05-14 20:29:08
|
Ok - one more thing on this.... a question actually: Why do we need to "contract()" for SerialMesh? Shouldn't it be ok to have holes in the element / node numbering? Right now we kind of have weird behavior where nodes will be changing numbers all the time as we adapt the mesh (even if a node isn't destroyed and recreated it can be renumbered through contract() ). That seems like weird behavior that is kind of anti-user. For instance, what if you want to track the value of a variable at a node that is created through refinement? You probably can't do that with our current system because that node number will be changing all the danged time.... right? Derek On Mon, May 14, 2012 at 1:07 PM, Derek Gaston <fri...@gm...> wrote: > Also, on a related note, it looks like in equation_systems.C around line > 194 sets "mesh_changed = true"... no matter what. > > So calling eq->reinit() will cause a mesh.contract() _no matter what_... > even if you haven't modified the mesh. Meaning that just calling > eq->reinit() you will get your nodes and elements renumbered! > > It looks like this is in there because of backwards compatibility... > > Derek > > > On Mon, May 14, 2012 at 12:37 PM, Derek Gaston <fri...@gm...> wrote: > >> Around line 1100 in unstructured_mesh.C in UnstructuredMesh::contract() >> it calls renumber_nodes_and_elements() >> >> This is a bad idea. >> >> We've initialized our meshes by skipping renumbering... but then calling >> eq->reinit() causes all of the nodes / elems to then be renumbered. >> >> Any ideas for what to do here? Should we make a separate function to >> remove the NULLs out of the element / node vectors but keep the numbering >> the same? >> >> Should we just not renumber if we skipped renumbering when we initialized >> the mesh? >> >> Derek >> > > |