Failure on shm meshes

[SiHubb]

Hi Bruno,

I've just tried to convert snappyHexMesh meshes to cgns and it's having trouble looking up cell vertices. Below is the output (I've run snappy in parallel with -overwrite and reconstructed back in to /constant, the same problem exists if you mesh in serial and use -time to pick a time level from snappy output).

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  5.x                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 5.x-197d9d3bf20a
Exec   : foamToCGNS -constant -noZero
Date   : Dec 14 2018
Time   : 13:57:19
Host   : "instance-1"
PID    : 6167
I/O    : uncollated
Case   : /home/simonjameshubbard/motorBike
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = constant
Default value for rho: 1
Warning : log file not found. No convergence history will be included.
Time = constant
CGNS output file : "/home/simonjameshubbard/motorBike/ConversionCGNS/constant.cgns"
Processing the mesh: 404990 nodes, 352465 cells
Processing mesh connectivity: 352465 cells of type: "MIXED"
--> FOAM FATAL ERROR: 
Wrong number of vertices in cell
    expected 4,5,6, or 8, found 0
    From function foamToCGNS
    in file writeCGNS.H at line 219.
FOAM aborting
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  ? at ??:?
#3  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#4  ? at ??:?
Aborted (core dumped)

The mesh seems OK - checkMesh doesn'tflag anything up.

This was from the standard $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike case. I've tried it on other similar cases with the same result. It will work fine on the results of blockMesh, but seems to struggle with snappy.

Let me know if there's anything else I can do to help.

Thanks,

Simon.

[wyldckat]

So part of the answer is given here: https://www.cfd-online.com/Forums/openfoam-meshing/117743-cgnstofoam-error-when-converting-icem-mesh.html#post428326

Namely that there is apparently a flaw in the mesh, hence the error message.

However, after looking at the code, I find it really strange why it's telling us it has zero vertices... because that would also require 0 faces, which checkMesh does not report to us as a possibility.

That said, there is a critical limitation in the code and as indicated in the message: only Wrong number of vertices in cell expected 4,5,6, or 8 vertices are supported, but snappyHexMesh will generate cells that have more than 8 vertices... this alone:

    polyhedra:     35136
    Breakdown of polyhedra by number of faces:
        faces   number of cells
            4   3990
            5   6550
            6   5456
            7   2964
            8   1300
            9   10610
           10   18
           11   7
           12   2341
           13   2
           14   1
           15   1636
           17   1
           18   259
           21   1

gives a brief notion of how many vertices there might be in this mesh... which can easily be 21 or more vertices, given that the minimum 4 faces will use 4 vertices in a tetrahedra or similar.

Looking further into the code, it seems that what's missing is an extension of the existing definitions in applications/utilities/postProcessing/dataConversion/foamToCGNS/vertexMappingOpenFoamCGNS.H: https://github.com/wyldckat/cgnsToFromFoam/blob/OF5x/applications/utilities/postProcessing/dataConversion/foamToCGNS/vertexMappingOpenFoamCGNS.H

OpenFOAM does have a list of cells that it is meant to support: https://github.com/OpenFOAM/OpenFOAM-5.x/blob/master/etc/cellModels - but the main problem that I can see is that general polyhedral cells are not listed on this file...

So my conclusion so far is that implementing something that can handle general polyhedral cell conversion may be a bit overly complex... that said, foamToVTK does this: https://github.com/OpenFOAM/OpenFOAM-5.x/blob/master/applications/utilities/postProcessing/dataConversion/foamToVTK/foamToVTK/vtkTopo.C#L310

So what's missing is the connectivity matrix... namely the one that converts one orientation of vertices to another... ok, it's allegedly straight forward...

OK, I think that all that I'm missing is this: How are you seeing in 3D the resulting CGNS files? I don't remember if ParaView is able to open them or not...

[SiHubb]

Thanks Bruno.

I'm looking at the 3D CGNS meshes in Paraview - it will read the grid in, but doesn't understand the boundary condition descriptions. I've just had a quick look with Gmsh and it seems that will read 3D CGNS in too. 

[wyldckat]

Hi Simon,

I hope you don't mind, but I'll be editing this comment a lot in the next minutes, while I sift through the information as I progress on things...

1. The cell shape type 0 is referring to polyhedral cells, hence the zero... given that it's not in any of the standard shapes, nor in one of the other shapes listed in etc/cellModels.
2. Generic polyhedral notation exists, as documented here: https://cgns.github.io/CGNS_docs_current/sids/sids.pdf - section "7.3 Elements Structure Definition".
   • On section 7.4 there are more details on how this can be implemented.

[wyldckat]

@SiHubb: My apologies, but I'm not well enough today... the freaking flu still has my body under its wraps, even though it's allegedly almost cured.

I'll tweet about this issue, perhaps someone else is able to pick this up and work on it.

[SiHubb]

@wyldckat No need to apologise - thanks for taking a look. I'm on the tail end of a bug, which is also taking it's time to shift, so I know the feeling.