Description: When changing Representation to “volume”, the PT algorithm (OpenGLProjectedTetrahedralMapper) is executing and seems to induce a ~ x200 fold increase in process resident memory (RES on htop) before crashing.
It is well known that this algorithm creates auxiliary data structures that are memory hungry but this is impressive …
ParaView Binary: is downloaded from Kitware: ParaView-5.13.1-MPI-Linux-Python3.10-x86_64/bin/paraview
(same result with 5.13).
Input data: Netcdf file: dataset-armor-3d-nrt-weekly_20190731T1200Z_P20201117T1307Z.nc
is open and available from Copernicus website here:
How can I make sure in this case that I select another mapper (like NVIDIA IndeX plugin or OSPRay) prior to changing from Surface to Volume ?
Using pvpython I don’t encounter the same memory issue whether I do:
#1 view.Representation = “NVIDIA IndeX” #—> triggers IndeX
or #2 view.Representation = “Volume”
or #3 view.Representation is commented out (left undefined)
I thought that a 250MB field was small enough for ParaView to be “responsive” …
how small should I go not to be bothered with slow response ? I understand that this depends
on a lot of factors … (hardware, software, paraview algorithm, etc…) but it seems that using pvpython and Interact() the response is way faster although the GUI is simple. It seems that the GUI from pyvista Plotter is a bit better. I was wondering if they could be the same if pyvista is based on VTK too ?
If you look at the bottom of the screen snapshot you can read OpenGLProj…
it is not something I explicitly chose. I simply set Rerpesentation to Volume and this
is what I get. You said “when I switch …”, so I’m probably missing something here.
As a matter of fact, I wonder if I can change the Representation to Volume without
triggering the rendering in order to select a specific mapping algorithm ?
Thanks for this last piece of advice, This will help in the future.
Funny, I thought this “regular” grid would be easier. But it is still considered a
StructuredGrid though (not Uniform though nor Unstructured, needed by IndeX).
I did try ResampleToImage mapper and it works. PT,Bunyk,Zssweep all fail with the same memory problem (I suspect this is a cgroup container memory configuration issue limited the process around 50GB or 5% limit of the node memory that you likely not encounter on your system) …
I am bit puzzled by the fact that you said earlier that with PT algorithm ParaView did not even try to render because of absence of Tetrahedras while in my case it goes on but fails because of oom …
I might try to document these in a more systematic fashion …