[boffin5]

To increase my understanding of working with multiRegion cases, I am trying to do the same parallel case with 2 different ways of meshing.

The first uses topoSet and splitMeshRegions, while the second runs snappyHexMesh twice to create 2 different regions.

These are both for a case with a radiator inside a body, and fed by a duct.

Both runscripts are attached. While the latter (I call it 2 regions) method worked, the topoSet method failed; the runlog showing the failure is also attached.

I tried to write the topoSet method script such that it arrives at an identical polyMesh for fluid and solid, as with the 2 regions method. The first attached image shows a paraView clip for the 2 regions method, and the second image shows a clip for the topoSet method. In the latter, the faces for the solid region have not been created. This might be the reason for the failure, I don't know.

The topoSet method script required more lines because I run decomposePar -allRegions twice, and I copy and save the solid polyMesh so that it won't get overwritten in the second decomposePar step. I tried to used the decomposePar -region regionName option, but couldn't get it to work.

All things being equal, I would prefer to use the topoSet method, as it is more similar to a serial version of the case, that works. The problem lies, I think, with decomposePar. I need to get it to work such that the 2nd time it is executed, it doesn't overwrite the solid polyMesh from the first time. I am hoping for ideas on how to do this. All the same, many thanks to the community people who have been so helpful on my journey thus far!

[Yann]

Hi Alan,

Your workflow is quite hard to understand and seems quite complex for such a simple case.

Why are you running splitMeshRegions?

Lets try to clarify few things:

chtMultiRegionFoam is most of the time used to simulate heat transfer in solids and fluids. Each region has its own mesh and regions are coupled together through their interfaces using mapped walls.

In such cases, each region is defined as a cellZone in snappyHexMeshDict and all regions are meshed at once with snappyHexMesh. The resulting mesh is then splitted using splitMeshRegions to create regions based on the cellZones names. SplitMeshRegions also creates interfaces between each regions as mappedWall using this syntax "mySolidName_to_myFluidName". These interfaces have a type "mappedWall".

Your case is a bit different. You have 2 meshes overlapping : one is your fluid mesh the other one is the radiator mesh. There is no interfaces between the regions since fluid flows through the radiator. The coupling between both regions is achieved thanks to the "constantHeatTransfer" in fvOptions.

Maybe I'm missing something, but I do not think you should be using splitMeshRegions in your case.

Feel free to give more details if you feel like I did not understand the issue!

Yann

[boffin5]

As part of trying to expand my learning with regards to runscripts, my goal here is based on the premise that given a serial run script, it can be adapted to run in parallel.


For my multiregion case, I have a serial version that seems to run okay. It uses splitMeshRegions and topoSet as part of the run script. So I went through it step by step to adapt it for a parallel version. This required some gyrations, since decomposePar overwrites previous polyMeshes that I want to keep. I call the result a 'topoSet runscript'.


But running it is inconsistent. It is okay if I limit it to time step 85, but if I increase it, it fails with this message:

[0] --> FOAM FATAL ERROR: Solving for fluid region solid
DILUPBiCGStab:  Solving for Ux, Initial residual = 0.0252295, Final residual = 0.000260451, No Iterations 1
DILUPBiCGStab:  Solving for Uy, Initial residual = 0.0244245, Final residual = 0.00028387, No Iterations 1
DILUPBiCGStab:  Solving for Uz, Initial residual = 0.0263954, Final residual = 0.000277525, No Iterations 1
DILUPBiCGStab:  Solving for h, Initial residual = 0.794511, Final residual = 0.0264979, No Iterations 8
[1] [0] 


[0] Negative initial temperature T0: -296.14
[1] 
[1] --> FOAM FATAL ERROR: 
[1] [0] Negative initial temperature T0: -113.569
[1] 
[1]     From function Foam::scalar Foam::species::thermo<Thermo, Type>::T

I'm not sure what to do with this.


Also, I have a parallel case more along the lines of what you describe; I call it a '2regions runscript'. But it is also inconsistent. It runs okay with a flow velocity of 60, but if I increase it to 90, it fails with this message:

Solving for fluid region fluid
DILUPBiCGStab:  Solving for Ux, Initial residual = 0.051815, Final residual = 0.00292461, No Iterations 1
DILUPBiCGStab:  Solving for Uy, Initial residual = 0.210492, Final residual = 0.00696092, No Iterations 1
DILUPBiCGStab:  Solving for Uz, Initial residual = 0.0892766, Final residual = 0.00307162, No Iterations 1
DILUPBiCGStab:  Solving for h, Initial residual = 0.983714, Final residual = 0.0733501, No Iterations 5
          [1] iter          Test           e/h          Cv/p          Tnew
          [1] 0       551.837        758415       1049.15       173.272
          [1] 1       173.272       36964.9       994.498       499.345
          [1] 2       499.345        660402       1039.87       211.656
          [1] 3       211.656        102961       1000.63       469.778
          [1] 4       469.778        603858       1035.12       235.396
          [1] 5       235.396        145593       1004.04        450.18

         [1] 94       349.315        365180       1018.59        345.45
          [1] 95        345.45        357468       1018.11       349.159
          [1] 96       349.159        364870       1018.57         345.6
          [1] 97         345.6        357766       1018.13       349.016
          [1] 98       349.016        364583       1018.55       345.737
          [1] 99       345.737        358041       1018.14       348.883
          [1] 100       348.883        364319       1018.54       345.864
          [1] 101       345.864        358294       1018.16       348.762
[1] 
[1] 
[1] --> FOAM FATAL ERROR: 
[1] Maximum number of iterations exceeded: 100
[1] 
[1]     From function Foam::scalar Foam::species::thermo<Thermo, Type>::T(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar) const, bool) const [with Thermo = Foam::hPolynomialThermo<Foam::icoPolynomial<Foam::specie> >; Type = Foam::sensibleEnthalpy; Foam::scalar = double; Foam::species::thermo<Thermo, Type> = Foam::species::thermo<Foam::hPolynomialThermo<Foam::icoPolynomial<Foam::specie> >, Foam::sensibleEnthalpy>]
[1]     in file /home/ubuntu/OpenFOAM/OpenFOAM-8/src/thermophysicalModels/sp

This is all frustrating, because the boundary conditions for all these cases are the same. I'm just trying to find a method for chtMultiRegion cases that gives the most consistent results.

Your method is the best, I'm sure, but now I have to understand why my boundary conditions lead to the 'maximum number of iterations' problem.

Thanks again for your help!

[Yann]

Hi Alan,

Could you please share your cases for both methods so I can have a look at it?

Thanks,
Yann

[boffin5]

Yann,
Thank you again! Here are zip files for all 3 cases: serial, topoSet version, and the 2 regions version. I truly appreciate your help.
Alan w

[Yann]

Hi Alan,

Your cases are a bit messy:

In your serial case, the topoSet is useless:

1. First you run splitMeshRegions, which splits the mesh located in constant/polyMesh to new regions: constant/fluid/polyMesh and constant/solid/polyMesh.
2. Then you run topoSet without any options: it means topoSet creates the cellZone in constant/polyMesh
3. foamToVTK allows you to visualize the cellZone created in constant/polyMesh
4. Then your delete constant/polyMesh and proceed to re-run blockMesh and snappyHexMesh to mesh your fluid region.

This means steps 2 and 3 are useless. Moreover, the "porousCells" cellZone you create with topoSet is not used anywhere in the simulation. I am not sure why you are doing those steps, you can remove it from your workflow it will not have any effect on your simulation. (see the attached case radiator-serial_Yann.zip)

Now about your parallel-topoSet case :

1. first thing is, you are not using the same snappyHexMeshDict files in the serial and parallel cases. When I run the case with the runp script, both fluid and solid mesh are wrong (for instance, there is no body in the mesh in the fluid region).
2. As stated for the serial case, topoSet is useless and can be removed.
3. There is a lot of unnecessary operations: running surfaceFeatures twice is useless, running blockMesh twice is useless, and many of your for loops to copy/delete meshes can be avoided. This might not be a problem as long as you work with small cases, but this can become a huge time loss when it comes to bigger cases.

I modified your runp script to make it a bit simpler (see radiator-parallel_Yann.zip). This case produces the same results as the serial one.

And finally your last case (so-called 2 regions version): the runp script by itself runs fine (as for the previous cases, running surfaceFeatures twice is useless). Your problem is related to the mesh: the solid region is not as refined in this case as it is in the other cases. Using the same refinement box as in the other cases solves the problem and the case produces again the same results as the previous ones.

Let me know if something is not clear!
Cheers,

Yann

[boffin5]

It has been said that if you put a chimpanzee and a typewriter in a box, and wait long enough, you will end up with a copy of Tolstoy's War and Peace. That's kind of how it's been for me with OpenFOAM, trying to learn a complex application with very little guidance. But thanks to help from you and others, I have been able to go much faster than the chimp, and finally have arrived at the point, I hope, where I can put the code to productive use. Thank You Yann, Bloerb and everyone else who has come to my aid!



Alan w

[boffin5]

Thanks to help that I received from Yann regarding my chtMultiRegion template, I am now trying to apply it to my Meredith Effect problem. This one has an airplane fuselage and a heat exchanger.


The duct loft is somewhat complex, and I had to extract a lot of curves for use in refining a mesh that looked visually acceptable. But when I try to run the case, I get this error message:

/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  8
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
Build  : 8-1c9b5879390b
Exec   : chtMultiRegionFoam -parallel
Date   : Apr 20 2022
Time   : 11:01:19
Host   : "boffin5-VirtualBox"
PID    : 10218
I/O    : uncollated
Case   : /home/boffin5/cfdaero/meredith-yann
nProcs : 2
Slaves : 1("boffin5-VirtualBox.10219")
Pstream initialized with:
    floatTransfer      : 0
    nProcsSimpleSum    : 0
    commsType          : nonBlocking
    polling iterations : 0
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 fluid mesh for region fluid for time = 0

Create fluid mesh for region solid for time = 0

*** Reading fluid mesh thermophysical properties for region fluid

    Adding to thermoFluid

Selecting thermodynamics package 
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       polynomial;
    thermo          hPolynomial;
    equationOfState icoPolynomial;
    specie          specie;
    energy          sensibleEnthalpy;
}

    Adding to rhoFluid

    Adding to UFluid

    Adding to phiFluid

    Adding to gFluid

    Adding to hRefFluid

    Adding to pRefFluid

    Adding to ghFluid

    Adding to ghfFluid

    Adding to turbulenceFluid

Selecting turbulence model type RAS
Selecting RAS turbulence model kEpsilon
RAS
{
    RASModel        kEpsilon;
    turbulence      on;
    printCoeffs     on;
    Cmu             0.09;
    C1              1.44;
    C2              1.92;
    C3              0;
    sigmak          1;
    sigmaEps        1.3;
}

    Adding to thermophysicalTransport

Selecting thermophysical transport type RAS
Selecting default RAS thermophysical transport model eddyDiffusivity
    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

Creating finite volume options from "constant/fvOptions"

Selecting finite volume options model type constantHeatTransfer
    Source: fluidTosolid
Selecting finite volume options model type interRegionExplicitPorositySource
    Source: porosityBlockage
- selecting inter region mapping
Creating mesh-to-mesh addressing for fluid and solid regions using cellVolumeWeight
    Overlap volume: 574.311
*** Reading fluid mesh thermophysical properties for region solid

    Adding to thermoFluid

Selecting thermodynamics package 
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       polynomial;
    thermo          hPolynomial;
    equationOfState icoPolynomial;
    specie          specie;
    energy          sensibleEnthalpy;
}

    Adding to rhoFluid

    Adding to UFluid

    Adding to phiFluid

    Adding to gFluid

    Adding to hRefFluid

    Adding to pRefFluid

    Adding to ghFluid

    Adding to ghfFluid

    Adding to turbulenceFluid

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

Selecting thermophysical transport type laminar
Selecting default laminar thermophysical transport model Fourier
    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

Creating finite volume options from "constant/fvOptions"

Selecting finite volume options model type constantHeatTransfer
    Source: solidTofluid
- selecting inter region mapping
Creating mesh-to-mesh addressing for solid and fluid regions using cellVolumeWeight
[0] 
[0] 
[0] --> FOAM FATAL ERROR: 
[0] Plane normal defined with zero length
Bad points:(1.34992 -0.149985 0.100174) (1.34992 -0.149985 0.112788) (1.34992 -0.149985 0.106484)
[0] 
[0]     From function void Foam::plane::calcPntAndVec(const point&, const point&, const point&)
[0]     in file meshes/primitiveShapes/plane/plane.C at line 85.
[0] 
FOAM parallel run aborting
[0] 
[0] #0  Foam::error::printStack(Foam::Ostream&) at ??:?
[0] #1  Foam::error::abort() at ??:?
[0] #2  Foam::plane::calcPntAndVec(Foam::Vector<double> const&, Foam::Vector<double> const&, Foam::Vector<double> const&) at ??:?
[0] #3  Foam::tetOverlapVolume::tetTetOverlapVol(Foam::tetrahedron<Foam::Vector<double>, Foam::Vector<double> const&> const&, Foam::tetrahedron<Foam::Vector<double>, Foam::Vector<double> const&> const&) const at ??:?

What does 'plane normal defined with zero length' mean? Is it because my mesh is too fine, or not fine enough? Or something else? I'm not sure how to deal with this error. Attached are the checkMesh logs for the fluid and solid regions. Also an image of the problem I'm dealing with. Hoping again (I know, it's been a lot of times) for help. If other files are needed for debugging, I can certainly supply them.

[boffin5]

In this case, with a radiator mesh overlapping the fluid mesh, would using the function 'mapFields' be of use?

[boffin5]

Hi Yann,

You were very helpful to me before, by providing repaired zip files for the serial and parallel versions of a sample chtMultiRegion case that I was working on.

Currently I'm working on a similar case with more complex geometry, so I revisited the files that you provided. The serial case works fine, but the parallel one now has a problem. It seems to run properly, but fails with the reconstructParMesh step. ParaView doesn't show any flow properties, i.e. p, U.

So I added an "exit" just before that line, and ran the case with the run script. Then, I manually entered "reconstructParMesh -constant -latestTime -allRegions ", and this error message appeared:

Create time

This is an experimental tool which tries to merge individual processor
meshes back into one master mesh. Use it if the original master mesh has
been deleted or if the processor meshes have been modified (topology change).
This tool will write the resulting mesh to a new time step and construct
xxxxProcAddressing files in the processor meshes so reconstructPar can be
used to regenerate the fields on the master mesh.

Not well tested & use at your own risk!

Operating on regions fluid and solid

Merge tolerance : 1e-07
Write tolerance : 1e-06


--> FOAM FATAL ERROR: 
Your current settings specify ASCII writing with 6 digits precision.
Your merging tolerance (1e-07) is finer than this.
Please change your writeFormat to binary or increase the writePrecision
or adjust the merge tolerance (-mergeTol).

    From function int main(int, char**)
    in file reconstructParMesh.C at line 529.

FOAM exiting

I'm not sure what happened, as I didn't change anything. As before, I am running OpenFoam 8. Attached below is the run script.

I'll have more questions, but this one is hanging me up at the present time.

Hoping you have time to help:

Alan w

[Yann]

Hello Alan,

Check out the mergeTolerance parameter at the end of snappyHexMeshDict. I guess it must be set to 1e-7, while the writePrecision in controlDict must be set to 1e-6.
You can increase the writePrecision to 1e-7 it should solve the problem.

However I'm surprised you didn't get an error earlier in the workflow, I thought you couldn't even mesh with snappy if the writePrecision is higher than mergeTolerance.

Cheers,
Yann

[boffin5]

Thanks Yann,

In your post of 16 April of last year, you provided a zip file which fixed my chtMultiRegion case problems. After revisiting this case and working with it, I have issues, and recently you suggested why it is failing. Here is the error message. You said that the merge and write tolerances should be the same, specifically in controlDict and snappyHexMeshDict.

Merge tolerance : 1e-07
Write tolerance : 1e-06
--> FOAM FATAL ERROR: 
Your current settings specify ASCII writing with 6 digits precision.
Your merging tolerance (1e-07) is finer than this.

But, in snappyHexMeshDict.1 and .2 (one for each region), at the bottom I have:

mergeTolerance 1e-06;

And, in controlDict, I have :

writePrecision 6;

So these settings should be okay, and do not correspond to the error message. I can't find the string '1e-07' anywhere in the case folder.

So then, I went back to your post where you attached the zip files, and re-downloaded the parallel case, just in case I had inadvertantly altered my original copy. But the same error appears. Further, in the log output for reconstructPar -constant -latestTime -allRegions it says:

Exec   : reconstructPar -constant -latestTime -allRegions
Date   : Mar 24 2023
Time   : 11:01:55
Host   : "localhost.localdomain"
PID    : 22852
I/O    : uncollated
Case   : /home/boffin5/cfdaero/radiator-parallel-yann.old
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



Reconstructing fields for mesh fluid

Time = constant

Reconstructing FV fields



--> FOAM FATAL ERROR: 
Size of maps does not correspond to size of mesh for processor 0
faceProcAddressing : 40080 nFaces : 107827
cellProcAddressing : 12800 nCell : 32060
boundaryProcAddressing : 7 nFaces : 8

    From function Foam::fvFieldReconstructor::fvFieldReconstructor(Foam::fvMesh&, const Foam::PtrList<Foam::fvMesh>&, const Foam::PtrList<Foam::IOList<int> >&, const Foam::PtrList<Foam::IOList<int> >&, const Foam::PtrList<Foam::IOList<int> >&)
    in file fvFieldReconstructor.C at line 56.

FOAM exiting

I don't know what to make of this error. This is all quite frustrating, since this exact case ran fine a few months ago, or so I thought. Maybe I should have my head examined.

[piu58]

I don't recommend setting the merge tolerance and the write tolerance to the same value. This causes errors. I recommend the merge tolerance at least 10x larger, that means 1e-5 in your case.

The error output may come from some rounding effects.

[boffin5]

Thank you, Herr Pilz! Per your suggestion, I changed the merge tolerance in both of the snappyHexMeshDict files to 1e-05. Again, note that this is for the parallel case zip file given by Yann earlier in this thread.

Unfortunately, it made no difference to the output. In fact, the log message for reconstructParMesh still shows the same information:

Merge tolerance : 1e-07
Write tolerance : 1e-06

This, despite neither of those values appearing anywhere in the case files.

That said, the simullation seems to run, as it cranks through the time steps; obviously data is being generated. But, it fails to reconstruct the mesh, so no data can be seen in paraView.

Hoping for help; I need this template!

----------------------------------------------------------------

Alles hat ein Ende, nur die Wurst hat zwei

[piu58]

I don't know why, but the merge tolerance does not seem to be changed. May you increase write tolerance at 1e-8 instead?

It is a good idea using binary as write format. It is more precise.

[Yann]

Hello guys,

I just thought about something. The error seems to be related to reconstructParMesh and reconstructParMesh -help says:

[...]
 -mergeTol <scalar>
                    specify the merge distance relative to the bounding box size
                    (default 1e-7)
[...]

At least this is what I get with OpenFOAM-8. Alan, are you still using this version?
Try to update your reconstructParMesh command and tell us if it solves the issue:

reconstructParMesh -mergeTol 1e-5

Yann

[boffin5]

Your suggestion to change the mergeTol worked! So now I have a working template, until I apply it and run into the next glitch/hangup/roadblock. But they occur less frequently, as I continue working with this stuff.