Segementation Fault when opening OpenFOAM data

ParaView Support
1

Hi,

I’ve recently started working on a new OpenFOAM case, and have run into a problem trying to visualise results using paraview. I can open paraview fine, but when I hit apply after opening the .foam file paraview will close, printing “Segementation Fault (Core Dumped)” to the terminal. Weirdly, this only happens when the case is reconstructed. If i decompose it then I can open it in paraview no problem.

I’m using ParaView v5.4.1 on SUSE Enterprise 15 SP1. I’m using the pre-compiled binaries downloaded from the paraview website, not the paraview bundled with OpenFOAM. I’ve also tried using v5.4.0 and v5.8.1 with the same problems. On v5.8.1 the following stack trace is generated:

Loguru caught a signal: SIGSEGV
Stack trace:
59            0x407b5d bin/paraview() [0x407b5d]
58      0x7f80b90bd34a __libc_start_main + 234
57            0x4077ed bin/paraview() [0x4077ed]
56      0x7f80b6c1d0b4 QCoreApplication::exec() + 132
55      0x7f80b6c144aa QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 234
54      0x7f8087829e96 /home/ttjrjw2/Software/Paraview581/plugins/platforms/../../lib/libQt5XcbQpa.so.5(+0xb1e96) [0x7f8087829e96]
53      0x7f80b704862b QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 187
52      0x7f80b706cc15 QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) + 261
51      0x7f80b706b1a3 QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) + 1779
50      0x7f80b6c15c08 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 264
49      0x7f80b8710f01 QApplication::notify(QObject*, QEvent*) + 577
48      0x7f80b8709c8c QApplicationPrivate::notify_helper(QObject*, QEvent*) + 156
47      0x7f80b8762cd3 /home/ttjrjw2/Software/Paraview581/bin/../lib/libQt5Widgets.so.5(+0x1b8cd3) [0x7f80b8762cd3]
46      0x7f80b876042d /home/ttjrjw2/Software/Paraview581/bin/../lib/libQt5Widgets.so.5(+0x1b642d) [0x7f80b876042d]
45      0x7f80b87104ed QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) + 461
44      0x7f80b6c15c08 QCoreApplication::notifyInternal2(QObject*, QEvent*) + 264
43      0x7f80b8711c78 QApplication::notify(QObject*, QEvent*) + 4024
42      0x7f80b8709c8c QApplicationPrivate::notify_helper(QObject*, QEvent*) + 156
41      0x7f80b87469d8 QWidget::event(QEvent*) + 488
40      0x7f80b87fd4c5 QAbstractButton::mouseReleaseEvent(QMouseEvent*) + 213
39      0x7f80b87fd312 /home/ttjrjw2/Software/Paraview581/bin/../lib/libQt5Widgets.so.5(+0x253312) [0x7f80b87fd312]
38      0x7f80b87fc014 /home/ttjrjw2/Software/Paraview581/bin/../lib/libQt5Widgets.so.5(+0x252014) [0x7f80b87fc014]
37      0x7f80b87fbe02 QAbstractButton::clicked(bool) + 50
36      0x7f80b6c41c47 QMetaObject::activate(QObject*, int, int, void**) + 1511
35      0x7f80b7fb78d2 pqPropertiesPanel::apply() + 1106
34      0x7f80b7e87142 pqPropertiesPanel::applied(pqProxy*) + 50
33      0x7f80b6c41c47 QMetaObject::activate(QObject*, int, int, void**) + 1511
32      0x7f80b8cac65a pqApplyBehavior::applied(pqPropertiesPanel*, pqProxy*) + 154
31      0x7f80b8cad8e5 pqApplyBehavior::showData(pqPipelineSource*, pqView*) + 437
30      0x7f80abbfb998 vtkSMParaViewPipelineControllerWithRendering::ShowInPreferredView(vtkSMSourceProxy*, int, vtkSMViewProxy*) + 360
29      0x7f80abbf982b vtkSMParaViewPipelineControllerWithRendering::UpdatePipelineBeforeDisplay(vtkSMSourceProxy*, int, vtkSMViewProxy*) + 155
28      0x7f80b6015a60 vtkSMSourceProxy::UpdatePipeline(double) + 176
27      0x7f80b5f9f8a1 vtkSMOutputPort::UpdatePipelineInternal(double, bool) + 193
26      0x7f80b5f05b75 vtkPVSessionBase::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 53
25      0x7f80b5f06abb vtkPVSessionCore::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 59
24      0x7f80b5f06c85 vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) + 245
23      0x7f80b5484ddd vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) + 29
22      0x7f80b5484aae vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) + 1198
21      0x7f80b5483fea vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) + 330
20      0x7f80b5483cf5 vtkClientServerInterpreter::CallCommandFunction(char const*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&) + 325
19      0x7f80ad0ddee3 vtkSISourceProxyCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 1507
18      0x7f80b5f41d24 vtkSISourceProxy::UpdatePipeline(int, double, bool) + 484
17      0x7f80b158ff1f vtkStreamingDemandDrivenPipeline::Update(int, vtkInformationVector*) + 255
16      0x7f80b1550f9a vtkDemandDrivenPipeline::UpdateData(int) + 138
15      0x7f80b158e9c1 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 801
14      0x7f80b1551fc6 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 262
13      0x7f80b154b83a vtkCompositeDataPipeline::ForwardUpstream(vtkInformation*) + 330
12      0x7f80b158e9c1 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 801
11      0x7f80b1552467 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1447
10      0x7f80b154cac1 vtkCompositeDataPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 257
9       0x7f80b154f8c7 vtkDemandDrivenPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 55
8       0x7f80b1555330 vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 64
7       0x7f809b821432 vtkPOpenFOAMReader::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 786
6       0x7f809aa5429e vtkOpenFOAMReader::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1278
5       0x7f809aa52f3a /home/ttjrjw2/Software/Paraview581/bin/../lib/libvtkIOGeometry-pv5.8.so.1(+0xe1f3a) [0x7f809aa52f3a]
4       0x7f809aa430a5 /home/ttjrjw2/Software/Paraview581/bin/../lib/libvtkIOGeometry-pv5.8.so.1(+0xd20a5) [0x7f809aa430a5]
3       0x7f809aa67f4c /home/ttjrjw2/Software/Paraview581/bin/../lib/libvtkIOGeometry-pv5.8.so.1(+0xf6f4c) [0x7f809aa67f4c]
2       0x7f809aa5ab7e /home/ttjrjw2/Software/Paraview581/bin/../lib/libvtkIOGeometry-pv5.8.so.1(+0xe9b7e) [0x7f809aa5ab7e]
1       0x7f80b913ea63 /lib64/libc.so.6(+0xa5a63) [0x7f80b913ea63]
0       0x7f80b90d25a0 /lib64/libc.so.6(+0x395a0) [0x7f80b90d25a0]
(  64.966s) [paraview        ]                       :0     FATL| Signal: SIGSEGV
Segmentation fault (core dumped)

I was wondering if anyone had encountered similar problems, or knew of a way to fix this, apologies if this is the wrong place to post. I’ve also posted the problem to CFD Online at the following link:

Many thanks,
Jack

2

Hi Jack,

tl;dr: I noticed the same, workaround is to use Decomposed Case, there may be some things that influence the behavior.

My experience has been similar. There are a few things that influence the behavior I found out:

  1. Mesh size. Larger meshes will have this issue but small meshes will not (Not sure what the threshold is, it also depends on 2.)
  2. Mesh type: Tetrahedral meshes are giving these issues much less frequent than polyhedral/hexcore (snappyHexMesh) meshed. Not sure about pure hexahedral meshes as I rarely have those for large cases.

As the mesh size influences this problem the most I suspect it has something to do with memory, but that is just a hypothesis that I never got confirmed.

My work-around is to use the reader with a decomposed case. The only downside to that is that if I want to use feature edges to highlight boundaries of patches it may also show processor boundaries, which I typically do not care too much about.

If someone has more insights I would like to learn as well.

Other things that may influence this:
a. Operating system (There were cases where colleagues running Windows could open a particular case and I could not from my linux workstation (or vice versa, my own memory is not that clear about this))
b. Graphics card (Same with the different operating system, my colleagues have different graphics cards)

Best Regards,
Tom

The behavior is consistent between paraview/pvpython/pvbatch and there does not seem to be a difference whether I am working in client/server mode or just in the client, except for maybe changes between the graphics card used in our cluster (the server) and my workstation.

3

Hello,

I have exactly the same problem and I have tried several ParaView versions, including 5.9.0-RC2. All on (Debian) linux.

Like Tom I decompose the cases that crash. A decomposition into 2 parts is enough.

It always happens with larger meshes (tens of millions of cells), but I don’t know the exact limit.

I can provide a test case, if necessary.

Kind regards,
Roland

4

Roland,

Please provide a test case and the reader options you specify so we can investigate what is going on here.

Regards,
J.

5

Hi Joachim,

I have just sent you a private message with a link to a test case.

This mesh is created using the snappyHexMesh utility, but we have similar problems with (OpenFOAM) meshes created by ANSA.

Included is a state file created by 5.9.0-RC3. It loads the decomposed data, but when you change the ‘Case Type’ to ‘Reconstructed Case’ (and hit ‘Apply’) ParaView crashes. A log of this is also included.

Let me know if you need more information.

Merry Christmas!

Kind regards,
Roland

6

@Joachim_P and @tomF

Saw this before the break, but didn’t look at it further. I highly suspect that this is due to the handling of faces in the reader which internally uses a private vtkFoamLabelVectorVector struct. This structure corresponds approximately to the OpenFOAM faceCompactList in that the list of lists is stored as data + offset indices.
The indices are thus sized (nFaces * nVertsPerFace), which can easily overflow the capacity of an int32_t, even when the total number of faces/cells/points are well within the limit. If you inspect the header of the “polyMesh/faces” files, it is quite likely that the serial case has class faceList; whereas the decompose case has class faceCompactList;. When generating these files within OpenFOAM we check if the running index for the compact format would exceed the label limit (eg, 32bit) and revert to using a faceList instead for those cases. The VTK reader on the other hand, handles both internally as a compact list and will thus experience these overflows.

Possible fixes:

  • always use a vtkTypeInt64Array for the Indices of vtkFoamLabelVectorVectorImpl (or a vtkIdTypeArray?, or a vtkTypeUInt64Array?)
  • same as above, but provide as second template parameter to vtkFoamLabelVectorVectorImpl (for the indecisive)

/mark

7

Added as issue 8082 and tackling while examining issue 8081. Hope to get something on a merge request in the next few days, and would like someone to test.

8

Changes in MR 75319 that I hope will cure the overflows.
@tomF or @roland would need to check if these changes solve your problems.

9

Sure, I guess we would need to wait for the merge request to be accepted and then to have it implemented in the new ParaView 5.9 release?

10

It won’t be in 5.9 as the release split occured weeks ago already.

11

@tomF - are you in the position to build from source? Can either build based on the merge-request, and/or we can test a few minor changes, but need to see if we can make it a minimal patch.

12

Unfortunately I now see that I would need to update a lot on my system and I do not want to break other things, so I am afraid I cannot help. But maybe @roland can manage it.

13

I’ve had a try, but either I did something wrong, or the problem was not solved.

What I did was this: I’ve merged the branch ‘olesen/vtk-openfoam-mixed-precision’ to a clone of VTK. This I’ve used to build ParaView. I couldn’t build the GUI (only QT 5.11, while 5.12 is required), but pvpython was no problem. This version of pvpython crashed when trying to open a certain reconstructed data set, but not the decomposed version.

@olesenm, is there a way to check that my build really includes your updated code? Or else can I send you the same data set that I’ve send to @Joachim_P?

Kind regards,
Roland

14

Hi @roland - if you have a convenient way to make a data set available, it would likely help.
Email address as per the git commit(s)

15

Hi Mark,

I’ve just tested 5.10.0-RC1 and my test case opened flawlessly in it. Thanks for the good work!

Kind regards,
Roland

2 Likes