| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0005979 | ParaView | (No Category) | public | 2007-10-30 21:29 | 2009-05-13 13:59 | ||||
| Reporter | Alan Scott | ||||||||
| Assigned To | Utkarsh Ayachit | ||||||||
| Priority | high | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | 3.4 | Fixed in Version | 3.4 | ||||||
| Summary | 0005979: Component names stripped and modified for vectors or tensors in exodus files | ||||||||
| Description | Component names are being stripped in the exodus reader. For instance, I have a file (litho2D.exo, scico/~, not released) that shows this. For instance, ParaView 3.0.2 correctly reads in STRESS_1_XX, STRESS_1_YY, STRESS_1_ZZ, STRESS_1_XY, STRESS_1_YZ and STRESS_1_XZ. ParaView 3.2.0 reads this in and displays it as Stress_1_. The calculator then incorrectly shows these components as STRESS_1_0, STRESS_1_1, STRESS_1_2, STRESS_1_3, STRESS_1_4, STRESS_1_5, and STRESS_1_6. This is an important one to fix in 3.4. It is keeping my user from upgrading from 3.0.2. Ask me for the file to replicate this one. May not go outside. | ||||||||
| Tags | No tags attached. | ||||||||
| Project | |||||||||
| Topic Name | |||||||||
| Type | |||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0009594) David Karelitz (reporter) 2007-10-31 13:07 |
Some clarification. The exodus reader should do what it's doing (converting scalars into tensors and vectors). There should be the ability to color an object by an individual component of a vector or tensor (with the component indices labelled using x,y,z and xx,xy,xz,yy,yz,zz) Similarly anywhere else a component indice shows up for a vector or tensor, it should use x,y,z, or xx,xy,xz,yy,yz,zz. The only other location I can think of where this occurs is the calculator. We should think about what to do for other filters as well, such as threshold and contour. The other option to all of this is to have the exodus reader output the scalar array as well as the vector or tensor; however, this uses double the memory. |
|
(0011560) David Thompson (old) (reporter) 2008-04-27 14:21 |
This is not a simple fix. Arrays that are not symmetric rank 3 tensors may have 6 components (and thus should not have xx,yy,zz,xy,xz,yz labels). Because of the way vtkDataSetAttributes is defined, only a single point array and a single cell array can be marked as tensors per dataset. There needs to be a convention for marking array "purpose" or "intent" beyond what vtkDataSetAttributes provides. (Side note: some changes are also due to vtkDataSetAttributes to support multitexturing... we need a way to indicate multiple texture coordinate arrays.) There are several ways to fix this: 1. Hack. We could perhaps get by with a change to the PV3 "Display" tab and colormap dialog; plus a change to the array calculator. This seems like a short term fix at best, and as I mention above, may not be desirable in all cases. 2. Extend vtkDataArray to accept component names. This could be done in two ways. 2.a. Use vtkInformation in vtkDataArray to indicate component names. There is already a PER_COMPONENT() key used to store the range of each component. The problem here is that the information is not currently copied when arrays are shallow/deep copied. 2.b. Store component names directly. This seems like the simplest thing to do but would increase the footprint of vtkDataArray even when no component names are stored. 3. Extend vtkDataSetAttributes to allow multiple arrays to be marked SCALAR, VECTOR, TEXTURE, TENSOR, etc. but still single some out as "active". The problem here is that there's an existing API which expects a single array to be active at a time and many filters use it. |
|
(0012154) David Thompson (old) (reporter) 2008-05-29 14:05 |
Berk, I'd like some feedback on the various alternatives I proposed (or some more alternatives if you don't like any of the ones already there). I'm happy to change the Exodus reader to accommodate any of the fixes but clearly the main part of the fix will be outside the reader. |
|
(0012155) Ken Moreland (manager) 2008-05-29 14:31 |
Dave, I think you've made this request way more complicated than it needs to be. The request was simply to combine the six Exodus arrays into a single field array. Don't worry about registering the active tensors in vtkDataSetAttributes. ParaView doesn't use the active scalars/vectors/tensors anyway. Also don't worry about how the calculator handles them. It should just treat them as a single vector. I think it's always done that, and that's OK. I like the idea of using the vtkInformation in vtkDataArray to store component names, but that is orthogonal to the issue addressed by this bug. |
|
(0012156) David Thompson (old) (reporter) 2008-05-29 14:50 |
Ken, the Exodus reader is already combining (has always combined) the 6 arrays into a single field. The only difference is that ParaView *used* to display the components in the color-by-scalar dialog as the array name plus _X, _Y, _Z, _XY, _XZ, or _YZ but now just uses _0, _1, ..., or _5. |
|
(0012552) Utkarsh Ayachit (administrator) 2008-06-27 08:30 |
6 component vectors are now labelled as [XX, YY, ZZ, XY, XZ, YZ]. The color component chooser as well the calculator use this convention while naming components. /cvsroot/ParaView3/ParaView3/Applications/Client/Testing/XML/Calculator.xml,v <-- Applications/Client/Testing/XML/Calculator.xml new revision: 1.11; previous revision: 1.10 /cvsroot/ParaView3/ParaView3/Qt/Components/pqCalculatorPanel.cxx,v <-- Qt/Components/pqCalculatorPanel.cxx new revision: 1.22; previous revision: 1.21 /cvsroot/ParaView3/ParaView3/Qt/Components/pqColorScaleEditor.cxx,v <-- Qt/Components/pqColorScaleEditor.cxx new revision: 1.48; previous revision: 1.47 /cvsroot/ParaView3/ParaView3/Qt/Components/pqDisplayColorWidget.cxx,v <-- Qt/Components/pqDisplayColorWidget.cxx new revision: 1.33; previous revision: 1.32 /cvsroot/ParaView3/ParaView3/Qt/Core/pqScalarBarRepresentation.cxx,v <-- Qt/Core/pqScalarBarRepresentation.cxx new revision: 1.7; previous revision: 1.6 /cvsroot/ParaView3/ParaView3/Qt/Core/pqScalarBarRepresentation.h,v <-- Qt/Core/pqScalarBarRepresentation.h new revision: 1.6; previous revision: 1.5 |
|
(0012588) Alan Scott (manager) 2008-06-30 19:43 |
Terrific!!! Tested client/server. |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2007-10-30 21:29 | Alan Scott | New Issue | |
| 2007-10-31 13:07 | David Karelitz | Note Added: 0009594 | |
| 2008-04-08 11:25 | Ken Moreland | Assigned To | => David Thompson (old) |
| 2008-04-08 11:25 | Ken Moreland | Status | backlog => tabled |
| 2008-04-08 11:25 | Ken Moreland | Category | => 3.4 |
| 2008-04-27 14:21 | David Thompson (old) | Note Added: 0011560 | |
| 2008-05-29 14:04 | David Thompson (old) | Assigned To | David Thompson (old) => Berk Geveci |
| 2008-05-29 14:05 | David Thompson (old) | Note Added: 0012154 | |
| 2008-05-29 14:31 | Ken Moreland | Note Added: 0012155 | |
| 2008-05-29 14:50 | David Thompson (old) | Note Added: 0012156 | |
| 2008-05-29 15:40 | Berk Geveci | Assigned To | Berk Geveci => David Thompson (old) |
| 2008-06-05 08:33 | Berk Geveci | Assigned To | David Thompson (old) => Utkarsh Ayachit |
| 2008-06-27 08:30 | Utkarsh Ayachit | Status | tabled => @80@ |
| 2008-06-27 08:30 | Utkarsh Ayachit | Resolution | open => fixed |
| 2008-06-27 08:30 | Utkarsh Ayachit | Note Added: 0012552 | |
| 2008-06-30 19:43 | Alan Scott | Status | @80@ => closed |
| 2008-06-30 19:43 | Alan Scott | Note Added: 0012588 | |
| 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) |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |