# ParaView 5.13.1 killed by linux oom killer when volume rendering a 250MB field
**URL:** https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992
**Category:** ParaView Support
**Created:** [January 16, 2025, 4:33pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992 "2025-01-16T16:33:49Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@jmb64](https://discourse.paraview.org/u/jmb64)
#### Post date: [January 16, 2025, 4:33pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/1 "2025-01-16T16:33:49Z")
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:
> **[Multi Observation Global Ocean 3D Temperature Salinity Height Geostrophic...](https://data.marine.copernicus.eu/product/MULTIOBS_GLO_PHY_TSUV_3D_MYNRT_015_012/files?path=MULTIOBS_GLO_PHY_TSUV_3D_MYNRT_015_012%2Fdataset-armor-3d-nrt-weekly_202012%2F2019%2F&subdataset=dataset-armor-3d-nrt-weekly_202012)**
>
> You can find here the Multi Observation Global Ocean ARMOR3D L4 analysis and multi-year reprocessing. It consists of 3D Temperature, Salinity, Heights, Geostrophic Currents and Mixed Layer Depth, available on a 1/8 degree regular grid and on 50 depth...
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
1.
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
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 17, 2025, 9:12am UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/2 "2025-01-17T09:12:28Z")
> [@jmb64](#):
>
> dataset-armor-3d-nrt-weekly\_20190731T1200Z\_P20201117T1307Z.nc
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 ?
---
### Author:  [@jmb64](https://discourse.paraview.org/u/jmb64)
#### Post date: [January 17, 2025, 1:47pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/3 "2025-01-17T13:47:00Z")
Hi Mathieu,
```
Interesting, I'm doing
File Open + NetCDF Reader
You can do ncdump ... or use Panoply to view the content also.
```
Jean-Marc
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 17, 2025, 1:56pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/4 "2025-01-17T13:56:17Z")
Then I’m unable to reproduce the issue using ParaView 5.13.1.
---
### Author:  [@jmb64](https://discourse.paraview.org/u/jmb64)
#### Post date: [January 17, 2025, 2:09pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/5 "2025-01-17T14:09:47Z")
Strange, you mean you can’t reproduce the problem or can’t even read the file ?
JM
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 17, 2025, 2:16pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/6 "2025-01-17T14:16:39Z")
I can read the file but I do not reproduce the crash or any strong memory usage.
---
### Author:  [@jmb64](https://discourse.paraview.org/u/jmb64)
#### Post date: [January 17, 2025, 2:31pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/7 "2025-01-17T14:31:39Z")
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
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 17, 2025, 2:35pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/8 "2025-01-17T14:35:58Z")
When I switch to projected tetra volume rendering I get an error:
> vtkOpenGLProjectedTetrahedraMapper (0x637245387f50): Encountered non-tetrahedra cell!
And nothing is rendered.
---
### Author:  [@jmb64](https://discourse.paraview.org/u/jmb64)
#### Post date: [January 17, 2025, 2:51pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/9 "2025-01-17T14:51:56Z")
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
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [January 17, 2025, 3:04pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/10 "2025-01-17T15:04:23Z")
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.
---
### Author:  [@jmb64](https://discourse.paraview.org/u/jmb64)
#### Post date: [January 17, 2025, 4:26pm UTC](https://discourse.paraview.org/t/paraview-5-13-1-killed-by-linux-oom-killer-when-volume-rendering-a-250mb-field/15992/11 "2025-01-17T16:26:56Z")
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