Need implicit exodus node index in selection view
This issue was created automatically from an original Mantis Issue. Further discussion may take place here.
Here is a request from a user. I think he makes more sense than I do, so I am copying what he said. There is a dataset associated with this request, ask me for it. (blade1_full.exo)
We need to be able to ascertain the exodus node number even in the presence of a node map. The attached file has two important node numbers associated with each node:
- The exodus node index, which is implicitly numbered (1:N) on the model. It is used for all connectivity information.
- The global node id.
The situation is slightly different in parallel and serial. I will explain with an example. The attached example has a beam sticking out of the end of the blade. The last node on that beam is the 303 node in the exodus file. It's global ID is 4800705. The "selection inspector" properly reports its global node id (or pedigree id). Both the global node id and pedigree id are the same in version 3.4.0. However, it's point id has no connection to anything in the exodus model. The point id is zero.
The underlying exodus file lists this as the 303 node in the model. The 303rd entry in the node number map is 4800705. Thus, paraview knows the index and is associating the proper node id with the node, but it does not report the index of 303. This index is used in various other places, most importantly in the connectivity table. The connectivity for element block 480000 contains this index as is shown by grope.
GROPE> sele block 480000 GROPE> list connecti
Block***** (#2): 6 elements (3..8) 2-node 7 attributes # elem Connectivity 1 3 303 304 2 4 304 66 3 5 66 67 4 6 67 65 5 7 65 64 6 8 64 39
The same information can be seen (in another format) in the exodus file using either exotxt or ncdump. I can provide those if needed.
In parallel we need the same data, but the meaning is slightly different. In parallel, the node number map of the spread files points to the original exodus data numbering. Thus, in parallel (I believe) paraview will now return the number 303 for the global id. This is as it should be. But, now on the local subdomain, we should still be able to find the local exodus index which would depend of course on the decomposition.
I would suggest these values be labeled as follows. global id should return the same data it currently does. local id should return the index, i.e. 303 for the serial case.