|Anonymous | Login||2017-07-23 11:02 EDT|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008422||ParaView||Bug||public||2009-01-22 18:27||2011-01-13 17:00|
|Assigned To||Utkarsh Ayachit|
|Target Version||3.6.2||Fixed in Version||3.6.2|
|Summary||0008422: Need implicit exodus node index in selection view|
|Description||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:
1. The exodus node index, which is implicitly numbered (1:N) on the model.
It is used for all connectivity information.
2. 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.
|Tags||No tags attached.|
Ken Moreland (manager)
|I think this bug boils down to writing out special arrays for the implicit node and element indices (similar to the global indices or object ids). The data will not be visible in the selection inspector but will be visible in the spreadsheet view.|
Alan Scott (manager)
|Please talk to me before implementing. Alan|
Nathan Fabian (developer)
|I've added this and it works as expected for all the exodus files I've looked at (especially the ones above. There may be a number of caveats to how it works with older files. It should work well for serial files. The only really troubling ones are split exodus files which are not detectable from within ExodusIIReader (but are from withing PExodusIIReader). With a work around to detect split files, the caveats for older versions could probably be specialized.|
Utkarsh Ayachit (administrator)
Committing Nathan's fixes for BUG 0008422 to 3.6 branch
* Added implicit index arrays as requested in 8422. It is off by default
as there are currently a number of caveats to what numbers will show up
* XML changes to load implicit exodus arrays.
* Added the implicit variables to the exodus variable box, off by default.
/cvsroot/ParaView3/ParaView3/Qt/Components/pqExodusIIPanel.cxx,v <-- Qt/Components/pqExodusIIPanel.cxx
new revision: 126.96.36.199; previous revision: 188.8.131.52
/cvsroot/ParaView3/ParaView3/Servers/ServerManager/Resources/readers.xml,v <-- Servers/ServerManager/Resources/readers.xml
new revision: 184.108.40.206; previous revision: 220.127.116.11
/cvsroot/ParaView3/ParaView3/VTK/Hybrid/vtkExodusIIReader.cxx,v <-- VTK/Hybrid/vtkExodusIIReader.cxx
new revision: 18.104.22.168; previous revision: 22.214.171.124
/cvsroot/ParaView3/ParaView3/VTK/Hybrid/vtkExodusIIReader.h,v <-- VTK/Hybrid/vtkExodusIIReader.h
new revision: 126.96.36.199; previous revision: 188.8.131.52
/cvsroot/ParaView3/ParaView3/VTK/Hybrid/vtkExodusIIReaderPrivate.h,v <-- VTK/Hybrid/vtkExodusIIReaderPrivate.h
new revision: 184.108.40.206; previous revision: 1.6
/cvsroot/ParaView3/ParaView3/VTK/Hybrid/vtkExodusModel.cxx,v <-- VTK/Hybrid/vtkExodusModel.cxx
new revision: 220.127.116.11; previous revision: 1.8
/cvsroot/ParaView3/ParaView3/VTK/Hybrid/vtkExodusReader.cxx,v <-- VTK/Hybrid/vtkExodusReader.cxx
new revision: 18.104.22.168; previous revision: 1.56
/cvsroot/ParaView3/ParaView3/VTK/Hybrid/vtkPExodusIIReader.cxx,v <-- VTK/Hybrid/vtkPExodusIIReader.cxx
new revision: 22.214.171.124; previous revision: 1.27
Alan Scott (manager)
|Tested with can.exo, client/numerous servers, Linux.|
|2009-01-22 18:27||Alan Scott||New Issue|
|2009-02-17 16:42||Utkarsh Ayachit||Status||backlog => tabled|
|2009-02-17 16:42||Utkarsh Ayachit||Assigned To||=> Utkarsh Ayachit|
|2009-05-13 13:46||Utkarsh Ayachit||Target Version||=> 3.6|
|2009-08-24 13:18||Ken Moreland||Category||=> Bug|
|2009-08-24 13:18||Ken Moreland||Summary||Need exodus node index in selection view => Need implicit exodus node index in selection view|
|2009-08-24 13:20||Ken Moreland||Note Added: 0017185|
|2009-08-24 16:18||Alan Scott||Target Version||3.6 => 3.6.2|
|2009-09-01 15:11||Alan Scott||Note Added: 0017287|
|2009-09-28 19:53||Nathan Fabian||Note Added: 0017812|
|2009-10-01 14:10||Utkarsh Ayachit||Note Added: 0017875|
|2009-10-01 14:10||Utkarsh Ayachit||Status||tabled => @80@|
|2009-10-01 14:10||Utkarsh Ayachit||Fixed in Version||=> 3.6.2|
|2009-10-01 14:10||Utkarsh Ayachit||Resolution||open => fixed|
|2009-10-02 15:11||Alan Scott||Relationship added||has duplicate 0009341|
|2009-10-02 15:17||Alan Scott||Relationship added||related to 0009649|
|2009-10-02 15:19||Alan Scott||Note Added: 0017914|
|2009-10-02 15:19||Alan Scott||Status||@80@ => closed|
|2011-01-13 17:00||Source_changeset_attached||=> VTK master a2bd8391|
|2011-01-13 17:00||Source_changeset_attached||=> VTK master 020ef709|
|Copyright © 2000 - 2017 MantisBT Team|