MantisBT - ParaView
View Issue Details
0004752ParaView(No Category)public2007-04-02 11:492009-05-13 13:59
David Karelitz 
Berk Geveci 
normalmajoralways
closedfixed 
 
3.43.4 
0004752: Node/side sets and no compositing weirdness
Running in parallel, if I load an exodus file, turn off compositing, and turn on a node set, the coloring by BlockID becomes wrong. Selecting cells shows they have the correct BlockID though.
No tags attached.
Issue History
2007-08-13 16:44Berk GeveciAssigned ToDave DeMarle => Berk Geveci
2007-08-13 16:44Berk GeveciPrioritynormal => high
2007-08-13 16:44Berk GeveciStatusbacklog => tabled
2007-08-23 17:10Berk GeveciCategory => 3.2
2007-09-12 13:19Berk GeveciNote Added: 0008943
2007-09-12 13:19Berk GeveciStatustabled => @20@
2007-09-12 13:20Berk GeveciNote Added: 0008944
2007-09-12 16:21Ken MorelandNote Added: 0008950
2007-10-12 13:27Berk GeveciPriorityhigh => normal
2008-04-08 16:34Berk GeveciStatus@20@ => tabled
2008-04-08 16:34Berk GeveciAssigned ToBerk Geveci => David Karelitz
2008-04-08 16:34Berk GeveciAssigned ToDavid Karelitz => Berk Geveci
2008-04-08 16:34Berk GeveciCategory => 3.4
2008-05-01 13:57Berk GeveciStatustabled => @80@
2008-05-01 13:57Berk GeveciResolutionreopened => fixed
2008-05-05 21:06Alan ScottStatus@80@ => closed
2008-05-05 21:06Alan ScottNote Added: 0011717
2009-05-13 13:58Utkarsh AyachitTarget Version => 3.4
2009-05-13 13:59Utkarsh AyachitFixed in Version => 3.4
2011-06-16 13:10Zack GalbreathCategory => (No Category)

Notes
(0007178)
user521   
2007-04-06 12:56   
The color map is being rescaled to fit the new range of block ids. For example, open up can.ex2, it has blockid 1 and 2. If the color scale editor (open up display tab, edit color map) has "Automatically Rescale to Fit Data Range" on, then the colors will change as soon as a nodeset is turned on because the nodeset has blockid 0.
(0007229)
Ken Moreland   
2007-04-10 15:43   
This is, in fact, a bug. Here is an easy way to replicate it:

1. Start ParaView client/server with at least 2 process on the server.
2. Load the can data set with the default options. Observer the coloring of the block ids.
3. Run the data through the D3 filter (everything will still be fine).
4. Change the exodus reader to load "NodeSet 1". At this point, it will render correctly when compositing, but the colors will be dorked if geometry is delivered to the client.

I'm lowering the priority of this bug slightly because there are many more important ones to address right now.
(0008943)
Berk Geveci   
2007-09-12 13:19   
D3 is getting confused because the global element ids of vertices in the nodeset are not unique. To verify, load can, turn off all blocks, turn on a nodeset, color by PedigreeElementID. You will see that all vertices have the same pedigree (and global) id of 0. I don't know what the solution is. Do we change exodus reader to produce unique ids for vertices? Do we disable generation of global element ids?
(0008944)
Berk Geveci   
2007-09-12 13:20   
Reminder sent to: Ken Moreland

Ken, can you take a look at my latest note?
(0008950)
Ken Moreland   
2007-09-12 16:21   
I also see that the cell ids for the point set have invalid global ids. This pointed out a bug in D3 that I found and I'll try to check in the change tomorrow if I remember. It fixes the problem in this instance, but not in all instances since I think D3 will still try to use global cell ids when ghost cells are created.

I cannot remember what the plan was to handle missing global ids for sets. I think it is to punt until multiblock is supported. Eric might know better.
(0011717)
Alan Scott   
2008-05-05 21:06   
Looks correct to me. Tested client/server.