oom-kill event(s)

[RachelMeng0096]

Good evening everyone, I've been frequently encountering an issue of insufficient memory lately. Could you please suggest some ways to resolve this? Thank you in advance for your kind assistance.

[marchdf]

Hi, thanks for reaching out! Can you provide more details about the size of the case? How many cells/levels/species/etc? What type of system are you running on? CPU/GPU, ram available, etc

[RachelMeng0096]

Hello, my grid size is approximately 90 million, with the densest grid level at level 2, and involves six types of species. The size of the finest grid is 32 micrometers. I am running simulations on the Paratera HPC Cloud, but specific details about the hardware configuration are not disclosed. The currently available memory is 61,247,764 kB, and I believe it has sufficient RAM to support large-scale model computations and data processing. Additionally, I've noticed that oom-kill events errors often occur when I attempt to output slices. I'm not sure if this is the reason.

[marchdf]

How are you outputting the slices? Can you share your input file?

[RachelMeng0096]

I have generated slices using the following method, referencing settings similar to those of cavityflame. In addition, I have incorporated droplets into the process. And I'm curious to know if it's possible to output planes that are not parallel to the x, y, or z axes.

pelec.diagnostics = ynormP pelec.ynormP.type = DiagFramePlane pelec.ynormP.file = yNorm1.5cm pelec.ynormP.normal = 1 pelec.ynormP.center = 1.5 pelec.ynormP.int = 100 pelec.ynormP.interpolation = Linear pelec.ynormP.field_names = x_velocity y_velocity z_velocity magvort density magvel Temp heatRelease

[drummerdoc]

As for the arbitrary plane question, one strategy I've used is to define a variable as a function of spatial coordinates whose level sets are the plane (or surface) that you are interested in, then use the "isosurface.cpp" code in PeleAnalysis to interpolate desired variables to that triangulated surface that results. This should properly deal with cases where your surface cuts through coarse-fine boundaries (although you might run into issues with the EB...if so, let me know). However, your result will be a triangulated surface in a data format I made up, rather than a standard AMReX data structure that you can use elsewhere. These surface files, or "mef" files (Marc's element format) can be manipulated with other routines in PeleAnalysis/Src folder (look for source files with MEF in their names) - for example, you can get contours of variables on those surfaces, you can cut, combine, etc the files, but it's all a bit "in your face" software that I've written for my own hacking and simply made available. Let me know if you find them useful and need other things.

[marchdf]

@esclapez might know about planes in other directions so I will let him answer that. I am curious if you can isolate the reason for the oom. Does it happen when you reduce the resolution (e.g. fewer levels) and still output the planes? Does it change as you change the number of nodes you are using? Is it just related to the output planes? Can you provide a stacktrace/backtrace from a debug build? Short of having access to your system and actual case this is the best we can do right now... Hopefully this helps!