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.
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.
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.
Program received signal SIGABRT, Aborted.
0x00007ffff7e2e90c in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7e2e90c in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff7dd43a0 in raise () from /usr/lib/libc.so.6
#2 0x00007ffff7dbb57a in abort () from /usr/lib/libc.so.6
#3 0x00007ffff2a9a41f in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/assert_fail.cc:41
#4 0x00007fffedc19ce2 in std::vector<std::vector<unsigned int, std::allocator<unsigned int> >, std::allocator<std::vector<unsigned int, std::allocator<unsigned int> > > >::operator[] (this=0x7fffffffdb80, __n=140) at /usr/include/c++/15.2.1/bits/stl_vector.h:1282
#5 0x00007fffedc12a57 in (anonymous namespace)::DataSetBinner::GetBin (this=0x7fffffffdb80, binIndex=0x7fffffffd9bc) at /home/glow/dev/vtk/vtk1/src/Common/DataModel/vtkOverlappingAMRMetaData.cxx:71
#6 0x00007fffedc12b9e in (anonymous namespace)::DataSetBinner::GetBoxesInIntersectingBins (this=0x7fffffffdb80, box=..., boxes=std::set with 966 elements = {...}) at /home/glow/dev/vtk/vtk1/src/Common/DataModel/vtkOverlappingAMRMetaData.cxx:97
#7 0x00007fffedc173f2 in vtkOverlappingAMRMetaData::CalculateParentChildRelationShip (this=0x555556321d40, level=13, children=std::vector of length 3668, capacity 3668 = {...}, parents=std::vector of length 6428, capacity 6428 = {...})
at /home/glow/dev/vtk/vtk1/src/Common/DataModel/vtkOverlappingAMRMetaData.cxx:825
#8 0x00007fffedc15f0a in vtkOverlappingAMRMetaData::GenerateParentChildInformation (this=0x555556321d40) at /home/glow/dev/vtk/vtk1/src/Common/DataModel/vtkOverlappingAMRMetaData.cxx:612
#9 0x00007fffedc10aff in vtkOverlappingAMR::GenerateParentChildInformation (this=0x555556321940) at /home/glow/dev/vtk/vtk1/src/Common/DataModel/vtkOverlappingAMR.cxx:91
#10 0x00007fffee79c670 in PyvtkOverlappingAMR_GenerateParentChildInformation (self=0x7fffdc69ce20, args=0x7ffff7b603b8 <_PyRuntime+90616>) at /home/glow/dev/vtk/vtk1/build/CMakeFiles/vtkCommonDataModelPython/vtkOverlappingAMRPython.cxx:1000
#11 0x00007ffff77b02d8 in ?? () from /usr/lib/libpython3.14.so.1.0
#12 0x00007ffff777867c in _PyObject_MakeTpCall () from /usr/lib/libpython3.14.so.1.0
#13 0x00007ffff779a85a in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.14.so.1.0
#14 0x00007ffff778b805 in ?? () from /usr/lib/libpython3.14.so.1.0
#15 0x00007ffff7876d2e in PyEval_EvalCode () from /usr/lib/libpython3.14.so.1.0
#16 0x00007ffff78b70d1 in ?? () from /usr/lib/libpython3.14.so.1.0
Please open an issue, this should not crash but error out instead.
In my actual application, I worked around the problem by detecting when blocks have this weird orientation, then building my dataset so that all the spacings are positive. This requires me to rearrange the iblank and point data arrays, but it does work in the end.