ParaView 5.13.1 killed by linux oom killer when volume rendering a 250MB field

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:

ncdump -h /fs/homeu2/eccc/mrd/rpnenv/jmb001/data/ppp5/PY/PARAVIEW/REGULAR_GRID/dataset-armor-3d-nrt-weekly_20190731T1200Z_P20201117T1307Z.nc

netcdf dataset-armor-3d-nrt-weekly_20190731T1200Z_P20201117T1307Z {
dimensions:
depth = 50 ;
latitude = 689 ;
longitude = 1440 ;
time = UNLIMITED ; // (1 currently)

	short to(time, depth, latitude, longitude) ;
			to:_FillValue = 32767s ;
			to:add_offset = 20. ;
			to:long_name = "temperature" ;
			to:scale_factor = 0.001 ;
			to:standard_name = "sea_water_temperature" ;
			to:unit_long = "degree Celsius" ;
			to:units = "degrees_C" ;

Changing Representation from Surface to Volume:

After changing representation to “volume” the default OpenGLProjectedTetrahedralMapper
is executing and consuming memory …

Last reading from htop is:

VIRT RES SHM
51 GB 30GB 257MB and …

this message from Linux

VisRTX 0.1.6, using devices:
0: NVIDIA A100 80GB PCIe (Total: 85.0 GB, Available: 84.5 GB)
error: exception occurred: Subprocess killed

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 ?

  1. 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)

  1. 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 ?

Thanks,

Jean-Marc

I’ve downnloaded the data but it doesnt seems to contain the same data as yours, could you precise how you are opening the data ?

Hi Mathieu,

 Interesting, I'm doing 
 File Open + NetCDF Reader

 You can do ncdump ... or use Panoply to view the content also.

Jean-Marc

Then I’m unable to reproduce the issue using ParaView 5.13.1.

image

Strange, you mean you can’t reproduce the problem or can’t even read the file ?

JM

I can read the file but I do not reproduce the crash or any strong memory usage.

Mathieu,

Are you able to render the volume (OpenGLProjectedTetrahedralMapper) ?

If so, do you know the (approx.) max RES memory you reach while doing so ?

I guess what could help i knowing the exacct steps you follow.
And maybe a way how I can bypass this specific algorithm ?

Thanks,

JM

When I switch to projected tetra volume rendering I get an error:

vtkOpenGLProjectedTetrahedraMapper (0x637245387f50): Encountered non-tetrahedra cell!

And nothing is rendered.

Mathieu,

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 ?

JM

There is a few different volume algorithm, the OpenGLProjectedTetrahedralMapper is just the default one for this data.

I wonder if I can change the Representation to Volume without triggering the rendering in order to select a specific mapping algorithm ?

Just dont show the dataset before switching to volume.

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 …

Again, thanks.

JM