>>> 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. Yep. The most constant single identifier for a node is probably its memory address, and even that is not guaranteed in parallel with redistribution. (The nodal coordinates are OK, but they don't survive scaling etc...) There are simply too many operations which require array-based communication with other processors, and the only way to implement this efficiently (that we have found) is to implicitly tie node and element numbers to the parallel partitioning. > 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. At the cost of an additional 4 bytes (plus more if padded :-( ) I would probably lean toward Node/Elem::label() or something like that. This could be an unsigned int which stores the node or element index as read from file. This raises a couple of issues, though... (i) what to do for nodes/elements created through refinement? (ii) the burden would be on the user to create an efficient lookup structure, or to call MeshTools::create_label_map() or something. Specifically, since the Mesh makes no use of such labels I would not want to incur the storage overhead of keeping such a lookup table around. -Ben ------------------------------------------------------------------------- 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
