AMR dataset with negative spacing

Support
1

I’m trying to create a vtkOverlappingAMR dataset. All the blocks are vtkUniformGrids, but the points are ordered so that X decreases with increasing I (the first index), Y increases with increasing J, and Z decreases with increasing K. So if the absolute value of a block’s spacing is ds, block[1,1,1] - block[0,0,0] is [-ds, ds, -ds]. Is this orientation a problem? Does it violate any fundamental assumptions of vtkOverlappingAMR datasets?

I ask because I’m building a ParaView plugin to read this dataset. When the block data is in the orientation described above, the plugin segfaults in GenerateParentChildInformation. It does not segfault when the data is oriented such that all the block spacings are positive. Before I go hunting for logic errors, I want to be sure the negative spacing is allowed in the first place.

Side note: how did the data come to be in this orientation in the first place? The simulation code created the blocks with positive spacings in each direction. However, they were “axis-swapped” before they were written out. This is effectively a 180 degree rotation about the Y axis.

2

I suspect that this does violate some assumptions made during implementation (not thinking of this use case). Especially if you are setting vtkAMRBoxes that are aligned with the uniform grids - meaning they are like 20, 10, 39, 20, 0, 10. I am pretty sure that it was assuming the AMR boxes go in a positive direction. And AMR boxes are closely linked to the orientation of the uniform grids when computing ghost cells (I think). First try fixing the direction of AMR boxes while leaving the spacing negative and see what you get. If that works great. If not, I suggest changing the spacing by moving the origin to the other corner.

3

I agree with @berk.geveci that this case was not tested nor accounted for. Please share code to repro so we fix the segfault at least.

4

I’ve attached a script that should demonstrate the issue. The script will read block data from one of the attached .npy files.

pvbatch demo3.py bad.npy

The “good” one has all the blocks oriented such that their spacings are positive in each direction. The “bad” one has the weird orientation I described in my original post, causing a segfault in GenerateParentChildInformation. The last call in the script, to vtk.vtkAMRUtilities.BlankCells, causes a malloc error regardless of the dataset. I’m using VTK 9.5.2, as packaged with ParaView 6.0.1.

demo3.py (4.1 KB)

good.npy (459.4 KB)

bad.npy (459.4 KB)

5

Im afraid this script is not working for me I’m afraid:

/home/glow/data/tmp/demo3.py:86: DeprecationWarning: Call to deprecated method Initialize. (Use Initialize(const std::vector<unsigned int>&) instead) -- Deprecated since version 9.6.0.
  amr.Initialize(numLevels, blocksPerLevel)
Traceback (most recent call last):
  File "/home/glow/data/tmp/demo3.py", line 88, in <module>
    amr.SetGridDescription(vtk.VTK_XYZ_GRID)
                           ^^^^^^^^^^^^^^^^
AttributeError: module 'vtk' has no attribute 'VTK_XYZ_GRID'