(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 (manager)
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 (administrator)
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 (administrator)
2007-09-12 13:20

Reminder sent to: Ken Moreland

Ken, can you take a look at my latest note?

(0008950)
Ken Moreland (manager)
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 (manager)
2008-05-05 21:06

Looks correct to me. Tested client/server.

Issue History
Date Modified	Username	Field	Change
2007-08-13 16:44	Berk Geveci	Assigned To	Dave DeMarle => Berk Geveci
2007-08-13 16:44	Berk Geveci	Priority	normal => high
2007-08-13 16:44	Berk Geveci	Status	backlog => tabled
2007-08-23 17:10	Berk Geveci	Category	=> 3.2
2007-09-12 13:19	Berk Geveci	Note Added: 0008943
2007-09-12 13:19	Berk Geveci	Status	tabled => @20@
2007-09-12 13:20	Berk Geveci	Note Added: 0008944
2007-09-12 16:21	Ken Moreland	Note Added: 0008950
2007-10-12 13:27	Berk Geveci	Priority	high => normal
2008-04-08 16:34	Berk Geveci	Status	@20@ => tabled
2008-04-08 16:34	Berk Geveci	Assigned To	Berk Geveci => David Karelitz
2008-04-08 16:34	Berk Geveci	Assigned To	David Karelitz => Berk Geveci
2008-04-08 16:34	Berk Geveci	Category	=> 3.4
2008-05-01 13:57	Berk Geveci	Status	tabled => @80@
2008-05-01 13:57	Berk Geveci	Resolution	reopened => fixed
2008-05-05 21:06	Alan Scott	Status	@80@ => closed
2008-05-05 21:06	Alan Scott	Note Added: 0011717
2009-05-13 13:58	Utkarsh Ayachit	Target Version	=> 3.4
2009-05-13 13:59	Utkarsh Ayachit	Fixed in Version	=> 3.4
2011-06-16 13:10	Zack Galbreath	Category	=> (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 (manager) 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 (administrator) 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 (administrator) 2007-09-12 13:20	Reminder sent to: Ken Moreland Ken, can you take a look at my latest note?

(0008950) Ken Moreland (manager) 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 (manager) 2008-05-05 21:06	Looks correct to me. Tested client/server.

Relationships