View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0016006ParaView(No Category)public2016-02-19 20:342016-08-12 10:00
ReporterAlan Scott 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version5.0 
Target Version5.1Fixed in Version 
Summary0016006: Spreadsheet block numbers are offset by 1
DescriptionSomething 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.

TagsNo tags attached.
ProjectSandia
Topic Name
Typeincorrect functionality
Attached Files

 Relationships
related to 0016008closedKitware Robot Block number insanity saving/ reading exodus data. 

  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.

 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


Copyright © 2000 - 2018 MantisBT Team