On May 16, 2012, at 4:15 PM, Roy Stogner wrote: > On Wed, 16 May 2012, Derek Gaston wrote: > >> Why don't we _only_ renumber nodes and elements that are "beyond" >> the initial mesh. What I mean by that is this: >> >> a: Read mesh containing elements 4,3,1,2 (out of order on purpose) >> b: Refine some to create 5,6,7… leave 4,3,1,2 alone so we have this >> "ordering": 4,3,1,2,5,6,7 >> c: Coarsen later to remove 6 so now we have 4,3,1,2,5,_,7 >> d: Contract ONLY elements beyond the initial mesh so we would get >> 4,3,1,2,5,6 (where 7 has now become 6) > > Hmm... this is what already happens for SerialMesh, isn't it? It > ought to be doable for ParallelMesh too.
No! This isn't what happens for SerialMesh! The problem we're having is _with_ serial mesh. Go look at renumber_nodes_and_elements() around line 405 in unstructured_mesh.C… it very clearly renumbers _all_ nodes and elements. I actually don't care what happens to ParallelMesh right now. Our users know that there are certain restrictions when moving to ParallelMesh… but if they have a problem that needs it they are willing to take the trade off. > My first concern there is what happens when we're doing mesh > generation rather than reading a pre-numbered mesh from file. For > ParallelMesh creation of new nodes we start with them being as > *interleaved* as possible, with each processor p responsible for > handling the set ids which (mod n_procs+1) == p (with the n_procs+1 > case reserved for unpartitioned nodes and elements). I'd hate to > leave a mesh stuck with an initial numbering that was grossly > interleaved and sparse. > > Maybe leave the existing renumbering routine in there, to be called > for those cases, but add a new routine in that doesn't touch the first > Ne0,Nn0 nodes and elements? The idea is to store off the fact that we didn't want to renumber when we initialized…. and only then do the renumbering beyond the initial mesh. To be clear, this behavior would only happen when you do prepare_for_use(true)... > But then my second concern: we're capable of deleting (and ought to be > capable of adding) level 0 elements on the fly, it's just that the > library code never does so; it's the sort of thing that a user in a > variable domain problem would do by hand - picture an ablation problem > which combines mesh movement in the outermost cell layer with cell > deletion as the boundary passes that layer. I'd hate to offer a > "guarantee" that some numbers would go unchanged only to have to give > a few pages of fine print explaining under what conditions they'd > change. > > I suppose it wouldn't be the first situation requiring care by libMesh > users, though. Add "topologically unchanging initial meshes" to > "Lagrange elements", "unrefined meshes", "non-adaptively-refined > meshes", "serialized meshes", etc. on the list of "stuff that makes it > too easy to write code that will break when your discretization > requirements get more interesting. Yep - if you're changing the topology…. all bets are off. >> What do you think about my proposal? > > I don't have time to implement it myself, but as long as we still end > up doing initial renumbering on meshes which don't get their numbering > from a file, I do like the idea. Ok - I'm with you on this…. but I think it will be user selectable. i.e.... if you pass in "true" to prepare_for_use() there won't be any renumbering of the initial mesh _ever_ (With SerialMesh… ParallelMesh can do what it needs to). It is a "use at your own risk" kind of feature… The whole issue is that we have an API now where you can tell libMesh _not_ to renumber…. but then it will anyway the next time reinit() is called! That's inconsistent…. Derek ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
