On Wed, 27 Feb 2008, John Peterson wrote:
> Shengli Xu writes: > > Hello, libmesh users, > > > > The node number is not the same with that in the input unv file in > > libmesh-0.6.2 > > > > ... > > > > Is this a bug? If not, How can I let the node number in libmesh-0.6.2 to be > > the same as the input file? > > > > In general, we have never guaranteed that would be the case. If it > happened to be in one version of libmesh I guess that was just lucky. > LibMesh's mesh data structure needs to do various operations which > sometimes require renumbering nodes and elements. There's no way > we could support 5-10 different input file formats while maintaining > the numbering in all of them. We definitely don't support fixed node numbers through many operations. Refinement, repartitioning, etc. all need to change node and element numbers, because we keep those numbers in contiguous ranges on each processor. However, we probably ought to be able to preserve the node numbers from a file format at the initial Mesh::read, even if we have to do a mediocre initial partitioning (i.e. the contiguous ranges of element numbers become the partition) to do so. That would allow people who have tacked on nodal/element data vectors to associate that data with nodes/elements properly rather than just with their numbers before the mesh is next altered. It's up to Ben, though, I think; I don't have enough experience digging around in our I/O code. --- Roy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
