CFD Online Discussion Forums - cgns grid problem

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- SU2 (https://www.cfd-online.com/Forums/su2/)

- - cgns grid problem (https://www.cfd-online.com/Forums/su2/113393-cgns-grid-problem.html)

cgns grid problem

Hello
I am trying to read a cgns file with this error.

Code:

---------------------- Read grid file information -----------------------

Reading the CGNS file: GridT_NAL_PressureModel.cgns

CGNS file contains 1 database(s).

Database 1, Base: 1 zone(s), cell dimension of 3, physical dimension of 3.

Zone 1, Zone: 326907 vertices, 887691 cells, 326907 boundary vertices.

Reading grid coordinates...

Number of coordinate dimensions is 3.

Reading CoordinateX values from file.

Reading CoordinateY values from file.

Reading CoordinateZ values from file.

Reading connectivity information...

Number of connectivity sections is 7.





   !!! Error !!!

 Unrecognized element type.

 Now exiting...

The grid is taken from here

http://cfdcenter.aero.iisc.ernet.in/...grids_user.php

Is there a way to fix this ? cgnscheck seems to be ok

Code:

$ cgnscheck GridT_NAL_PressureModel.cgns 

reading CGNS file GridT_NAL_PressureModel.cgns



reading base "Base"

reading zone "Zone"

  reading element set "fluid"

  reading element set "pressure_farfield"

  reading element set "symmetry"

  reading element set "wall_wing"

  reading element set "wall_sting_modification"

  reading element set "wall_stingbase_outer"

  reading element set "wall_stingbase_inner"

  building volume faces hash table...

  finding exterior nodes...



checking base "Base"

checking zone "Zone"

  checking coordinates "GridCoordinates"

    checking coordinate "CoordinateX"

WARNING:dataclass not given

    checking coordinate "CoordinateY"

WARNING:dataclass not given

    checking coordinate "CoordinateZ"

WARNING:dataclass not given

  checking elements

  checking element set "fluid"

  checking element set "pressure_farfield"

  checking element set "symmetry"

  checking element set "wall_wing"

  checking element set "wall_sting_modification"

  checking element set "wall_stingbase_outer"

  checking element set "wall_stingbase_inner"

  checking boundary conditions

  checking BC "pressure_farfield"

    checking BC interface

  checking BC "symmetry"

    checking BC interface

  checking BC "wall_wing"

    checking BC interface

  checking BC "wall_sting_modification"

    checking BC interface

  checking BC "wall_stingbase_outer"

    checking BC interface

  checking BC "wall_stingbase_inner"

    checking BC interface



checking complete

3 warnings (3 shown)

The unrecognized element has

elemType = 20

Hi Praveen,

It looks like the mesh has elements of type HEXA_20 (extra nodes at the midpoints of each hex edge), while our reader was written with HEXA_8 elements in mind. Please see the page here for more information: http://www.grc.nasa.gov/WWW/cgns/CGN...l#unstructgrid.

We are currently working to expand the CGNS input and output capabilities. In the meantime, if you are interested in modifying the current CGNS implementation to suit your needs, the code for the reader can be found in geometry_structure.cpp around lines 800-1500.

T

Thanks. I will try. I did notice some strange behaviour. We are finding number of nodes in the element here

Code:



               /*--- Find the number of nodes required to represent

             this type of element. ---*/



               if ( cg_npe(elemType, &npe) ) cg_error_exit();

               elemIndex[j-1][s-1] = npe;

When I print out npe for the elemType=20, it is showing zero

Code:



               default:

                  printf( "\n\n   !!! Error !!!\n" );

                  printf( " Unrecognized element type = %d.\n", elemType);

                  printf( " Number of nodes           = %d.\n", npe);

                  printf( " Now exiting...\n\n");

                  exit(0);

                  break;

Output

Code:



   !!! Error !!!

 Unrecognized element type = 20.

 Number of nodes           = 0.

 Now exiting...

Does this look right ?

Looking at cgnslib.h, I see that type 20 is MIXED

Code:

483 CGNS_ENUMV( MIXED ) =20,

and such type it does return npe=0

Code:

513 #define  CG_NPE_MIXED     0

.

.



536 #define  NPE_MIXED     0

Do you know how to distinguish the element type in this case ?

Update: The MIXED element format is explained here

http://cgns.sourceforge.net/Proposed...ts_of_sids.pdf

on page No. 68. I think its not so easy to modify su2 to handle this case.

Indeed, we wrote the reader to handle separate element types rather than mixed elements within one zone (this seems to be how the mesh generation software that we most frequently use exports unstructured CGNS meshes).

That being said, it certainly isn't impossible to modify the current reader to handle this situation. In fact, I am sure other folks might be interested in something like this too. If you think you might want to give this a try, please feel free to ask questions about the current implementation in SU2.

I had the same problem.
I do not know how to fix that by modifying the code. So I used ICEM to convert the cell type. i.e. convert quad cell to triangle cell.
Then the cgns format can be converted to su2 format by the program.
It worked for me, although the number of elements increased, and costed more computational time, but the result was pretty good.

Ah, I had been curious about that, because we had heard that some ICEM grids were causing problems with the CGNS reader in SU2 (I don't have access to ICEM).

So, you can confirm that having mixed element types is indeed the issue w/ CGNS meshes from ICEM in SU2? Was it 2D or 3D? Same issues for interior vs. boundary elements?

Thanks for the feedback. This will help guide some upgrades to the CGNS reader in SU2...

In my cases, y++<1, so I used hybrid mesh, namely inflation of quad(2d) or hex(3d) cells on the boundary (airfoil).
After then, I used ICEM to convert all quad to tri (2d) or all cell to tetra (3d) in the Edit Mesh Tab. Otherwise, same error would occur, as shown in #1.
Finally, the exported CGNS grid can be successfully converted and used in SU2.

Dear Praveen,

Did you find a workaround for this problem?
I am also trying to use the same mesh for the workshop and I have the same problem.

We created a converter from GridPro to SU2, but at first we would like to try the organiser's grids with both SU2 and OpenFOAM

No. I am planning to write a separate converter from cgns to su2 format but I have not had time to work on it.

Dear all,

My colleague Martin SPEL modified the source code in order to be able to handle the zones with mixed elements. It actually had nothing to do with HEX 20 elements.

There was also another problem which was that we couldn't run the CGNS conversion if the code was compiled with MPI activated. It is now possible, since we only check if we are running parallel or not (not compilation based).

Please, find attached the modified file.

Vincent,

Thank you for sharing: this is a great contribution! If it is alright with you and your colleague, I would like to adapt the code that you have shared and place it into the current version of SU2 so that it will be available in the next release.

I'll be in touch to discuss further,
Tom

Thanks for this. I tried it on my cgns grid. I am able to save the mesh in su2 format but cannot run the cfd with the cgns mesh, some segmentation fault.

However I do not get segmentation fault if I run with the converted su2 mesh file.

Hi Praveen,

Totally normal from what I understood. SU2 does not handle CGNS in parallel so far.
So you have to first run a serial computation, at least up to the CGNS conversion. And then you can run your parallel computation using the SU2 mesh obtained from the previous computation.

A bit tricky, but at least it works ;)

@Tom: No problem, I sent you an email regarding the code.

I was making a serial run on the cgns file when the segmentation occurred. But yes, I can just use the converted file. Thanks.

Thanks a lot, it works.
Help me saving much computational cost.

Hi all,

For those who are failing to convert quad cells using cgns from ICEMCFD 14.5, just select cgns version 2.4 and SU2 is able to convert the files. I saw here in CFDOnline that other people are facing the same CGNS problem with version later than ICEM 12.1.

Cheers.

Hello Guys,

I keep getting a similar error but I cannot compile with the archive *.cpp attached above.Am I supposed to do so? Does anyone have any idea what the problem may be?

Code:

---------------------- Read grid file information -----------------------

Reading the CGNS file: Patrulha6.cgns

CGNS file contains 1 database(s).

Database 1, Unstructured data: 1 zone(s), cell dimension of 3, physical dimension of 3.

Zone 1, Patrulha5: 6743713 vertices, 6203599 cells, 0 boundary vertices.

Reading grid coordinates...

Number of coordinate dimensions is 3.

Reading CoordinateX values from file.

Reading CoordinateY values from file.

Reading CoordinateZ values from file.

Reading connectivity information...

Number of connectivity sections is 20.





   !!! Error !!!

 Unrecognized element type.

 Now exiting...

Thank you all,
Regards
JuB

Quote:

Originally Posted by JuB (Post 479182)

Hello Guys,

I keep getting a similar error but I cannot compile with the archive *.cpp attached above.Am I supposed to do so? Does anyone have any idea what the problem may be?

Code:

---------------------- Read grid file information -----------------------

Reading the CGNS file: Patrulha6.cgns

CGNS file contains 1 database(s).

Database 1, Unstructured data: 1 zone(s), cell dimension of 3, physical dimension of 3.

Zone 1, Patrulha5: 6743713 vertices, 6203599 cells, 0 boundary vertices.

Reading grid coordinates...

Number of coordinate dimensions is 3.

Reading CoordinateX values from file.

Reading CoordinateY values from file.

Reading CoordinateZ values from file.

Reading connectivity information...

Number of connectivity sections is 20.





   !!! Error !!!

 Unrecognized element type.

 Now exiting...

Thank you all,
Regards
JuB

I think the archive above should be compiled with version 2.XXX instead of version 3.0