[Shibi]

Hello to all Foamers,

I will state my problem:



I am creating a case where 2 solids in contact are transferring heat to the surrounding air. I am using OpenFOAM v1912.



I generated the mesh with snappyHexMesh and I am happy with the end result.
However, I am getting problems when I use the splitMeshRegion -cellZones utility. It creates domains not defined by me with zones having negative values. I do not know where do these domains came from and would like a methodology to solve this.

0    0    air
1    1    solid1
2    2    solid2
3    -1    domain3
4    -1    domain4
5    -1    domain5
6    -1    domain6
7    -1    domain7


. . .

I used two methodologies to generate the mesh and would like to share it with you for a more contextualized question.


Methodology 1:
I first ran surfaceCheck to check if both solids where closed.

The results showed that there was no problem with the stls.

Then, I created the background mesh with blockMesh and attributed a cellZone to it via :

blocks
(
    hex (0 1 2 3 4 5 6 7 ) air (40 40 40) simpleGrading (1 1 1)
   
);

Afterwards, I generated the mesh for the different regions with snappyHexMesh and used the following approach to define cellZones and cellFaces:

    refinementSurfaces
    {
      solid1
        {
        // Surface-wise min and max refinement level
        level (4 4);

        // Define cell and Face Zones
        faceZone solid1;
        cellZone solid1;
        cellZoneInside insidePoint;
        insidePoint (-3.021234 10.04124 -132.51234);
        } 


       solid2
        {
        // Surface-wise min and max refinement level
         level (3 3);

        // Define cell and Face Zones
        faceZone solid2;
        cellZone solid2;
        cellZoneInside insidePoint;
        insidePoint (-3.021234 5.04124 -132.51234);
    
        } 
    }

I used as location in Mesh a point within the air domain.




The mesh is Ok, but when I use the splitMeshRegions -cellZones I get the multiple domains which I referred to in the beginning of the post.





CheckMesh result:

Checking patch topology for multiply connected surfaces...
                   Patch    Faces   Points                  Surface topology
                   inlet     3600     3721  ok (non-closed singly connected)
                  outlet     3600     3721  ok (non-closed singly connected)
                   walls    14400    14640  ok (non-closed singly connected)

Checking faceZone topology for multiply connected surfaces...
                FaceZone    Faces   Points                  Surface topology
                    solid1    34731    40381  multiply connected (shared edge)
                   solid2   167899   175310  multiply connected (shared edge)
  <<Writing 280 conflicting points to set nonManifoldPoints

Checking basic cellZone addressing...
                CellZone        Cells       Points       VolumeBoundingBox
                    air       938384      1153598    0.9995443 (-0.5037818 -0.4477832 -0.6351975) (0.4962182 0.5522168 0.3648025)
                   solid1       140552       182724 0.0003240833 (-0.0463241 -0.01032742 -0.2624402) (0.04019703 0.02055706 -0.002523096)
                  solid2       242021       349657 0.0001315835 (-0.04803438 0.007296541 -0.2642762) (0.04047093 0.09695013 -0.006148401)

Checking geometry...
    Overall domain bounding box (-0.5037818 -0.4477832 -0.6351975) (0.4962182 0.5522168 0.3648025)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (9.670993e-16 9.711741e-17 4.235526e-16) OK.
    Max cell openness = 3.987074e-16 OK.
    Max aspect ratio = 12.61511 OK.
    Minimum face area = 1.304291e-08. Maximum face area = 0.0002779737.  Face area magnitudes OK.
    Min volume = 6.190595e-12. Max volume = 4.632872e-06.  Total volume = 1.  Cell volumes OK.
    Mesh non-orthogonality Max: 61.39361 average: 11.34664
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 1.485724 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

I found out that I could run splitMeshRegions -cellZonesOnly and in fact get only the domains I specified, however, when I run the case I would get the error bellow which I assume is due to lake of regions that where not considered.

Time = 1


Solving for fluid region air
DILUPBiCGStab:  Solving for Ux, Initial residual = 1, Final residual = 0.0116219, No Iterations 1
DILUPBiCGStab:  Solving for Uy, Initial residual = 1, Final residual = 0.001894981, No Iterations 1
DILUPBiCGStab:  Solving for Uz, Initial residual = 1, Final residual = 0.0113973, No Iterations 1
DILUPBiCGStab:  Solving for h, Initial residual = 1, Final residual = 0.0006057759, No Iterations 1
Min/max T:273 273.1336
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in /lib/x86_64-linux-gnu/libc.so.6
#3  Foam::DICPreconditioner::calcReciprocalD(Foam::Field<double>&, Foam::lduMatrix const&) at ??:?
#4  Foam::DICPreconditioner::DICPreconditioner(Foam::lduMatrix::solver const&, Foam::dictionary const&) at ??:?
#5  Foam::lduMatrix::preconditioner::addsymMatrixConstructorToTable<Foam::DICPreconditioner>::New(Foam::lduMatrix::solver const&, Foam::dictionary const&) at ??:?
#6  Foam::lduMatrix::preconditioner::New(Foam::lduMatrix::solver const&, Foam::dictionary const&) at ??:?
#7  Foam::PCG::scalarSolve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#8  Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const at ??:?
#9  Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:?
#10  Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#11  Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
#12  Foam::fvMatrix<double>::solveSegregatedOrCoupled(Foam::dictionary const&) at ??:?
#13  Foam::fvMesh::solve(Foam::fvMatrix<double>&, Foam::dictionary const&) const at ??:?
#14  Foam::fvMatrix<double>::solve() in ~/OpenFOAM/OpenFOAM-v1912/platforms/linux64GccDPInt32Opt/bin/chtMultiRegionSimpleFoam
#15  ? in ~/OpenFOAM/OpenFOAM-v1912/platforms/linux64GccDPInt32Opt/bin/chtMultiRegionSimpleFoam
#16  __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#17  ? in ~/OpenFOAM/OpenFOAM-v1912/platforms/linux64GccDPInt32Opt/bin/chtMultiRegionSimpleFoam
Floating point exception (core dumped)

With paraview I was able to see that the zones it created were in the interface between both solids [image in attachment].




Methodology 2:

All of the setting used in the snappyHexMesh were the same except for the definition of the regions.


Here, I did not define any region with blockMesh


and everything with SHMdict as follows:

locationsInMesh
(
      ((-3.021234 10.04124 -132.51234)     solid1)
      ((-3.021234 5.04124 -132.51234)       solid2)
      ((100.1234 0.1234 0.1234)                  air)
);

With this approach, I ran splitMeshRegion -cellZones without any problem and was able to get only the regions I wanted. However, for some reason it created patches with the names of the regions I defined.

Checking patch topology for multiply connected surfaces...
                   Patch    Faces   Points                  Surface topology
                   inlet     3600     3721  ok (non-closed singly connected)
                  outlet     3600     3721  ok (non-closed singly connected)
                   walls    14400    14640  ok (non-closed singly connected)
                    solid1      645     1117  ok (non-closed singly connected)
                   solid2      690     1188  ok (non-closed singly connected)

Checking faceZone topology for multiply connected surfaces...
                FaceZone    Faces   Points                  Surface topology
             solid1_to_air    23995    25495  ok (non-closed singly connected)
            solid2_to_air   152673   156544  multiply connected (shared edge)
           solid2_to_solid1    24663    26057  ok (non-closed singly connected)
  <<Writing 190 conflicting points to set nonManifoldPoints

Checking basic cellZone addressing...
                CellZone        Cells       Points       VolumeBoundingBox
                  solid2       242020       349664     131529.9 (-48.03443 7.322347 -264.2761) (40.46967 96.95013 -6.123892)
                   solid1       140552       182706     324154.9 (-46.31507 -10.32614 -262.4393) (40.19727 20.53908 -2.522975)
                    air       938067      1152245 9.995443e+08 (-503.7818 -447.7832 -635.1975) (496.2182 552.2168 364.8025)

Checking geometry...
    Overall domain bounding box (-503.7818 -447.7832 -635.1975) (496.2182 552.2168 364.8025)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (7.70767e-16 -1.114579e-16 3.747821e-16) OK.
    Max cell openness = 5.113948e-16 OK.
    Max aspect ratio = 11.17296 OK.
    Minimum face area = 0.006413276. Maximum face area = 277.9738.  Face area magnitudes OK.
    Min volume = 0.006188031. Max volume = 4632.874.  Total volume = 1e+09.  Cell volumes OK.
    Mesh non-orthogonality Max: 61.4087 average: 11.33247
    Non-orthogonality check OK.
    Face pyramids OK.
 ***Max skewness = 17.17423, 68 highly skew faces detected which may impair the quality of the results
  <<Writing 68 skew faces to set skewFaces
    Coupled point location match (average 0) OK.

Failed 1 mesh checks.

End

After assigning some boundary conditions to created patches the simulation did not give any problem...


As anyone experienced something like this?
Why does snappyHexMesh create these patches and why does the splitMeshRegions utility create the previously mentioned zones? Does anyone know of a methodology to go around this?
Thanks!