Re: [Paraview] Running Paraview on an HPC machine with multiple processes?

[Alessandro De Maio]

Hi Jake,
 when you talk about running in multi-processing are you talking about
the solver that produces the data or about running Paraview in mpi-mode?
Which is the error you get?

Alessandro

On Wed, Jul 12, 2017 at 5:28 PM, Jake Gerard 
wrote:

> Any help here would be greatly appreciated.
>
> On Tue, Jul 11, 2017 at 2:37 PM, Jake Gerard 
> wrote:
>
>> Good Afternoon,
>>
>> I have been moving to an HDF5/XDMF system for analyzing big data from a
>> computational fluid model. I finally got all the basic components working
>> on my local machine but have run into problems when trying to run on an HPC
>> system. Here is the XDMF file:
>>
>> 
>> 
>> http://www.w3.org/2003/XInclude; Version="2.1">
>>   
>> 
>>   
>>   
>>   
>> 
>>   0 0 0
>> 
>> 
>>   1 1 1
>> 
>>   
>>   
>> 
>>   out.h5:/pres_group/presmag
>> 
>>   
>>   
>> > Dimensions="91 19 19 3">
>>   
>> out.h5:/velo_group/x_velo
>>   
>>   
>> out.h5:/velo_group/y_velo
>>   
>>   
>> out.h5:/velo_group/z_velo
>>   
>> 
>>   
>> 
>>   
>> 
>>
>> This has worked properly on my machine. However, when I was getting an
>> error of failing to read the pressure data when I tried this on multiple
>> processes. The vector data for velocity was fine, but the pressure data
>> could not be read. I narrowed the problem down to something regarding the
>> number of processes because the pressure data worked fine on the HPC
>> machine if I only ran it on 1 process. Is there anything that sticks out
>> that could be causing this problem? For instance, is there a different
>> format for these files when they are run on multiple processes?
>>
>> Respectfully,
>>
>> Jacob Gerard
>>
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] passing a numpy array to a programmable filter

[Alessandro De Maio]

Thank you very much Utkarsh,
 your suggestion was very helpful as always!

Alessandro

On Tue, May 30, 2017 at 4:23 PM, Utkarsh Ayachit <
utkarsh.ayac...@kitware.com> wrote:

> The best option would be to indeed move the Python code to "get" the array
> from the the other numerical process to the Programmable Filter's script
> itself, rather than doing it in the batch script.
>
> The do-at-your-own-peril option, which may work if you don't intend to run
> the batch script in parallel or client-server modes,  would be to pass the
> array via a global variable in some module that both the batch script and
> the programmable filter script import. Since the Python interpreter is
> shared between the two, and modules don't get imported twice, you should be
> able to set the variable in one and access it in another.
>
> Utkarsh
>
> On Fri, May 26, 2017 at 10:53 AM, Alessandro De Maio <demai...@gmail.com>
> wrote:
>
>> Dear all,
>>  I'm writing a pvbatch script in which I need to perform some
>> calculations on paraview objects (provided by a quite complex pipeline that
>> starts from reading vtu files and processing through reseamplewithdataset
>> filter and other filter manipulations) by using a programmable filter to
>> which I must pass some information that in the main script is representable
>> as a quite big float numpy ndarray. This array comes from another numerical
>> process that cannot be included in the same programmable filter.
>>
>> I don't know how to pass this numpy array to the programmable filter.
>> Probably I could use the Parameters property of the programmable filter
>> but, if I correctly understand the use of this feature, the whole array
>> should be converted to a very big string (or more than one) and then
>> reconverted back to float values inside the PF.
>>
>> I've tried to create a vtkTable object in the main script using the
>> following lines:
>>
>> T = vtkTable()
>> array_vtk = numpy_support.numpy_to_vtk(array)
>> array_vtk.SetName("AAA")
>> T.AddColumn(array_vtk)
>>
>> and this seems to generate a vtkTable object (by printing type(T) I get
>> " " ) but this is not a
>> Paraview class object so when I pass this as an input argument to the
>> Programmable Filter I obviously get the error:
>> "vtkCommonDataModelPython.vtkTable' object has no attribute 'SMProxy'.
>>
>>
>>
>> Is there any way to do this? I've thought about using
>> servermanager.CreateProxy() but I don't know how to use it and if it could
>> help.
>>
>> Of course the easy solution could be to write the array to the disk from
>> the main script and to read it from the  disk inside the programmable
>> filter, but I would like to avoid passing through the disk writing that
>> could be too much slow.
>>
>> Any help would be appreciated.
>> Thank you in advance
>>
>> Alessandro
>>
>> ___
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ParaView Wiki at:
>> http://paraview.org/Wiki/ParaView
>>
>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/paraview
>>
>>
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] passing a numpy array to a programmable filter

[Alessandro De Maio]

Dear all,
 I'm writing a pvbatch script in which I need to perform some
calculations on paraview objects (provided by a quite complex pipeline that
starts from reading vtu files and processing through reseamplewithdataset
filter and other filter manipulations) by using a programmable filter to
which I must pass some information that in the main script is representable
as a quite big float numpy ndarray. This array comes from another numerical
process that cannot be included in the same programmable filter.

I don't know how to pass this numpy array to the programmable filter.
Probably I could use the Parameters property of the programmable filter
but, if I correctly understand the use of this feature, the whole array
should be converted to a very big string (or more than one) and then
reconverted back to float values inside the PF.

I've tried to create a vtkTable object in the main script using the
following lines:

T = vtkTable()
array_vtk = numpy_support.numpy_to_vtk(array)
array_vtk.SetName("AAA")
T.AddColumn(array_vtk)

and this seems to generate a vtkTable object (by printing type(T) I get
" " ) but this is not a Paraview
class object so when I pass this as an input argument to the Programmable
Filter I obviously get the error: "vtkCommonDataModelPython.vtkTable'
object has no attribute 'SMProxy'.



Is there any way to do this? I've thought about using
servermanager.CreateProxy() but I don't know how to use it and if it could
help.

Of course the easy solution could be to write the array to the disk from
the main script and to read it from the  disk inside the programmable
filter, but I would like to avoid passing through the disk writing that
could be too much slow.

Any help would be appreciated.
Thank you in advance

Alessandro
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] How to configure ParaView 5.2.0 to use off screen rendering?

[Alessandro De Maio]

Hi,
 I've just compiled the Paraview-5.3.0 superbuild with EGL. I created
an EGL dir in /usr/include with egl.h, eglext.h and eglplatform.h (taken
from www.khronos.org/registry/egl/) and I created a KHR dir in /usr/include
with khrplatform.h (taken from the same site).
ccmake already recognized the /usr/include/EGL include path for EGL and
everything was ok.

Alessandro

On Mon, Mar 20, 2017 at 3:28 PM, Dan Lipsa  wrote:

> Looking at the errors you are getting looks like
> /pan20/yzzhang/EGL/eglplatform.h
> needs  KHR/khrplatform.h
>
> Maybe your configuration uses different EGL header files than what you
> expect.
>
> DAn
>
>
> On Mon, Mar 20, 2017 at 10:22 AM, 张驭洲  wrote:
>
>>
>>
>> Thanks for your reply! But I don't know where the KHR/khrplatform.h is
>> used. When I configure paraview using ccmake, the options about EGL are
>> EGL_INCLUDE_DIR,
>> EGL_LIBRARY, EGL_gldispatch_LIBRARY, EGL_opengl_LIBRARY,
>> VTK_EGL_DEVICE_INDEX and VTK_USE_OFFSCREEN_EGL. In the path that I assigned
>> to the EGL_INCLUDE_DIR, there is khrplatform.h file. What's more, I have
>> built ParaView 5.2.0 with EGL used on another machine. That machine use
>> NVIDIA GT 730 GPU, and in the EGL_INCLUDE_DIR path, there is not a
>> khrplatform.h file, but the paraview can be built successfully and works.
>> The khrplatform.h is required by the current EGL (1.5), but my EGL version
>> is 1.4. Maybe it doesn't need that file?
>>
>> Thank you again!
>>
>> -Zhang
>>
>> -原始邮件-
>> *发件人:* "Dan Lipsa" 
>> *发送时间:* 2017年3月20日 星期一
>> *收件人:* "张驭洲" 
>> *抄送:* paraview 
>> *主题:* Re: [Paraview] How to configure ParaView 5.2.0 to use off screen
>> rendering?
>>
>>
>> It seems you are missing KHR/khrplatform.h
>> You can download it from the EGL website:
>> https://www.khronos.org/registry/EGL/
>>
>> On Sat, Mar 18, 2017 at 3:51 AM, 张驭洲  wrote:
>>
>>>
>>>
>>> Hello,
>>>
>>> I'm building ParaView 5.2.0 on a machine that uses NVIDIA Tesla K80
>>> GPUs. The K80 GPUs have no interface for monitor, so I have to use off
>>> screen rendering. It's said that EGL is a pretty good choice for this
>>> situation, but as I switch VTK_USE_OFFSCREEN and VTK_USE_OFFSCREEN_EGL to
>>> "ON" and then make,  I get these errors:
>>>
>>> Built target vtkIOImage
>>> [ 16%] Building C object VTK/ThirdParty/glew/vtkglew/CM
>>> akeFiles/vtkglew.dir/src/glew.c.o
>>> In file included from /pan20/yzzhang/EGL/egl.h:39,
>>>  from /pan20/yzzhang/ParaView-v5.2.0
>>> /VTK/ThirdParty/glew/vtkglew/src/glew.c:38:
>>> /pan20/yzzhang/EGL/eglplatform.h:37:29: error: KHR/khrplatform.h: No
>>> such file or directory
>>> In file included from /pan20/yzzhang/EGL/egl.h:39,
>>>  from /pan20/yzzhang/ParaView-v5.2.0
>>> /VTK/ThirdParty/glew/vtkglew/src/glew.c:38:
>>> /pan20/yzzhang/EGL/eglplatform.h:151: error: expected ‘=’, ‘,’, ‘;’,
>>> ‘asm’ or ‘__attribute__’ before ‘EGLint’
>>> In file included from /pan20/yzzhang/ParaView-v5.2.0
>>> /VTK/ThirdParty/glew/vtkglew/src/glew.c:38:
>>> /pan20/yzzhang/EGL/egl.h:121: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>>> ‘__attribute__’ before ‘EGLBoolean’
>>> In file included from /pan20/yzzhang/ParaView-v5.2.0
>>> /VTK/ThirdParty/glew/vtkglew/src/glew.c:38:
>>> /pan20/yzzhang/EGL/egl.h:122: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>>> ‘__attribute__’ before ‘EGLBoolean’
>>> /pan20/yzzhang/EGL/egl.h:123: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>>> ‘__attribute__’ before ‘EGLContext’
>>> /pan20/yzzhang/EGL/egl.h:124: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>>> ‘__attribute__’ before ‘EGLSurface’
>>> /pan20/yzzhang/EGL/egl.h:125: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
>>> ‘__attribute__’ before ‘EGLSurface’
>>> ..
>>>
>>> Maybe it is clear that there is something wrong with the EGL header
>>> file, but I don't know how to fix it. The operation system is CentOS 6.6.
>>> There is an integrated graphics and 6 K80 GPUs. I connect to the machine
>>> using ssh and have set headless X server using one of the K80 GPUs. I can
>>> run the glxgears test in the off screen mode, but I don'n know how to make
>>> sure that EGL is correctly setted. I want to know how to use EGL for off
>>> screen rendering.
>>>
>>> Any help would be highly appreciated!
>>>
>>> -Zhang
>>>
>>>
>>>
>>>
>>> ___
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the ParaView Wiki at:
>>> http://paraview.org/Wiki/ParaView
>>>
>>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/paraview
>>>
>>>
>>
>>
>>
>>
>>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 

[Paraview] XDMF and nested Grid Collections

[Alessandro De Maio]

Hi,

I'm trying to export from a parallel MPI CFD code a set of results using
xdmf/hdf5 format in order to be read in Paraview.
The computational domain is divided into several parts (unstructured
polyhedral grid) and the idea is to write a xdmf  with a further
subdivision to be read in parallel by mpi paraview.
So it's a nested subdivision in which the external level is based on
different parts of the domain (that should be extractable in Paraview after
the reading) and each part is divided into a number of chunks equal to the
number of processes of the parallel Paraview execution. With such a
subdivision, reading this file with a parallel Paraview execution, each
Paraview process loads a fraction of each part and, if all the chunks of
each part have the same dimension, all the Paraview processes are balanced.

In the following there is an example for two parts and two Paraview
processes.

I've used nested Grid Collections of type Spatial and it seems that
everything is ok but the problem is that in Paraview the names of the first
level collection items  is lost (in the following example  tet_cell1 and
tet_cell2) and these items are called "Block 0" and "Block 1". The leaf
elements of the tree instead (Grid_01, Grid_02, ...) mantain their correct
name.

I've tried also to change the GridType of the external level from
Collection to Tree (that should be supported in the xdmf data format) but
in this case the item in Paraview is empty (0 cells and 0 nodes).

Is there any error in my procedure? It's the first time that I use xdmf.

Thank you in advance for your help.

Alessandro




http://www.w3.org/2001/XInclude; Version="3.3">
  

  

  
../positive/xdmf/tet_cell1.h5:Data0
  
  
../positive/xdmf/tet_cell1.h5:Data1
  
  
../positive/xdmf/tet_cell1.h5:Data2
  



  
../negative/xdmf/tet_cell1.h5:Data0
  
  
../negative/xdmf/tet_cell1.h5:Data1
  
  
../negative/xdmf/tet_cell1.h5:Data2
  

  

  


  
../positive/xdmf/tet_cell2.h5:Data0
  
  
../positive/xdmf/tet_cell2.h5:Data1
  
  
../positive/xdmf/tet_cell2.h5:Data2
  



  
../negative/xdmf/tet_cell2.h5:Data0
  
  
../negative/xdmf/tet_cell2.h5:Data1
  
  
../negative/xdmf/tet_cell2.h5:Data2
  


  


  

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Fwd: Segfault reading polyhedral cells xdmf3 file

[Alessandro De Maio]

Hi David,
 thank you for the correction. It should solve the problem. Without
increasing sub it will remain 0 and the Resize call does nothing.

A.

On Tue, Jan 10, 2017 at 10:20 PM, David E DeMarle <dave.dema...@kitware.com>
wrote:

> Thanks Allesandro.
>
> From your long message ;), I think that the fix then is to not overcount
> the space taken for the polyhedral cells. https://gitlab.kitware.
> com/vtk/vtk/merge_requests/2346
>
> thoughts?
>
>
> David E DeMarle
> Kitware, Inc.
> R Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909 <(518)%20881-4909>
>
> On Fri, Dec 16, 2016 at 11:11 AM, Alessandro De Maio <demai...@gmail.com>
> wrote:
>
>> I've done some more debugging on this topic.
>>
>> The problem is not related only to windows machines: the easy example
>> that I attached at the beginning of this post (polyhedron.xmf) seems to be
>> correctly opened on Linux machines, but if you try to reopen it several
>> times (for example using the new 5.2 feature of "Reload Files"), not very
>> often but sometimes it gives segfault also on Linux machines. Moreover, if
>> you try to open a bigger file (with more polyhedra inside) it fails more
>> often or, sometimes, it seems not to read all the polyhedral cells in the
>> mesh.
>>
>> I've tried to investigate the code and I think I've found the reason of
>> this behaviour, but of course, as I'm not an expert in VTK programming, a
>> more relevant opinion from the experts in this forum would be appreciated.
>> The function that builds the VTK topology starting from what has been
>> read from a xmdf file is vtkXdmf3DataSet::CopyShape in the source file
>>  vtkXdmf3DataSet.cxx (path superbuild/paraview/src/VTK/IO/Xdmf3/ in the
>> 5.2.0 superbuild building directory). In case of "mixed" XdmfTopologyType
>> (line 1460 of the file) it creates a vtkCellArray structure named vCells
>> that at line 1548 is passed to the SetCells function to create the
>> connectivity information of the DataSet. This vCells structure is filled
>> through the pointer *cells_ptr that is initially dimensioned with a size
>> equal to conn_lenght (line 1470) that is the size of the topology array
>> xTopology that comes form xdmf file reading.
>> This structure is filled as a sequence of blocks: each block for each
>> cell. If the cell is not a polyhedron it contains the number of points for
>> that cell followed by the list of pointID of the vertices. If the cell is a
>> polyhedron, as it's explained at lines 1531-1534, the cell information is
>> the sequence of: cell Lenght (that is the size of the following list for
>> that cell), the number of faces and, for each face, the number of points
>> and the list of points. So this array is exactly the same of the one that
>> has been read from the xdmf file, with the substitution of the cell type
>> for non polyhedral cells with the number of points for that cell, and, with
>> the substitution of the cell type with the cell lenght for polyhedral cells.
>>
>> But, after the loop on cells to fill this structure, at line 1547 there
>> is a call to the function Resize to reduce the Array to an overall lenght
>> index-sub where index is the original array lenght and sub is the number of
>> polyhedral cells.
>>
>> I think that this Resize call il wrong because the array lenght is
>> correct before this reduction.
>> If you print the content of the vCell structure after the Resize, for the
>> example of polyhedron.xmf, the last two elements of the array (that are the
>> last two nodes of the last hexaedron cell of the mesh) are missing.
>>
>> Probably when the SetCells function is called at line 1548 with a
>> cell_type array of the right lenght but a truncated vCells array as the
>> second argument, the missing elements of vCell array "could" be available
>>  as they should be next in memory to the truncated array, but this is not
>> guaranteed because it is randomical and it depends on the operating system
>> (that could explain the different behaviour between linux and windows).
>>
>> In any case I've tried to comment the Resize function call and the xmdf
>> reader has been able to read all the cases that I've tried to read with
>> polyhedral and not polyhedral 3d cells (there is still a problem with
>> polygons but I'll write another post on this topic).
>>
>> As I've said at the beginning of this too much long message, I hope that
>> VTK/Paraview developers give their opinion about my hypothesis.
>>
>> Thank you
>>
>> Alessand

Re: [Paraview] Fwd: Segfault reading polyhedral cells xdmf3 file

[Alessandro De Maio]

I've done some more debugging on this topic.

The problem is not related only to windows machines: the easy example that
I attached at the beginning of this post (polyhedron.xmf) seems to be
correctly opened on Linux machines, but if you try to reopen it several
times (for example using the new 5.2 feature of "Reload Files"), not very
often but sometimes it gives segfault also on Linux machines. Moreover, if
you try to open a bigger file (with more polyhedra inside) it fails more
often or, sometimes, it seems not to read all the polyhedral cells in the
mesh.

I've tried to investigate the code and I think I've found the reason of
this behaviour, but of course, as I'm not an expert in VTK programming, a
more relevant opinion from the experts in this forum would be appreciated.
The function that builds the VTK topology starting from what has been read
from a xmdf file is vtkXdmf3DataSet::CopyShape in the source file
 vtkXdmf3DataSet.cxx (path superbuild/paraview/src/VTK/IO/Xdmf3/ in the
5.2.0 superbuild building directory). In case of "mixed" XdmfTopologyType
(line 1460 of the file) it creates a vtkCellArray structure named vCells
that at line 1548 is passed to the SetCells function to create the
connectivity information of the DataSet. This vCells structure is filled
through the pointer *cells_ptr that is initially dimensioned with a size
equal to conn_lenght (line 1470) that is the size of the topology array
xTopology that comes form xdmf file reading.
This structure is filled as a sequence of blocks: each block for each cell.
If the cell is not a polyhedron it contains the number of points for that
cell followed by the list of pointID of the vertices. If the cell is a
polyhedron, as it's explained at lines 1531-1534, the cell information is
the sequence of: cell Lenght (that is the size of the following list for
that cell), the number of faces and, for each face, the number of points
and the list of points. So this array is exactly the same of the one that
has been read from the xdmf file, with the substitution of the cell type
for non polyhedral cells with the number of points for that cell, and, with
the substitution of the cell type with the cell lenght for polyhedral cells.

But, after the loop on cells to fill this structure, at line 1547 there is
a call to the function Resize to reduce the Array to an overall lenght
index-sub where index is the original array lenght and sub is the number of
polyhedral cells.

I think that this Resize call il wrong because the array lenght is correct
before this reduction.
If you print the content of the vCell structure after the Resize, for the
example of polyhedron.xmf, the last two elements of the array (that are the
last two nodes of the last hexaedron cell of the mesh) are missing.

Probably when the SetCells function is called at line 1548 with a cell_type
array of the right lenght but a truncated vCells array as the second
argument, the missing elements of vCell array "could" be available  as they
should be next in memory to the truncated array, but this is not guaranteed
because it is randomical and it depends on the operating system (that could
explain the different behaviour between linux and windows).

In any case I've tried to comment the Resize function call and the xmdf
reader has been able to read all the cases that I've tried to read with
polyhedral and not polyhedral 3d cells (there is still a problem with
polygons but I'll write another post on this topic).

As I've said at the beginning of this too much long message, I hope that
VTK/Paraview developers give their opinion about my hypothesis.

Thank you

Alessandro


On Thu, Dec 15, 2016 at 10:54 PM, David E DeMarle 
wrote:

>
> On Thu, Dec 15, 2016 at 4:39 PM, David E DeMarle  > wrote:
>
>> fails on windows
>
>
> some of the time. ;)
>
> If you open it up with the spreadsheet view (so no rendering), you can see
> that the cell connectivity array gets nonsense in it - some of the time.
> When you then open a renderview and show it, it crashes.
>
> So something about the read in of the connectivity data has an
> uninitialized/misaligned word somewhere.
>
> David E DeMarle
> Kitware, Inc.
> R Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Fwd: Segfault reading polyhedral cells xdmf3 file

[Alessandro De Maio]

Both the cases are ok on the Windows PC.

On Thu, Dec 1, 2016 at 6:19 PM, Armin Wehrfritz <dkxl...@gmail.com> wrote:

> To follow up on this issue, I have done some more testing. From the link
> below you can find two datasets with polyhedral cells, where one is
> working just fine and the other one is crashing consistently when
> opening it in ParaView 5.2.
> The XDMF files are created form the respective .vtu files with ParaView
> 5.2 (Kitware binaries, Linux 64bit) using the Xdmf3 writer.
>
> The strange thing is that the dataset leading to the seg fault is a
> subset of the dataset that just works fine.
>
> Here the link:
> https://drive.google.com/file/d/0B5CHY8CFeTf2V09NVUhTRkpYSE0
> /view?usp=sharing
>
> Alessandro, can you test these files and report back which ones are
> working on your PC?
>
> Thanks,
> Armin
>
>
>
>
>
>
>
> On 11/30/2016 08:19 PM, Alessandro De Maio wrote:
>
>> 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 <dkxl...@gmail.com
>> <mailto:dkxl...@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
>> <http://www.vtk.org/Wiki/VTK/Polyhedron_Support>). The example
>> file you send has a whole lot of faces that are not planar.
>>
>>

Re: [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  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
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Fwd: Segfault reading polyhedral cells xdmf3 file

[Alessandro De Maio]

Hi Armin,
 thank you for your reply.
I've used both for reading and writing the Xdmf3 choose.
In attach you can find the output of the saving of the polyhedron.vtu
(saved.xmf and saved.h5) from the Windows machine.

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.

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.

 Thank again for your help.

Cheers

Alessandro





 [image: Inline image 1]


On Wed, Nov 30, 2016 at 3:59 PM, Armin Wehrfritz <dkxl...@gmail.com> wrote:

> Hi Alessandro,
>
> I just tested the .xmf file on my Linux work-station using the ParaView
> 5.2 binaries from the Kitware webpage and everything works as expected.
>
> Also, reading the .vtu file and saving the data as xdmf works correctly
> on my machine.
>
> I don't have a Windows PC and have never tested this functionality
> anywhere else than under Linux. However, IIRC, the implementation of the
> polyhedral cell support doesn't have any operating system specific code.
> Just to note though, you need to use the Xdmf3 reader/writer in ParaView
> for xdmf files with polyhedral cells.
>
> Can you check that the .xmf file you generated from the .vtu file has
> the same topology information as the original .xmf file?
>
> Cheers,
> Armin
>
>
>
>
>
>
>
>
> On 11/29/2016 06:09 PM, Alessandro De Maio wrote:
>
>> Dear All,
>>  I would like to use xdmf file format for exporting polyhedral mesh
>> results from a CFD code to be opened with Paraview. If I'm not wrong
>> Paraview 5.2.0 should be able to read/write such kind o files.
>>
>> Just to understand the format of the xmf file, I've been trying to open
>> a very easy example taken from the post by Armin Wehrfritz (Tue Sep 27
>> 09:03:00 EDT 2016) in this mailing list (the title of the post was
>> "Combination of polygonal-data and unstructured grid") named
>> polyhedron.xmf (that I put in attach to this post). But using Paraview
>> 5.2.0 (Windows 64bit) binary, it gives segmentation fault immediately
>> after the "Apply" button click.
>>
>> I've tried also to read the vtu version of the same geometry
>> (polyhedron.vtu taken from the same post of Armin and in attach) and to
>> save it from Paraview in xdmf3 file format. Once I try to re-read the
>> xmf generated file, the behaviour is the same and Paraview crashes.
>>
>> Has anyone of you experience with xdmf polyhedral files in Paraview?
>>
>> Thank you in advance for any suggestion
>>
>> Alessandro De Maio
>>
>>
>> ___
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ParaView Wiki at:
>> http://paraview.org/Wiki/ParaView
>>
>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/paraview
>>
>> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>


saved.h5
Description: Binary data


saved.xmf
Description: Binary data


cube.vtu
Description: Binary data
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Segfault reading polyhedral cells xdmf3 file

[Alessandro De Maio]

Dear All,
 I would like to use xdmf file format for exporting polyhedral mesh
results from a CFD code to be opened with Paraview. If I'm not wrong
Paraview 5.2.0 should be able to read/write such kind o files.

Just to understand the format of the xmf file, I've been trying to open a
very easy example taken from the post by Armin Wehrfritz (Tue Sep 27
09:03:00 EDT 2016) in this mailing list (the title of the post was
"Combination of polygonal-data and unstructured grid") named polyhedron.xmf
(that I put in attach to this post). But using Paraview 5.2.0 (Windows
64bit) binary, it gives segmentation fault immediately after the "Apply"
button click.

I've tried also to read the vtu version of the same geometry
(polyhedron.vtu taken from the same post of Armin and in attach) and to
save it from Paraview in xdmf3 file format. Once I try to re-read the xmf
generated file, the behaviour is the same and Paraview crashes.

Has anyone of you experience with xdmf polyhedral files in Paraview?

Thank you in advance for any suggestion

Alessandro De Maio


polyhedron.xmf
Description: Binary data


polyhedron.vtu
Description: Binary data
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview