View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0016006 | ParaView | (No Category) | public | 2016-02-19 20:34 | 2016-08-12 10:00 | ||||
Reporter | Alan Scott | ||||||||
Assigned To | Kitware Robot | ||||||||
Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
Status | closed | Resolution | moved | ||||||
Platform | OS | OS Version | |||||||
Product Version | 5.0 | ||||||||
Target Version | 5.1 | Fixed in Version | |||||||
Summary | 0016006: Spreadsheet block numbers are offset by 1 | ||||||||
Description | Something is naming the unnamed blocks as 1 based (Unnamed block ID: 1…, Unnamed block ID: 2) in exodus datasets (such as can.exo). This 1 based numbering scheme is used in the Properties tab, and the Information tab. Further, in the Information tab, you find ElementBlockIds goes from 1 to 2. This is probably OK. EnSight does the same. So does an internal Sandia tool named ncdump (sort of). Now, create a spreadsheet view. Notice the block number – it is offsfet by 1! So, we now have block numbers 2 and 3. I think this is a bug, and needs to be fixed. | ||||||||
Tags | No tags attached. | ||||||||
Project | Sandia | ||||||||
Topic Name | |||||||||
Type | incorrect functionality | ||||||||
Attached Files | |||||||||
Relationships | ||||||
|
Relationships |
Notes | |
(0035759) Alan Scott (manager) 2016-02-22 17:30 |
From an email with Utkarsh: ... I should explain what's happening. The "Block Number" shown in the the SpreadSheet view is not Exodus block number. VTK (and ParaView) numbers blocks in a multiblock dataset using a unique indexing scheme which makes it possible to identify a block irrespective of the hierarchy. Every exodus block is mapped to a single block in VTK, however other objects from Exodus such as side sets, face sets, etc. also get mapped to a block in VTK. Thus, if VTK representation of exodus data stuck with using Exodus block ids alone, it couldn't' identify the blocks associated with side sets etc. To help refer back to the exodus block number/sideset number etc, the Exodus reader adds a "cell data" array named "ObjectId". Note this is only added as cell data and hence shown in the spreadsheet view only when looking at cell data. Here's a potential fix: + rename current Block Number to be something more unique eg. "VTK Block Number" + make exodus reader put an ObjectId for point data as well. + hide "VTK Block number" from the spreadsheet view when "Objectid" is present. OK, Alan here. Lets go with Utkarsh's fix above. Further, lets rename ObjectId to something reasonable - like Block Number! |
(0035760) Alan Scott (manager) 2016-02-22 17:31 |
From another e-mail thread - Note that in the "block number", the offset is intentional. The offset of block # by 1 is not a bug - it is intentional. Load can.e Edit/Find Data Change criteria to ObjectId, so that the BlockID selector appears: Click on drop down list for selecting blocks Note that Block #1 is ALL element blocks - this is a special value which is the default value used for blocks in Find Data (and possibly elsewhere?) - Block #1 includes both element blocks in the model (block IDs 1 &2, which are block numbers 2 & 3). We need to be careful that Find Data and any other routines which depend on Block Number 1 being a special code meaning "all element blocks" aren't broken by any changes we make. I'm not sure that this choice for a special code was prudent, but it exists, so we need to be mindful of it. |
(0035839) Alan Scott (manager) 2016-03-14 18:49 |
OK, I think I know what I want. Please do the following: * Rename current Block Number (i.e., internally generated VTK block number) to be "VTK Internal Block". * Change the name of "ObjectId" (which doesn't mean anything to anyone) to "Block Number". * Have the Exldus reader put a Block Number (formerly Object Id) on all points. Make this user selectable. * Hide the VTK Internal Block when Block Number (formerly ObjectId) is present. Test by looking in the Spreadsheet View, and with Find Data. |
(0035945) Alan Scott (manager) 2016-05-10 20:52 edited on: 2016-05-10 20:53 |
I have yet another user being confused by this. Needs to be fixed. I added it to trello. |
(0039004) Kitware Robot (administrator) 2016-08-12 10:00 |
Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current ParaView Issues page linked in the banner at the top of this page. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2016-02-19 20:34 | Alan Scott | New Issue | |
2016-02-19 20:35 | Alan Scott | Target Version | => 5.1 |
2016-02-19 20:35 | Alan Scott | Description Updated | |
2016-02-22 17:30 | Alan Scott | Note Added: 0035759 | |
2016-02-22 17:31 | Alan Scott | Note Added: 0035760 | |
2016-02-22 17:40 | Alan Scott | Relationship added | related to 0016008 |
2016-03-14 18:49 | Alan Scott | Note Added: 0035839 | |
2016-05-10 20:52 | Alan Scott | Note Added: 0035945 | |
2016-05-10 20:53 | Alan Scott | Note Edited: 0035945 | |
2016-08-12 10:00 | Kitware Robot | Note Added: 0039004 | |
2016-08-12 10:00 | Kitware Robot | Status | backlog => closed |
2016-08-12 10:00 | Kitware Robot | Resolution | open => moved |
2016-08-12 10:00 | Kitware Robot | Assigned To | => Kitware Robot |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |