Paraview crashes for xdmf file with anisotropic mesh

peete1 · January 24, 2025, 3:45pm

Good day,

I am working on a Linux machine, trying to visualize a parameter/time-dependent function from an xdmf file. (The file is generated from the open-source FEM software FenicsX).

The function is defined on a 3-dimensional mesh/grid, with hexagonal cells. The mesh is anisotropic. Depending on the exact number of cells in each dimension, my Paraview installation can easily load the file into the pipeline browser, or it crashes, i.e. it closes immediately.

Here are some example configurations:

Lx	Ly	Lz	Nx	Ny	Nz	outcome
0.2	1	2\pi\approx6.3	30	200	20	works fine
0.2	1	2\pi\approx6.3	\textcolor{red}{50}	200	20	crash

L_i denotes the size of the domain of the function, and N_i the number of cells (in the direction i).

Workflow to reproduce the problem:

drag&drop the xdmf file into the paraview window
Choose “Xdmf3ReaderT” in the “Open Data With…” window
Press “ok”

I saved the two files and uploaded them here: LINK. The link expires on 2025-01-31.

Thank you for your help.

Let me know if it is of interest for you to get a minimum working example code, that generates such xdmf files, that provoke this behavior.

peete1 · January 27, 2025, 9:54am

I ran paraview with the log-levels flag:
paraview --log-level=2

and provoke the crash again, with a comparable xdmf file. This is the log output:

/home/out/xdmf_100x90x100_Nt1_T0.1_wiggles_mu0.0005__20250127-102344.xdmf:193604: parser error : xmlSAX2Characters: huge text node
194006 198989 204071 199040 199041 204072 209201 204124
                 ^
/home/out/xdmf_100x90x100_Nt1_T0.1_wiggles_mu0.0005__20250127-102344.xdmf:193604: parser error : Extra content at the end of the document
194006 198989 204071 199040 199041 204072 209201 204124
                 ^
xmlReadFile could not read /home/out/xdmf_100x90x100_Nt1_T0.1_wiggles_mu0.0005__20250127-102344.xdmf in XdmfCoreReader::XdmfCoreReaderImpl::openFile
terminate called after throwing an instance of 'XdmfError'
  what():  xmlReadFile could not read /home/out/xdmf_100x90x100_Nt1_T0.1_wiggles_mu0.0005__20250127-102344.xdmf in XdmfCoreReader::XdmfCoreReaderImpl::openFile

Loguru caught a signal: SIGABRT
Stack trace:
59      0x5c96a6ae03f5 paraview(+0xd3f5) [0x5c96a6ae03f5]
58      0x71e53d429e40 __libc_start_main + 128
57      0x71e53d429d90 /usr/bin/../lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x71e53d429d90]
56      0x5c96a6adf0a3 paraview(+0xc0a3) [0x5c96a6adf0a3]
55      0x71e53b6c0cf4 QCoreApplication::exec() + 148
54      0x71e53b6b875b QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 299
53      0x71e53b7130b8 QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 104
52      0x71e5375193e3 g_main_context_iteration + 51
51      0x71e5375712b8 /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0xab2b8) [0x71e5375712b8]
50      0x71e53751bd3b g_main_context_dispatch + 619
49      0x71e520eabd67 /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(+0x73d67) [0x71e520eabd67]
48      0x71e520e85116 QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 118
47      0x71e520e83d18 QXcbConnection::handleXcbEvent(xcb_generic_event_t*) + 632
46      0x71e520ebd62c /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(+0x8562c) [0x71e520ebd62c]
45      0x71e53bb1629c QWindowSystemInterface::handleDrop(QWindow*, QMimeData const*, QPoint const&, QFlags<Qt::DropAction>, QFlags<Qt::MouseButton>, QFlags<Qt::KeyboardModifier>) + 188
44      0x71e53bb43213 QGuiApplicationPrivate::processDrop(QWindow*, QMimeData const*, QPoint const&, QFlags<Qt::DropAction>, QFlags<Qt::MouseButton>, QFlags<Qt::KeyboardModifier>) + 147
43      0x71e53b6b9e3a QCoreApplication::notifyInternal2(QObject*, QEvent*) + 314
42      0x71e53c96c713 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 131
41      0x71e53c9cc210 /usr/bin/../lib/x86_64-linux-gnu/libQt5Widgets.so.5(+0x1cc210) [0x71e53c9cc210]
40      0x71e53c9cb402 /usr/bin/../lib/x86_64-linux-gnu/libQt5Widgets.so.5(+0x1cb402) [0x71e53c9cb402]
39      0x71e53b6b9e3a QCoreApplication::notifyInternal2(QObject*, QEvent*) + 314
38      0x71e53c975c0d QApplication::notify(QObject*, QEvent*) + 9005
37      0x71e53c96c713 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 131
36      0x71e53c9af4ee QWidget::event(QEvent*) + 526
35      0x71e53c2d9d66 pqMainWindowEventManager::drop(QDropEvent*) + 70
34      0x71e53b6f17c8 /usr/bin/../lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2f17c8) [0x71e53b6f17c8]
33      0x71e53d16fb55 pqMainWindowEventBehavior::onDrop(QDropEvent*) + 1013
32      0x71e53d16ac05 pqLoadDataReaction::loadData(QStringList const&, QString const&, QString const&, pqServer*) + 613
31      0x71e53d1691d9 pqLoadDataReaction::loadData(QList<QStringList> const&, QString const&, QString const&, pqServer*) + 841
30      0x71e53d165b57 pqLoadDataReaction::LoadFile(QStringList const&, pqServer*, QPair<QString, QString> const&) + 71
29      0x71e53c34ff93 pqObjectBuilder::createReader(QString const&, QString const&, QStringList const&, pqServer*) + 1155
28      0x71e53c34b381 /usr/bin/../lib/x86_64-linux-gnu/libpqCore-pv5.10.so.1(+0xff381) [0x71e53c34b381]
27      0x71e538fe4644 vtkSMParaViewPipelineControllerWithRendering::PostInitializeProxy(vtkSMProxy*) + 68
26      0x71e53b150b31 vtkSMParaViewPipelineController::PostInitializeProxy(vtkSMProxy*) + 385
25      0x71e53b1bae11 vtkSMSourceProxy::UpdatePipelineInformation() + 129
24      0x71e53b0b349a vtkPVSessionBase::ExecuteStream(unsigned int, vtkClientServerStream const&, bool) + 122
23      0x71e53b0bca2b vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool) + 251
22      0x71e53c7a14e5 vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&) + 37
21      0x71e53c7a101d vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&, int) + 237
20      0x71e53c7a08cd vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream const&, int) + 1197
19      0x71e5395cf240 vtkSISourceProxyCommand(vtkClientServerInterpreter*, vtkObjectBase*, char const*, vtkClientServerStream const&, vtkClientServerStream&, void*) + 1776
18      0x71e53b0e6e70 vtkSISourceProxy::UpdatePipelineInformation() + 176
17      0x71e537f75c9a vtkDemandDrivenPipeline::UpdateInformation() + 42
16      0x71e537f748c4 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 612
15      0x71e537f65417 vtkCompositeDataPipeline::ExecuteDataObject(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 87
14      0x71e537f71624 vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 84
13      0x71e5356fdb56 vtkXdmf3Reader::RequestDataObjectInternal(vtkInformationVector*) + 726
12      0x71e5356fd1c8 /usr/bin/../lib/x86_64-linux-gnu/libvtkIOXdmf3-pv5.10.so.1(+0x3e1c8) [0x71e5356fd1c8]
11      0x71e52fcaccc2 XdmfReader::read(std::string const&) const + 34
10      0x71e52f792dec XdmfCoreReader::read(std::string const&) const + 44
9       0x71e52f7975e3 XdmfCoreReader::readItems(std::string const&) const + 1075
8       0x71e52f74ab4c /usr/bin/../lib/x86_64-linux-gnu/libvtkxdmfcore-pv5.10.so.1(+0x27b4c) [0x71e52f74ab4c]
7       0x71e53a4ae4d8 /usr/bin/../lib/x86_64-linux-gnu/libstdc++.so.6(+0xae4d8) [0x71e53a4ae4d8]
6       0x71e53a4ae277 /usr/bin/../lib/x86_64-linux-gnu/libstdc++.so.6(+0xae277) [0x71e53a4ae277]
5       0x71e53a4ae20c /usr/bin/../lib/x86_64-linux-gnu/libstdc++.so.6(+0xae20c) [0x71e53a4ae20c]
4       0x71e53a4a2b9e /usr/bin/../lib/x86_64-linux-gnu/libstdc++.so.6(+0xa2b9e) [0x71e53a4a2b9e]
3       0x71e53d4287f3 abort + 211
2       0x71e53d442476 raise + 22
1       0x71e53d4969fc pthread_kill + 300
0       0x71e53d442520 /usr/bin/../lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x71e53d442520]
(   4.720s) [paraview        ]                       :0     FATL| Signal: SIGABRT
Aborted (core dumped)

Somehow, the log output states

huge text node
extra content at the end of the document

I dont understand why either of those would appear only under a certain choice of mesh-size, and not at all for other mesh-sizes.
But it does seem, that the xdmf file is the problem.

Another test: running
xmllint --noout ./50x200x20_crash.xdmf

yields:

./50x200x20_crash.xdmf:193317: parser error : Resource limit exceeded: Text node too long, try XML_PARSE_HUGE
206707 207275 207843 207296 207297 207844 208389 207863
                                                 ^

Indicating indeed, that the xdmf file is broken.

I am happy for any suggestions.

peete1 · January 27, 2025, 5:29pm

I figured it out. The problem is, that if one chooses to create a mesh in fenicsX using a special argument of the xdmf-writer, then - under some choice of the element number/mesh structure - the xdmf file is corrupted.

If one creates a mesh like this:

msh = create_box(MPI.COMM_WORLD, 
                        [[0.0, 0.0, 0.0], [Lx, Ly, Lz]], 
                        [Nx,Ny,Nz],
                        cell_type=CellType.hexahedron)

Then, the “bad” way to write to xdmf is

from dolfinx import io
xdmf_file = io.XDMFFile(msh.comm, "my_file.xdmf", "w", encoding=io.XDMFFile.Encoding.ASCII)
xdmf_file.write_mesh(msh)
xdmf_file.close()

while the good way (the one that worked for me) is this:

from dolfinx import io
xdmf_file = io.XDMFFile(msh.comm, "my_file.xdmf", "w")
xdmf_file.write_mesh(msh)
xdmf_file.close()