[MOAB-dev] read polygon mesh from vtk file

Mon Jun 30 00:12:09 CDT 2014

OK,
There is a bug, indeed.
This code is not tested, it seems that it was borrowed from mesquite reader.
We never write polydata, we always write unstructured mesh in moab (with moab vtk writer)
The problem is that we need to preserve the order in the file  (it should be a standard vector of entity handles). It should be converted to a vector of ranges

when you create a polygon with different number of vertices, it will belong to a different entity sequence, and the 
order in the file and the natural handle order are different.

I will fix the this particular bug, but again, I think that for files not written by moab, we should use the vtk library reader, we should not reinvent the wheel. This moab vtk reader is very simple, and it should be used for files written by moab; 

more "bugs" will pop up, for sure. 

Iulian

________________________________________
From: Huayi Wei [huayiwei1984 at gmail.com]
Sent: Sunday, June 29, 2014 7:50 PM
To: Vijay S. Mahadevan
Cc: Grindeanu, Iulian R.; MOAB Dev
Subject: Re: [MOAB-dev] read polygon mesh from vtk file

Hi, Vijay,

I have tried to debug the code, and I think the problem maybe come from
`elem_list`. At the beginning , the reader don't insert the new polygon
handles into `elem_list`, so it keep empty. When meets  a new type
polygon which has different number of vertices with  its previous
created polygon,  reader try to insert the handles of the previous
created polygon into `elem_list`.  So maybe add a empty judgement in the
following line can solve the problem:

```
         if (first < elem_list.back().front()) // only need new range if
order would get mixed u
```

```
if( elem_list.empty() || first < elem_list.back().front() )

```

Best

Huayi

On 2014年06月30日 07:30, Vijay S. Mahadevan wrote:
> .Huayi,
>
> Thanks for the bug report. We haven't been testing the read/write of
> polygonal meshes rigorously. I was able to replicate your segfault
> with my locally configured VTK and will try to find the exact cause of
> the issue and push a fix. It is possible that the format expected
> might be different or outdated in our reader.
>
> Iulian, I'll send you the configuration commands for vtk 6.0/6.1 so
> that you can add a check in buildbot too.
>
> Vijay
>
> On Sun, Jun 29, 2014 at 6:26 PM, Huayi Wei <huayiwei1984 at gmail.com> wrote:
>> Hi, Lulian
>>
>> Thanks for your reply. The vtk file was generated by a simple matlab script
>> wrote by myself . It is very simple, and just includes the points and the
>> polygons.
>>
>> I think moab support such kind of vtk format, but maybe there exist some
>> bugs in its reading code. Please see function
>> `moab::ReadVtk::vtk_read_polygons` in `ReadVtk.cpp` file.
>>
>> Best
>>
>> Huayi
>>
>> ```
>> # vtk DataFile Version 3.0
>> MOAB 4.7.0pre
>> ASCII
>> DATASET POLYDATA
>> POINTS 26 double
>> 3.073901530231682e-06 2.977455744718462e-01 0.000000000000000e+00
>> -7.071067811865476e-01 7.071067811865475e-01 0.000000000000000e+00
>> -1.715691137876366e-01 3.536798274750831e-01 0.000000000000000e+00
>> -4.719776146377113e-01 1.857355490854607e-01 0.000000000000000e+00
>> -8.508854127205038e-01 3.599944589578263e-01 0.000000000000000e+00
>> 2.775557561562891e-16 1.000000000000000e+00 0.000000000000000e+00
>> -3.406715072241552e-01 8.588892413936710e-01 0.000000000000000e+00
>> 1.715662369808998e-01 3.536768053562428e-01 0.000000000000000e+00
>> 4.719754417201190e-01 1.857347459630188e-01 0.000000000000000e+00
>> -4.719756118732749e-01 -1.857348097293946e-01 0.000000000000000e+00
>> -1.000000000000000e+00 1.110223024625157e-16 0.000000000000000e+00
>> -8.508847507623047e-01 -3.599960570662885e-01 0.000000000000000e+00
>> 7.071067811865476e-01 7.071067811865476e-01 0.000000000000000e+00
>> 3.406701269292776e-01 8.588898131305294e-01 0.000000000000000e+00
>> 8.508845922027242e-01 3.599964398629780e-01 0.000000000000000e+00
>> -7.071067811865476e-01 -7.071067811865476e-01 0.000000000000000e+00
>> 4.719777412790575e-01 -1.857356073815120e-01 0.000000000000000e+00
>> 7.071067811865472e-01 -7.071067811865477e-01 0.000000000000000e+00
>> -3.051853356210140e-16 -1.000000000000000e+00 0.000000000000000e+00
>> 1.715687253344436e-01 -3.536802010232855e-01 0.000000000000000e+00
>> -3.319925237351595e-06 -2.977459818644166e-01 0.000000000000000e+00
>> -1.715662714497118e-01 -3.536770586038507e-01 0.000000000000000e+00
>> -3.406707216059742e-01 -8.588895668073767e-01 0.000000000000000e+00
>> 3.406712167592965e-01 -8.588893617081550e-01 0.000000000000000e+00
>> 1.000000000000000e+00 -2.775557561562891e-17 0.000000000000000e+00
>> 8.508853951409249e-01 -3.599945013986841e-01 0.000000000000000e+00
>> POLYGONS 10 64
>> 6 21 22 18 23 19 20
>> 6 20 0 7 8 16 19
>> 5 10 4 3 9 11
>> 5 12 13 7 8 14
>> 5 24 14 8 16 25
>> 5 21 9 11 15 22
>> 6 7 0 2 6 5 13
>> 5 19 23 17 25 16
>> 5 3 4 1 6 2
>> 6 21 9 3 2 0 20
>> ```
>>
>> On 2014年06月29日 23:38, Grindeanu, Iulian R. wrote:
>>> Hi,
>>> How was the file generated?
>>> our vtk reader is very simple, it does not support all vtk formats, and
>>> there is no plan to.
>>> For general vtk files, you would need to configure with vtk , I think (I
>>> am not sure, I would have to try).
>>> Vijay
>>>
>>> What was your configure command?
>>>
>>> Iulian
>>>
>>> ________________________________________
>>> From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on
>>> behalf of Huayi Wei [huayiwei1984 at gmail.com]
>>> Sent: Saturday, June 28, 2014 11:08 PM
>>> To: MOAB Dev
>>> Subject: [MOAB-dev] read polygon mesh from vtk file
>>>
>>> Hi, Moab Dev,
>>>
>>> I have a polygon mesh saved in vtk format, see attachment. I can show it
>>> by paraview. But when loading it into moab, I meet `Segmentation fault
>>> (core dumped)`
>>> error. I don't know how to fixed it. Please help me, thanks very much.
>>>
>>> Here is the cpp file.
>>> ```
>>> #include "moab/Core.hpp"
>>> #include <iostream>
>>> #include <assert.h>
>>>
>>> using namespace moab;
>>> using namespace std;
>>>
>>> int main(int argc, char ** argv)
>>> {
>>>        string file = s"/poly8-10.vtk";
>>>        Interface * imesh = new Core;
>>>
>>>        ErrorCode rval =  imesh->load_mesh(file.c_str());
>>>        assert(rval == MB_SUCCESS);
>>>
>>>        return 0;
>>> }
>>> ```
>>>
>>> And here is the information of core:
>>> ```
>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> Core was generated by `./readpolygon_test'.
>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>> #0  0x00007f3fee79cd3b in moab::Range::front (this=0xffffffffffffffe0)
>>>        at ./moab/Range.hpp:824
>>> 824      { return mHead.mNext->first; }
>>> (gdb) list
>>> 819    inline Range::const_iterator
>>> Range::const_iterator::start_of_block() const
>>> 820      { return Range::const_iterator( mNode, mNode->first ); }
>>> 821
>>> 822      //! get first entity in range
>>> 823    inline const EntityHandle& Range::front() const
>>> 824      { return mHead.mNext->first; }
>>> 825      //! get last entity in range
>>> 826    inline const EntityHandle& Range::back() const
>>> 827      { return mHead.mPrev->second; }
>>> 828
>>> ```
>>>
>>> Best
>>>
>>> Huayi
>>