[AlexandrosVouros]

Dear all,

I am using snappyHexMesh for a multiple regions heat fluid flow and heat transfer problem. I have checked heated duct tutorial and also, chtMultiRegionFoam_snappyMultiRegionHeater, which by the way is not working properly. My setup involves a very small cylinder that is imposed in the flow field through a hole in the cylindrical pipe

After the snappyHexMesh execution, the log file seems fine, decomposePar fails to work; the following error is found in the log file.


Decomposing mesh fluid

--> FOAM FATAL IO ERROR:
problem while reading header for object decomposeParDict

file: C:/OpenFOAM/20.09/Alex-dev/run/pipeProbeTest/system/fluid/decomposeParDict at line 1.

From function virtual Foam::autoPtr<Foam::ISstream> Foam::fileOperations::uncollatedFileOperation::rea dStream(Foam::regIOobject&, const Foam::fileName&, const Foam::word&, bool) const
in file global/fileOperations/uncollatedFileOperation/uncollatedFileOperation.C at line 559.

FOAM exiting


The truth is that I am not sure if I am missing something related to proper decomposition of multiregion problems or there is a problem in the setup. (Case files are attached). Please do not check the quality of the mesh, unless you think that have an impact. (Mesh looks bad for the moment, since the setting used in the heated duct tutorial are used.)

I work with OpenFoam 20.09 version, downloaded from cfd support (based on headers, it looks like a dev version actually) and installed in windows (8.1).

Thanks for your time,
Alex

[Alczem]

Hey,


After a quick look, I think you should just delete the decomposeParDict files for all the regions, and replace them by the one in the system folder, or just write another from scratch. The current ones seem unreadable. Maybe someone else can confirm.

[AlexandrosVouros]

Many thanks!

They, indeed, look corrupted!

[AlexandrosVouros]

Hi,

The decomposition seems ok.
But now, after Allrun, in the "boundary" file of a region faces that belong to other regions are included!


Thanks you in advance!

[AlexandrosVouros]

Ok.

It seems that updating the boundaries "by hand" it can work. But is there any logic for this one or it can be considered a bug?

Could someone please let me know if he/she has faced something similar?

Thanks in advance,
Alex

[Alczem]

I am not sure I understood the issue correctly, so this might be totally useless, but did you use decomposePar -allRegions to decompose your mesh regions by regions? The way you describe it makes me think that the mesh was decomposed as one region. With the -allRegions option, you should have a polymesh folder created for each region, so your case structure would look like constant/fluid/polyMesh and constant/solid/polyMesh.

[AlexandrosVouros]

Thank you for the response.

The decomposition is made using -all regions. Apologies for the weak explanation.

[AlexandrosVouros]

A more recent version of the configuration is attached. Now, three regions are formed but a small number of faces (about 2) seem to cause the introduction of wrong boundaries in the regions.


I tried to correct boundaries so that only the expected ones are included in each of the regions. - I also noticed that something similar is found in the allrun file of the chtmultiregionheater tutorial -. However, after editing boundaries decomposePar failed with the following error:


Alex@AlexPC /cygdrive/c/OpenFOAM/20.09/Alex-dev/run/working/pipeProbefluidMeshRun
$ decomposePar -allRegions
/*---------------------------------------------------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: dev
\\/ M anipulation |

OpenFOAM for Windows 20.09 (v1)
Built by CFD Support, www.cfdsupport.com (based on Symscape).
\*---------------------------------------------------------------------------*/
Build : dev-d26757ee1926
Exec : C:\OpenFOAM\20.09\cygwin64\opt\OpenFOAM\OpenFOAM-dev\platforms\cygwin64mingw-w64DPInt32Opt\bin\decomposePar.exe -allRegions
Date : Apr 25 2023
Time : 20:51:03
Host : "ALEXPC"
PID : 7184
I/O : uncollated
Case : C:/OpenFOAM/20.09/Alex-dev/run/working/pipeProbefluidMeshRun
nProcs : 1
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time



Decomposing mesh fluid

Create mesh

Calculating distribution of cells
Selecting decompositionMethod hierarchical

Finished decomposition in 0.077 s

Calculating original mesh data

Distributing cells to processors

Distributing faces to processors

Distributing points to processors

Constructing processor meshes

Processor 0
Number of cells = 21686
Number of faces shared with processor 1 = 970
Number of processor patches = 1
Number of processor faces = 970
Number of boundary faces = 9220

Processor 1
Number of cells = 21686
Number of faces shared with processor 0 = 970
Number of faces shared with processor 2 = 566
Number of processor patches = 2
Number of processor faces = 1536
Number of boundary faces = 8025

Processor 2
Number of cells = 21686
Number of faces shared with processor 1 = 566
Number of faces shared with processor 3 = 473
Number of processor patches = 2
Number of processor faces = 1039
Number of boundary faces = 8142

Processor 3
Number of cells = 21689
Number of faces shared with processor 2 = 473
Number of processor patches = 1
Number of processor faces = 473
Number of boundary faces = 9293

Number of processor faces = 2009
Max number of cells = 21689 (0.010375% above average 21686.8)
Max number of processor patches = 2 (33.3333% above average 1.5)
Max number of faces between processors = 1536 (52.9119% above average 1004.5)

Time = 0

Processor 0: field transfer
Processor 1: field transfer
Processor 2: field transfer
Processor 3: field transfer


Decomposing mesh thinWall

Create mesh

Calculating distribution of cells
Selecting decompositionMethod hierarchical

Finished decomposition in 0.035 s

Calculating original mesh data

Distributing cells to processors

Distributing faces to processors

Distributing points to processors

Constructing processor meshes

Processor 0
Number of cells = 10714
Number of faces shared with processor 1 = 284
Number of processor patches = 1
Number of processor faces = 284
Number of boundary faces = 13008


--> FOAM FATAL ERROR:
Cell 9478contains face labels out of range: 6(30928 -1 38553 38554 21536 21545) Max face index = 39309

From function Foam:olyMesh:olyMesh(const Foam::IOobject&, Foam:ointField&&, Foam::faceList&&, Foam::cellList&&, bool)
in file meshes/polyMesh/polyMesh.C at line 659.

FOAM aborting


This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Alex@AlexPC /cygdrive/c/OpenFOAM/20.09/Alex-dev/run/working/pipeProbefluidMeshRun


When I tried a non-parallel run, the solver performed a single iteration for the fluid and thenit also stopped and the following error message was displayed:


Alex@AlexPC /cygdrive/c/OpenFOAM/20.09/Alex-dev/run/working/pipeProbefluidMeshRun
$ chtMultiRegionFoam
/*---------------------------------------------------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: dev
\\/ M anipulation |

OpenFOAM for Windows 20.09 (v1)
Built by CFD Support, www.cfdsupport.com (based on Symscape).
\*---------------------------------------------------------------------------*/
Build : dev-d26757ee1926
Exec : C:\OpenFOAM\20.09\cygwin64\opt\OpenFOAM\OpenFOAM-dev\platforms\cygwin64mingw-w64DPInt32Opt\bin\chtMultiRegionFoam.exe
Date : Apr 25 2023
Time : 20:51:36
Host : "ALEXPC"
PID : 5900
I/O : uncollated
Case : C:/OpenFOAM/20.09/Alex-dev/run/working/pipeProbefluidMeshRun
nProcs : 1
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create fluid mesh for region fluid for time = 0

Create solid mesh for region thinWall for time = 0

Create solid mesh for region probe for time = 0

*** Reading fluid mesh thermophysical properties for region fluid

Adding to thermoFluid

Selecting thermodynamics package
{
type heRhoThermo;
mixture pureMixture;
transport const;
thermo hConst;
equationOfState rhoConst;
specie specie;
energy sensibleEnthalpy;
}

Adding to rhoFluid

Adding to UFluid

Adding to phiFluid

Adding to gFluid

Adding to hRefFluid

Adding to ghFluid

Adding to ghfFluid

Adding to turbulenceFluid

Selecting turbulence model type laminar
Selecting laminar stress model Stokes
Adding to reactionFluid

Combustion model not active: combustionProperties not found
Selecting combustion model none
Adding to radiationFluid

Radiation model not active: radiationProperties not found
Selecting radiationModel none
Adding to KFluid

Adding to dpdtFluid

Adding to fieldsFluid

Adding MRF

No MRF models present

Adding fvOptions

*** Reading solid mesh thermophysical properties for region thinWall

Adding to thermos

Selecting thermodynamics package
{
type heSolidThermo;
mixture pureMixture;
transport constIso;
thermo hConst;
equationOfState rhoConst;
specie specie;
energy sensibleEnthalpy;
}

Adding to radiations

Radiation model not active: radiationProperties not found
Selecting radiationModel none
Adding fvOptions

*** Reading solid mesh thermophysical properties for region probe

Adding to thermos

Selecting thermodynamics package
{
type heSolidThermo;
mixture pureMixture;
transport constIso;
thermo hConst;
equationOfState rhoConst;
specie specie;
energy sensibleEnthalpy;
}

Adding to radiations

Radiation model not active: radiationProperties not found
Selecting radiationModel none
Adding fvOptions


PIMPLE: Region fluid
PIMPLE: No convergence criteria found


PIMPLE: Region thinWall
PIMPLE: No convergence criteria found


PIMPLE: Region probe
PIMPLE: No convergence criteria found


PIMPLE: Operating solver in transient mode with 1 outer corrector
PIMPLE: Operating solver in PISO mode


Region: fluid Courant Number mean: 0.00123054 max: 0.0106757
Region: thinWall Diffusion Number mean: 0.836404 max: 317.404
Region: probe Diffusion Number mean: 0.811525 max: 137.86
--> FOAM Warning :
From function bool Foam::functionObjectList::read()
in file db/functionObjects/functionObjectList/functionObjectList.C at line 871
Caught FatalError
--> FOAM FATAL ERROR:

request for objectRegistry solid from objectRegistry pipeProbefluidMeshRun failed
available objects of type objectRegistry are

3
(
probe
fluid
thinWall
)


From function const Type& Foam:bjectRegistry::lookupObject(const Foam::word&) const [with Type = Foam:bjectRegistry]
in file db/objectRegistry/objectRegistryTemplates.C at line 211.

deltaT = 3.1505e-05
--> FOAM Warning :
From function bool Foam::functionObjectList::read()
in file db/functionObjects/functionObjectList/functionObjectList.C at line 871
Caught FatalError
--> FOAM FATAL ERROR:

request for objectRegistry solid from objectRegistry pipeProbefluidMeshRun failed
available objects of type objectRegistry are

3
(
probe
fluid
thinWall
)


From function const Type& Foam:bjectRegistry::lookupObject(const Foam::word&) const [with Type = Foam:bjectRegistry]
in file db/objectRegistry/objectRegistryTemplates.C at line 211.

Region: fluid Courant Number mean: 3.87681e-05 max: 0.000336337
Region: thinWall Diffusion Number mean: 0.0263509 max: 9.99983
Region: probe Diffusion Number mean: 0.0255671 max: 4.34329
deltaT = 3.1505e-05
Time = 3.1505e-05


Solving for fluid region fluid
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for Ux, Initial residual = 1, Final residual = 7.95669e-12, No Iterations 1
DILUPBiCGStab: Solving for Uy, Initial residual = 1, Final residual = 4.21493e-12, No Iterations 1
DILUPBiCGStab: Solving for Uz, Initial residual = 1, Final residual = 2.08602e-12, No Iterations 1
DILUPBiCGStab: Solving for h, Initial residual = 1, Final residual = 1.21618e-14, No Iterations 1
Min/max T:300 499.841
GAMG: Solving for p_rgh, Initial residual = 1, Final residual = 8.55613e-08, No Iterations 18
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 1.14867e-14, global = -3.53477e-15, cumulative = -3.53477e-15

Solving for solid region thinWall

Alex@AlexPC /cygdrive/c/OpenFOAM/20.09/Alex-dev/run/working/pipeProbefluidMeshRun


The truth is that I am getting desperate. I just adjusted snappy so that wrong faces are not present. However, still there are wrong boundaries assigned to polymesh/boundary files of my regions.

Perhaps, I should finally try explicit featuring now. I cannot think anythink else. Has anyone something else to propose?


Clean files can be downloaded from https://drive.google.com/file/d/1RnU...usp=share_link

[Alczem]

Hey!


I remember struggling with sHM and region definition too. I think the main difference I had with your sHM dictionary is that I used locationsInMesh rather than using cellZoneInside and cellZone for the refinement surfaces. Did you tried that too?


EDIT:


Yep, what I did was:

refinementSurfaces
    {
    
        domain
        {
            level (0 0);
            regions
            {                
                fluid_to_solid1 {level (1 2);}
                 fluid_to_solid2 {level (0 1);}
                walls             {level (0 1); patchInfo {type wall;}}



 
            }
            
            faceZones    (fluid_to_solid1 fluid_to_solid2 );
            //cellZoneInside  inside;
            //insidePoint (0 0 1.5);
            facetype        baffles;

        }
        
     }
    locationsInMesh
    (
    ((0 0 0) fluid)
    ((0 0 0.155000) solid1)
    ((0 0 0.107000) solid2)
    );

[Yann]

Originally Posted by Alczem

Hey!


I remember struggling with sHM and region definition too. I think the main difference I had with your sHM dictionary is that I used locationsInMesh rather than using cellZoneInside and cellZone for the refinement surfaces. Did you tried that too?

If you do not mind I would make a clarification: locationsInMesh is only available in the ESI-OpenCFD branch (openfoam.com).
Since AlexandrosVouros is using the foundation branch (openfoam.org) this won't be an option for him.

Regards,
Yann

[AlexandrosVouros]

The truth is that I haven't try locationInMesh so far. However, I might need to change openfoam version for this one.

Thank you both!

[AlexandrosVouros]

Dear Alczem,

Could you please verify?

1. locationsInMesh will be used for replacing the existing line for "locationInMesh". The latter will be deleted from snappy

2. The whole domain will be included in a single .stl file, correct?

Please note that I have three interfaces, namely: fluid ToProbe, FluidToThinWall and probeToThinWall. Will the faceZones line change accordingly, i.e.

faceZones (fluidToProbe fluidToThinWall probeToThinWall );
faceType baffles;


Last but not least, in which OF version have you run those cases? I am still working with windows 8.1 (, I know it's a very old machine, indeed) so that I cannot install the latest ESI OF version.

Thanks in advance

[Alczem]

Originally Posted by AlexandrosVouros

Dear Alczem,

Could you please verify?

1. locationsInMesh will be used for replacing the existing line for "locationInMesh". The latter will be deleted from snappy

2. The whole domain will be included in a single .stl file, correct?

Please note that I have three interfaces, namely: fluid ToProbe, FluidToThinWall and probeToThinWall. Will the faceZones line change accordingly, i.e.

faceZones (fluidToProbe fluidToThinWall probeToThinWall );
faceType baffles;


Last but not least, in which OF version have you run those cases? I am still working with windows 8.1 (, I know it's a very old machine, indeed) so that I cannot install the latest ESI OF version.

Thanks in advance

1. Yep you should only use one and comment out the other


2. Yep again, it should result in one big mesh with cellzones and facezones. Having more than two interfaces should not change anything if they are properly defined


I ran this case more than a year ago, so probably OF v2012 or 2106 I would say? Windows 8 is not compatible with the precompiled binaries? That's a shame :/ maybe through a virtual machine and linux?


If it is not working, I can only recommend to check the stl files and make sure they are correct (and ideally watertight although sHM will work if it isnt).


Keep us posted!

[AlexandrosVouros]

Hey!


I finally managed to ensure a watertight outlining (only!) geometry!

Baffles are given in separate files.



Multi domain regions are there and baffles work as expected.



A large number of cells and correct meshing -using the same grid parameters for all the exported stl surfaces -was necessary for salome.
The outline surface was checked via surfaceCheck.



Working with implicit sHM, there are still some cells that refer to the wrong mesh region. And also, the name of the boundary is included in the polymesh/boundary folders of both regions...



Questions:

1) I wonder if I could avoid them by changing parameters.

2) Will layers addition solve this problem?

3) Will explicit sHM provide better results or an even more detailed meshing needs to be developed is salome?


4) 'locationInMesh' is necessary although I think that 'locationsInMesh' could work also (it seems minor now)


5) Finally does allowFreeStandingZoneFaces true/false play a role in this problem? I cannot truly understand what it does. If activated, could I have all the faces baffles included -in a single stl file or is this totally wrong?



The link with one (definitely not the best) solution can be found here
https://drive.google.com/file/d/1ho4...usp=share_link


It has no layers and it can be definitely improved.









Many thanks guys!

[Alczem]

Hello!

A large number of cells and correct meshing -using the same grid parameters for all the exported stl surfaces -was necessary for salome.
The outline surface was checked via surfaceCheck.

A better surface mesh with a high resolution is usually helpful to mesh with snappy indeed.

Working with implicit sHM, there are still some cells that refer to the wrong mesh region. And also, the name of the boundary is included in the polymesh/boundary folders of both regions...

It may be due to the featureAngle you are using. The cells shared by both regions are located on the edges of the baffles or are they randomly spread across the surface? If they are on the edges, it is probably due to the featureAngle not being small enough to accurately detect all the features needed. If they seem random, you should try to play with the snapping values so that the cells touching the baffles are not too warped during the snapping stage. Using explicit feature detection could help too!


In your boundary files, do you mean that the exact same name appears twice? Or is it something like fluid_to_solid and solid_to_fluid? Usually, the creation of baffles results in a master patch in one region and a slave patch in the other region.


So to answer in order ^^

1) I wonder if I could avoid them by changing parameters.

Probably with the snapping values.

2) Will layers addition solve this problem?

I would not try to add layers until you are not satisfied with your snapped mesh.

3) Will explicit sHM provide better results or an even more detailed meshing needs to be developed is salome?

Explicit feature detection, in my experience, almost always results in a better mesh especially near the corners. It needs an additional step but it is worth it in my opinion. If you decide to try it, make sure to split your patches around their corners, i.e. if you have a wall forming a sharp edge that you want to properly mesh with good snapping, split this wall by this edge in two "sub-walls" and create one stl file per subwall. I find this approach more robust.

4) 'locationInMesh' is necessary although I think that 'locationsInMesh' could work also (it seems minor now)

locationsInMesh is good if you want the cellzones named directly during the meshing process. Otherwise I agree that it should not make any differences regarding the baffles.

5) Finally does allowFreeStandingZoneFaces true/false play a role in this problem? I cannot truly understand what it does. If activated, could I have all the faces baffles included -in a single stl file or is this totally wrong?

For more control, I would keep each baffle you need in a separate STL file. This setting allows for faces to "float" in your mesh, with no edge attached to the outer boundaries of your mesh. I may be wrong, but imagine that you need to model a fence with a porous jump, the top and side edges of the fence are not touching the outer boundaries (like the ground) so you would need to turn on this setting. Maybe look for other threads just in case because I don't think I ever had to use this.



Can you post a picture of the problematic cells? It might help to identify the issue


EDIT:


Sorry, didnt see the case. After a quick look, I think you might have better results by increasing the tolerance to 1.5 or even 2 in the snapping controls. Your boundaries are properly defined IMO. The mesh looks ok (even though you would need more cells in your thin wall region).

[AlexandrosVouros]

Many thanks fro the reply!

I modified several things but I am never satisfied (Perhaps, this is rather psychological than practical...)

Feature angle was reduced to 1-3, (I would need to apply 180 to featureextract too I think -I need to check) in order to be able to capture the probe_to_fluid_interface. It was very bad actually in the first place so that I increased very much the surface cells from salome and it looks better now.

However, there are still two(!) cells under fluid/Patch/probeWall and many more under probe/partch/fluidWall. An image is provided at the end of the message. In fact, those cells lie on the intersection (or better on the feature edge of the probe. I just found the 'delete small regions' in the v2012 version. Hope it will help.

(Forgot to mention, I am working now in a new ubuntu 22.04.2 LTS OS and 2212 foam version).

Now the most important!

You are right about splitting walls with sharp corners. But could you please check the probe_to_fluid interface? I is in fact a cylinder without its top surface. Could I split the baffle somehow? In all the tutorials I have seen, the baffle is given in a single stl file!

Finally, could you please elaborate on the "floating" settings. In my case, I have checked in salome that there is a common node (I used merge nodes in salome to this end) for the geom outline and the probe_to_fluid baffle. However, as you definitely know, do not maintain when snappying, otherwise I wouldn't have these problems.

Thanks again for the reply. I hope I will come back soon with better results.

[AlexandrosVouros]

The image with the problematic cells.


Wondering also if there is a way to define an edge instead of a surface interface in foam.

[AlexandrosVouros]

Hi!

A decent solution was achieved with explicit snappying. minCellFraction was succesfully applied!

The case can be found under the link below
https://drive.google.com/file/d/1Gzb...usp=share_link

Additional work needs to be done in the intersection. I think that it is rather mandatory to split the baffle in two surfaces so that the teeth are healed rather than trying to fix errors with snappying parameters.

[AlexandrosVouros]

I finally did managed to have a nice -although still with some problematic cells solution. However, since, I think that the topic does not correspond to the real problem I will open a new thread and put the link here.


Thanks again for your help.