Change UNV pyr to type 119?

1

Hello,

is it possible to change easily the format salome exports pyramids UNV? in the latests documentaiton it mentions:

Export to UNV of pyramids. According to available documentation, linear pyramids can be stored as
dataset 119 or 312. As VisIt-LLNL, the only other open-source code that reads pyramids from UNV,
reads them as dataset 312, we chose to export them as dataset 312. In import, SALOME can read
them as dataset 119 and 312.

When trying to import UNV with pyramids to OpenFOAM, it fails:

 → FOAM Warning :
From function void readCells(Foam::IFstream&, Foam::DynamicListFoam::cellShape&, Foam::DynamicList&, Foam::DynamicList&, Foam::DynamicListFoam::face&, Foam::DynamicList&, Foam::DynamicList&)
in file ideasUnvToFoam.C at line 463
Reading “Mesh_1.unv” at line 9818
Cell type 312 not supported

I wanted to check if by using the dataset 119 instead of the 312 for the exporting, one can use UNV as direct file format to link Salome & OpenFOAM.

@cbourcier , any inputs on this? I saw that you worked on the commit , do i need to download the complete source, modify src/DriverUNV/DriverUNV_W_SMDS_Mesh.cxx & src/DriverUNV/UNV2412_Structure.cxx

change 312 to 119 and recompile the hole salome?

2

Hello Franco,

Unfortunately, OpenFoam’s UNV reader does not manage dataset 119 or 312. Here are 2 versions of the same mesh so that you can test without compiling SMESH.

Mesh_pyra.zip (26,5 Ko)

Running ideasUnvToFoam.exe on these files gives:

  • 119:
--> FOAM Warning :
    From void readCells(Foam::IFstream&, Foam::DynamicList<Foam::cellShape>&, Foam::DynamicList<int>&, Foam::DynamicList<int>&, Foam::DynamicList<Foam::face, 16>&, Foam::DynamicList<int>&, Foam::DynamicList<int>&)
    in file ideasUnvToFoam.C at line 453
    Reading "Mesh_pyra_119.unv" at line 1010
    Cell type 119 not supported
  • 312:
--> FOAM Warning :
    From void readCells(Foam::IFstream&, Foam::DynamicList<Foam::cellShape>&, Foam::DynamicList<int>&, Foam::DynamicList<int>&, Foam::DynamicList<Foam::face, 16>&, Foam::DynamicList<int>&, Foam::DynamicList<int>&)
    in file ideasUnvToFoam.C at line 453
    Reading "Mesh_pyra_312.unv" at line 1010
    Cell type 312 not supported

Indeed, we can see in ideasUnvToFoam.C (search for “feID ==”) that these datasets are not read. The reader needs to be improved in OpenFoam’s side.

Christophe

1 Like
3

Thanks for your answer @cbourcier , I made the required modification and created an issue for every branch of OF.

now its up to the developpers to merge it to the main.

regards,

1 Like
Export/import issues format Salome/gmsh/OpenFOAM [solved]
4

Thank you Franco for having added this! I hope it will be integrated in OpenFoam.

5

My pleasure, .Com version already answered that it will be added to the source. you might be able to help me to solve the remaining issue from unv. Currently if we export a unv mesh with 1d groups, ideasUnvToFoam will crash, same mesh exported without the 1d groups will work correctly.

My current issue is that in contrast with the previous crashing, the output from openfoam side it is not giving me any good clues on the reason behind the crashing. Could you point me to where the 1d groups are treated while being exported in Salome on the source/any documentation on how it is dealt with them in the format specifications (I did not find much information on it over internet)? This might help me to find the culprit, if it’s Salome side or openfoam and if it’s ideasUnvToFoam culprit try to enmend it so the user does not need to remove the 1d groups before exportation (which creates confusion to new users).

6

ideasUnvToFoam.C does not read edges. As we can see line 308, edges (elements with feID == 11) are skipped.

It does not deal with group of edges neither. All groups are considered as groups of faces. As we can see in the example Mesh_hexa_edges.zip (691 Octets) where all_edges is a group of edges, the log shows:

0: all_edges is faceZone

When dealing with groups, it tries to find elements id for each group. For edges, as no element has been created, it does not find the element, and raise an error.

3 not found in table. Valid entries: 6(16 17 18 13 14 15)

To avoid this, we can store the edges ids and skip the groups of edges when reading the groups. I have made the modifications in ideasUnvToFoam.C.patch (2,8 Ko). It works well for the unv samples I have.

In the meanwhile, before it is being integrated, a simple workaround is to delete group of edges in SALOME before exporting to unv.

Christophe

1 Like
7

I opened the issues for this to be merged, thanks for it.

1 Like