host:
OS: ubuntu 22.04 LTS / arch linux (tested on both systems)
paraview headless 5.13.1, downloaded from ParaView website
host command (from paraview’s bin dir):
./pvserver
OpenFOAM version: OpenFOAM 12, OpenFOAM Foundation version, downloaded from GitHub and installed manually
description:
ParaView shows warnings with OpenFOAM’s new non-conformal-coupling (NCC) interface. A warning message appears from Paraview as “vtkOpenFOAMReader.cxx:8826 ERR| vtkOpenFOAMReaderPrivate …: Number of cells/points in mesh and field do not match: mesh = 0, field = 23805 in T”.
If I understand correctly the problem is related to the NCC interface, as it looks in OpenFOAM’s mesh directory in constant/polyMesh/boundary that these kind of interfaces have 0 faces. However, on these interfaces the faces will be actually generated with OpenFOAM’s command “createNonconformalCouples”, which are stored in constant/fvMesh, i.e. in a different subfolder. See more details in Using NCC in OpenFOAM | CFD Direct
The problem is that these warnings can cause segfault crash using the headless server in certain cases. I tried to narrow down the cause of this issue. It seems that for a small number of fields and/or boundaries the warning message pops up, but overall ParaView can handle the mesh. However, in case of a lot of boundaries and/or physical fields the headless server crashes with segfault. I guess it crashes because of the high number of warning messages.
I tried to create simple simulation case to highlight the issue with only one NCC boundary. In this case the simulation:
- it can be read when there is only one field
- but it crashes when there are 30 different fields and the NCC interface is selected. (The crash also happens when there are less fields but more NCC boundaries.)
I can share these sample simulation folders, if needed.
note: The crash does not happen, when the simulation is opened with the ParaView application, i.e. for me it happens only with the headless server.
open simulation dir in client by selecting the foam.foam file in the folder
set Case Type to “Reconstructed Case”
set Label size to “64 bit”
unselect all mesh regions except one: the container/patch/container-cube
for some reason the crash now happens also with only one field, so possibly I was incorrect regarding the number of fields or boundaries. Nevertheless I upload two cases:
- one with only one field (test_cube_paraview.tar.gz)
- another one with 31 fields. These fields are just simply the duplicate of T (test_cube_paraview_morefields.tar.gz )
I reproduce the warning but not the crash, with non-distributed and distributed egl headless server 5.13.1 binary release and linux client 5.13.1 binary release.
The crash happens with the osmesa headless version. Sorry that I did not specified it before.
I tried now with the egl version and it indeed does not crash with this version. Thanks for the hint.
Another (smaller) issue with the osmesa version: when the simulation block is deleted in ParaView the client GUI closes immediately, while the server side also abruptly closes with the message:
vtkSocketCommunicator.c:774 ERR| vtkSocketCommunicator (…): Could not receive tag. 1
vtkTCPNetworkAccessMana:284 ERR| vtkTCPNetworkAccessManager (…): Some error in socket processing.
This error does not occur with the egl version.
In an ubuntu 22.02 (remote) system, where I used the headless binary downloaded from paraview webpage
here I ran: ./pvserver from its bin directory
or in some cases parallel ./mpiexec -np 24 ./pvserver
both of them listening on the defult port (11111)
I connected to the system from a paraview client, which is installed in an arch linux OS
for investigating the crash issue I also ran the headless version on the arch linux OS, and connected locally with the client on the same machine.
I have the described issues:
- crash and the warnings with the NCC boundary,
- sudden exit after simulation block delete
- also a third one: the SaveScreenshot python command did not work on the remote system.
Other than these problems the osmesa version seemed to work, but I have not tested it yet so much.
So all in all should I use the egl version, and not osmesa as glibc version is 2.35 in my case on the ubuntu system?
I tested both of the sample cases with the EGL version, and the crash did not happen in them. Thanks for the help.
one additional note: if possible, please consider adjusting ParaView’s OpenFOAM reader to the new NCC interface to avoid the warning messages at the beginning. As I have written before, although the warning message is technically true, I think the 0 face issue does not represent a problem in this case.
