DBOPT_COORDSYS problems in test data and VisIt #17187
Labels
bug
Something isn't working
impact medium
Productivity partially degraded (not easily mitigated bug) or improved (enhancement)
likelihood medium
Neither low nor high likelihood
priority
a priority ticket
reviewed
Issue has been reviewed and labeled by a developer
Problem with data
The test file
curv2d.silo
indicates its mesh is using a coordinate system ofcylindrical
. However, if you look at the actual code,visit/src/tools/data/datagen/testall.C
Lines 802 to 807 in 18868ba
that computes the coordinate data, it is not putting
r
andtheta
into the coordinate arrays. It is computing the cartesian coordinates and putting those values in the coordinate arrays.Next, even when I have corrected for this, VisIt will wind up plotting the data incorrectly. It will plot the mesh as though the coordinate data is
x/y
notr/theta
. I have a new example I've started as part ofquad_disk.C
where I do something similar.Problem with VisIt
I can see a few answers here...
cylindrical
tocartesian
before VisIt even sees the data.I would appear we do both of these. For 2D Unstructured and Structured mesh with
coordsys
set toDB_CYLINDRICAL
, we set themesh_type
toAVT_RZ
inavtMeshMetaData
. When we eventually go to read the coordinates of the mesh, I think (I have yet to confirm this) we pass the coordinate data from the file onto VisIt unchanged meaning that VisIt is getting arrays ofr/theta
values.visit/src/databases/Silo/avtSiloFileFormat.C
Lines 1815 to 1819 in 18868ba
For Curves and 3D quad meshes, we appear to convert to cartesian in the plugin,
visit/src/databases/Silo/avtSiloFileFormat.C
Lines 12563 to 12570 in 18868ba
visit/src/databases/Silo/avtSiloFileFormat.C
Lines 12247 to 12255 in 18868ba
I don't think we handle 3D unstructured meshes but then why would we. There isn't the possibility of saving any in coordinate array storage for 3D data when its an unstructured mesh.
This is freakishly inconsistent, leads to added complexity and hard to justify. IMHO, downstream of the plugin, pretty much everything is kinda sorta expecting cartesian. So, it makes sense to me that we convert to cartesian in the plugin. That said, what does user want returned for coordinate data when s/he picks? I assume user wants their native coordinate data which converting subverts. Also relevant but less important collinear coordinates in cylindrical will not be collinear in cartesian and vice-versa so there is an increase in memory requirement when we convert. Think of it as adding 2-3 additional problem sized variables for the x, y and if 3D z coordinate data.
The text was updated successfully, but these errors were encountered: