[Paraview] Fwd: Segfault reading polyhedral cells xdmf3 file

[Alessandro De Maio]

You're right: the polyhedral cells of the cube.vtu example do not guarantee
the planarity of faces, but this is a typical case of a polyhedral mesh
automatically generated starting from a tetrahedral one (this example has
been built using the Ansys-Fluent converter) and I think it's quite a usual
situation.
But I'm not sure this could generate a segfault as the problem could be in
the algorythms applied by Paraview after the reading of the file that could
consider this hypothesis (as you remarked), while the VTK topological
description of a polyhedral cell doesn't seem to need it, and the reading
phase should only build the data structure compliant with VTK data
representation, as actually happens for vtu file format. But this is only
my opinion and of course it could be wrong as I don't have a deep knowledge
of all the involved procedures.
My idea is that the problem could be due to a memory error, as it's only
unfrequent with a small case (by the way the one cell mesh you attached can
be read also on the windows machine although with a randomic connectivity
error as the one I showed in the image attached to the previous message)
but very frequent with a quite bigger case as the cube.
Is it possible to use something like valgrind to check for memory errors in
Paraview ?

On Wed, Nov 30, 2016 at 6:35 PM, Armin Wehrfritz <dkxls23 at gmail.com> wrote:

> In attach you can find the output of the saving of the polyhedron.vtu
>> (saved.xmf and saved.h5) from the Windows machine.
>>
> OK, I tested the "saved.xmf" file and I can open it on my Linux machine
> without issues. Also, I compared the files generated on windows and
> linux machines, and the topology data is the same for both of them. The
> datatype in the h5 file is different (H5T_STD_I32LE for the file from
> the Windows machine vs. H5T_STD_I64LE for the file from the Linux
> machine). The end of line in the xmf file is different, but I don't
> think either one of them should cause an issue.
>
> I've tried also to repeat the procedure (reading of your xmf file) on a
>> Linux workstation and the behaviour is different: it seems that
>> randomically the crash happens again (once on about ten tries) and
>> sometimes it seems that the topology has a connectivity error (see the
>> image in attachment), while for the most of the times it seems to do the
>> right job.
>>
> As said, on my Linux machine it works consistently.
>
> I've tried also another case, a little bit heavier: a polyhedral mesh
>> read from the vtu in attach (cube.vtu) and saved with the Xdmf3 writer.
>> Trying to re-read the xmf version of this geometry always  produces a
>> crash also on the Linux machine.
>>
> I can confirm that the xmf file produce from the cube.vtu (using the
> Xdmf3 writer in ParaView 5.2) leads consistently to seg fault.
> However, even though the .vtu file works correctly, I'm not entirely
> sure if this is xmf specific problem. To be more precise, the
> implementation of polyhedral cells requires the face polygons to be
> planar (see http://www.vtk.org/Wiki/VTK/Polyhedron_Support). The example
> file you send has a whole lot of faces that are not planar.
>
> I extracted a single cell with several non-planar faces from your
> example and saved it as .xmf file (attached). I can read this particular
> file without issues on my Linux machine, whereas the original data file
> leads to a seg fault. One reason why the cube.vtu file works and the
> respective .xmf doesn't, could be related to the different approaches
> polyhedral cells are stored in vtu and xdmf files, but debugging this
> would require quite a bit of work...
>
> Maybe somebody else has an idea here.
>
> -Armin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20161130/3ac52a9b/attachment.html>