[MOAB-dev] read polygon mesh from vtk file

Huayi Wei huayiwei1984 at gmail.com
Sun Jun 29 19:50:47 CDT 2014


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
>>



More information about the moab-dev mailing list