[obiscolly50]

Hello,
I've been trying to do a simulation in chtMultiRegionFoam and i'm experiencing some problem which i cant understand why its happening. The simulation runs but for some weird reasons, it solves for all other field asides from the velocity. What is the reason for this? It's totally strange as i don't get any error messages . Below is a code excerpt from the run

/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  6
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
Build  : 6-1a0c91b3baa8
Exec   : chtMultiRegionFoam
Date   : Oct 30 2018
Time   : 03:36:28
Host   : "Obi"
PID    : 6268
I/O    : uncollated
Case   : /home/obi/OpenFOAM/obi-6/run/heatedShell/case
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 fluid mesh for region air for time = 0

Create solid mesh for region copper for time = 0

*** Reading fluid mesh thermophysical properties for region air

    Adding to thermoFluid

Selecting thermodynamics package
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState perfectGas;
    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

Selecting radiationModel none
    Adding to KFluid

    Adding to dpdtFluid

    Adding to fieldsFluid

    Adding to QdotFluid

    Adding MRF

No MRF models present

    Adding fvOptions

*** Reading solid mesh thermophysical properties for region copper

    Adding to thermos

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

    Adding to radiations

Selecting radiationModel none
    Adding fvOptions


PIMPLE: Region air
PIMPLE: No convergence criteria found


PIMPLE: Region copper
PIMPLE: No convergence criteria found


PIMPLE: Operating solver in PISO mode

Region: air Courant Number mean: 0.1039141 max: 0.6005547
Region: copper Diffusion Number mean: 0.06942615 max: 52.37995
deltaT = 0.0001666667
Region: air Courant Number mean: 0.01731902 max: 0.1000924
Region: copper Diffusion Number mean: 0.01157103 max: 8.729991
deltaT = 0.0001666667
Time = 0.000166667


Solving for fluid region air
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab:  Solving for h, Initial residual = 1, Final residual = 5.120642e-09, No Iterations 2
Min/max T:295.943 400
GAMG:  Solving for p_rgh, Initial residual = 0.9999859, Final residual = 0.004941267, No Iterations 3
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0.01802565, global = 0.0002057503, cumulative = 0.0002057503
Min/max rho:-11.58785 9.216414
GAMG:  Solving for p_rgh, Initial residual = 0.05691773, Final residual = 7.67363e-08, No Iterations 16
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 5.597979e-07, global = -1.020733e-08, cumulative = 0.0002057401
Min/max rho:0.8689607 1.506732

Solving for solid region copper
DICPCG:  Solving for h, Initial residual = 1, Final residual = 9.8895e-07, No Iterations 2
Min/max T:290.7127 332.6187
ExecutionTime = 4.52 s  ClockTime = 19 s

Region: air Courant Number mean: 2.546197 max: 8923.591
Region: copper Diffusion Number mean: 0.01157103 max: 8.729991
deltaT = 1.867707e-08
Time = 0.000166685


Solving for fluid region air
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab:  Solving for h, Initial residual = 0.0007881029, Final residual = 6.475526e-09, No Iterations 1
Min/max T:290.7155 400
GAMG:  Solving for p_rgh, Initial residual = 0.01570502, Final residual = 2.354311e-13, No Iterations 1
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 1.28292e-10, global = -2.830048e-12, cumulative = -2.830048e-12
Min/max rho:0.8695844 1.547143
GAMG:  Solving for p_rgh, Initial residual = 0.001365404, Final residual = 3.268448e-14, No Iterations 1
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 9.170082e-12, global = -5.047294e-15, cumulative = -2.835095e-12
Min/max rho:0.8695845 1.50835

Solving for solid region copper
DICPCG:  Solving for h, Initial residual = 5.203124e-05, Final residual = 7.670816e-16, No Iterations 1
Min/max T:290.7117 332.6234
ExecutionTime = 5.06 s  ClockTime = 20 s

Region: air Courant Number mean: 0.0002648757 max: 0.4671027
Region: copper Diffusion Number mean: 1.296677e-06 max: 0.0009783038
deltaT = 2.241238e-08
Time = 0.000166708

[kera]

Hallo,

The only thing I can think of right now is switching on the momentumPredictor in system/air/fvSolution

PIMPLE
{
    momentumPredictor   on;
    nCorrectors         2;
    nNonOrthogonalCorrectors 0;
}

Hope this helps!

Regards,
Ricky

Originally Posted by obiscolly50

Hello,
I've been trying to do a simulation in chtMultiRegionFoam and i'm experiencing some problem which i cant understand why its happening. The simulation runs but for some weird reasons, it solves for all other field asides from the velocity. What is the reason for this? It's totally strange as i don't get any error messages . Below is a code excerpt from the run

/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     | Website:  https://openfoam.org
    \\  /    A nd           | Version:  6
     \\/     M anipulation  |
\*---------------------------------------------------------------------------*/
Build  : 6-1a0c91b3baa8
Exec   : chtMultiRegionFoam
Date   : Oct 30 2018
Time   : 03:36:28
Host   : "Obi"
PID    : 6268
I/O    : uncollated
Case   : /home/obi/OpenFOAM/obi-6/run/heatedShell/case
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 fluid mesh for region air for time = 0

Create solid mesh for region copper for time = 0

*** Reading fluid mesh thermophysical properties for region air

    Adding to thermoFluid

Selecting thermodynamics package
{
    type            heRhoThermo;
    mixture         pureMixture;
    transport       const;
    thermo          hConst;
    equationOfState perfectGas;
    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

Selecting radiationModel none
    Adding to KFluid

    Adding to dpdtFluid

    Adding to fieldsFluid

    Adding to QdotFluid

    Adding MRF

No MRF models present

    Adding fvOptions

*** Reading solid mesh thermophysical properties for region copper

    Adding to thermos

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

    Adding to radiations

Selecting radiationModel none
    Adding fvOptions


PIMPLE: Region air
PIMPLE: No convergence criteria found


PIMPLE: Region copper
PIMPLE: No convergence criteria found


PIMPLE: Operating solver in PISO mode

Region: air Courant Number mean: 0.1039141 max: 0.6005547
Region: copper Diffusion Number mean: 0.06942615 max: 52.37995
deltaT = 0.0001666667
Region: air Courant Number mean: 0.01731902 max: 0.1000924
Region: copper Diffusion Number mean: 0.01157103 max: 8.729991
deltaT = 0.0001666667
Time = 0.000166667


Solving for fluid region air
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab:  Solving for h, Initial residual = 1, Final residual = 5.120642e-09, No Iterations 2
Min/max T:295.943 400
GAMG:  Solving for p_rgh, Initial residual = 0.9999859, Final residual = 0.004941267, No Iterations 3
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 0.01802565, global = 0.0002057503, cumulative = 0.0002057503
Min/max rho:-11.58785 9.216414
GAMG:  Solving for p_rgh, Initial residual = 0.05691773, Final residual = 7.67363e-08, No Iterations 16
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 5.597979e-07, global = -1.020733e-08, cumulative = 0.0002057401
Min/max rho:0.8689607 1.506732

Solving for solid region copper
DICPCG:  Solving for h, Initial residual = 1, Final residual = 9.8895e-07, No Iterations 2
Min/max T:290.7127 332.6187
ExecutionTime = 4.52 s  ClockTime = 19 s

Region: air Courant Number mean: 2.546197 max: 8923.591
Region: copper Diffusion Number mean: 0.01157103 max: 8.729991
deltaT = 1.867707e-08
Time = 0.000166685


Solving for fluid region air
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab:  Solving for h, Initial residual = 0.0007881029, Final residual = 6.475526e-09, No Iterations 1
Min/max T:290.7155 400
GAMG:  Solving for p_rgh, Initial residual = 0.01570502, Final residual = 2.354311e-13, No Iterations 1
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 1.28292e-10, global = -2.830048e-12, cumulative = -2.830048e-12
Min/max rho:0.8695844 1.547143
GAMG:  Solving for p_rgh, Initial residual = 0.001365404, Final residual = 3.268448e-14, No Iterations 1
diagonal:  Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors : sum local = 9.170082e-12, global = -5.047294e-15, cumulative = -2.835095e-12
Min/max rho:0.8695845 1.50835

Solving for solid region copper
DICPCG:  Solving for h, Initial residual = 5.203124e-05, Final residual = 7.670816e-16, No Iterations 1
Min/max T:290.7117 332.6234
ExecutionTime = 5.06 s  ClockTime = 20 s

Region: air Courant Number mean: 0.0002648757 max: 0.4671027
Region: copper Diffusion Number mean: 1.296677e-06 max: 0.0009783038
deltaT = 2.241238e-08
Time = 0.000166708

[obiscolly50]

Originally Posted by kera

Hallo,

The only thing I can think of right now is switching on the momentumPredictor in system/air/fvSolution

PIMPLE
{
    momentumPredictor   on;
    nCorrectors         2;
    nNonOrthogonalCorrectors 0;
}

Hope this helps!

Regards,
Ricky

Hi Ricky,
The momentum predictor on my fvSolution file was already on. Seems that's not the problem here. Please have a look at my case file and see if you could spot something wrong.

https://www.dropbox.com/s/xs660es6v7...hell2.zip?dl=0

Thanks very much.

[peterhess]

Hi,

The log file for subsetMesh have an error! (I tested with OF6.0).

The splitMeshRegions split the mesh into 77 regions...

You need to fix the problem in the meshing first.

I am woundering how the simulation runs by you.

OF version?

You are simulating transient. Is that right?

Setting

maxCo 10000;

is not a good idea.

Better to reduce to 1, supposing you simulate transient...


Regards

Peter

[obiscolly50]

Originally Posted by peterhess

Hi,

The log file for subsetMesh have an error! (I tested with OF6.0).

The splitMeshRegions split the mesh into 77 regions...

You need to fix the problem in the meshing first.

I am woundering how the simulation runs by you.

OF version?

You are simulating transient. Is that right?

Setting

maxCo 10000;

is not a good idea.

Better to reduce to 1, supposing you simulate transient...


Regards

Peter

Hi Peter,
Thanks for checking up on my case. Sorry it was my bad! I have fixed the case to have only 2 regions now. 77 regions were created because subsetMesh failed due to not removing some old cellToRegion files using my AllClean script. Also, i'm actually using a maxCo of 1. I've been trying different settings to see the cause of the problems, that's why it was at 1000, but i've changed it back. Please have a look at let me know your thoughts.

Here is the new link:
https://www.dropbox.com/s/xs660es6v7...hell2.zip?dl=0

Thank you very much.

[pete20r2]

I can't open the zip on my phone so I'll just guess, you don't have frozenFlow on do you?
If that's not it, go have a look at the source for chtMultiRegionFoam and find any "if" statements or other conditionals that might cause a skip of the U solution.

[obiscolly50]

Originally Posted by pete20r2

I can't open the zip on my phone so I'll just guess, you don't have frozenFlow on do you?
If that's not it, go have a look at the source for chtMultiRegionFoam and find any "if" statements or other conditionals that might cause a skip of the U solution.

I actually took a look at the chtMultiRegionFoam code last night and observed that specifying a frozenFlow would cause solving the velocity field to be skipped. But nowhere in the fvSolution did i specify that frozenFlow should be on. Unless this is implicitly implied by one of my boundary conditions which i'm not sure. Here is a link to the unzipped file if you want to view the case on-the-go: https://www.dropbox.com/sh/fhemlyce3...nEoj7e_Fa?dl=0

Thank you!

[peterhess]

Hello!

I rebulit the mesh you have in your case using salome and used the setups you have in your case.

Your mesh has different problems, as checkMesh has told me.


All The boundary condithins, themophysical proberties... has been imported from your case.

I just changed the mesh and the velocity at the outlet from zeroGradient to inletOutlet.

The simulation works.

That means that your setups are working.


The problems you are facing is by using the:

- snappyHexMesh -overwrite

If you look to the log file of snappy, you will notice that the maximum number of cells need to be increased in snappy from 200000 to a higher value!

That need to be done, but does not solve the problem!

- setSet -batch batch.setSet

and

- subsetMesh -overwrite isolation

I have no idea what you want to do with those two.


Anyway you are isolating the sourrounding boundaries and take them out of the simulation. And that includes the inlet and the outlet.


Would you please descibe the target of using those two utalities. ie what you want to do?


Anyway, here is the case meshed with salome.

https://drive.google.com/file/d/1OhW...ew?usp=sharing

Do you want to simulate transient or steady state?

Regards

Peter

PS: The gravity should be in Z direction!

[obiscolly50]

Thanks a lot Peter for the time you spent looking into my case. I've learnt several things from your last reply that should hopefully help me in future cases. Regarding your question below:

- setSet -batch batch.setSet

and

- subsetMesh -overwrite isolation

I have no idea what you want to do with those two.


Anyway you are isolating the sourrounding boundaries and take them out of the simulation. And that includes the inlet and the outlet.


Would you please descibe the target of using those two utalities. ie what you want to do?

I basically learnt that method from an old post by wyldckat for removing the background mesh. Here is the link https://www.cfd-online.com/Forums/op...tml#post341623.

From my understanding (maybe i'm wrong), the background mesh is not totally removed after using blockMesh. I experienced this and that was the reason it created 77 regions as you pointed out previously.

So, it would seem from the post, setSet was used to create a cellZone isolation which includes the needed zone (air and copper) and the subSetMesh command is used to tell OpenFOAM to create a new mesh from the 'isolation' and overwrite existing mesh. This has been my philosophy for the past couple of weeks i started learning chtMultiRegion.

Anyway you are isolating the sourrounding boundaries and take them out of the simulation. And that includes the inlet and the outlet.

I would agree with you this makes sense. However, this was my only way of not coming up with multiple unneeded regions; sometimes running into hundreds. If you have any way of avoiding this without subsetting the mesh please let me know. My objective is to run the whole simulation, including making the mesh using snappy in OpenFOAM. Based on what you pointed out, one possible solution which i've not tried but i think might work is creating the patches after snappyHexMesh and subsetMesh using topoSet and createPatch. Maybe then, the interior domain can absorb the boundary condition instead of it being isolated.

Anyway, here is the case meshed with salome.

https://drive.google.com/file/d/1OhW...ew?usp=sharing

Thanks a lot for this and the included python script. Your simulation meshing with Salome indeed runs. This problem i'm simulating is meant to be a simplification of a much complex problem i plan to run i future. I thought it would be easier to mesh using snappy, but i'm beginning to reconsider. Would you have a recommended method of multiregion meshing using snappyHex? Also, i'm trying to open the Salome study file to see your meshing process, but for some weird reason, the file opens but nothing shows up. I've tried on salome 7 and 8.

Are you want to simulate transient or steady state?

I'm trying to simulate transient, but the simulation timestep is painfully slow using a maxCo of 1. I wonder how that could be increased without using much larger cells. Anyway, it is my understanding that chtMultiRegion doubles as as both a steady state and transient solver. To change to steady, i just need to switch the ddtScheme to 'steadyState' and change PIMPLE to SIMPLE in fvSolution? Please correct me if i'm wrong.

PS: The gravity should be in Z direction!

I actually meant to simulate a horizontal pipe with fluid flowing in the z direction, and i think the gravity is pointed correctly in the y direction.

Once again, thanks for your great work Peter!

[peterhess]

I'm trying to simulate transient, but the simulation timestep is painfully slow using a maxCo of 1. I wonder how that could be increased without using much larger cells. Anyway, it is my understanding that chtMultiRegion doubles as as both a steady state and transient solver. To change to steady, i just need to switch the ddtScheme to 'steadyState' and change PIMPLE to SIMPLE in fvSolution? Please correct me if i'm wrong.

Yes you are right! ddt --> steady state

and

using the fvSchemes and fvSolution from:

/heatTransfer/chtMultiRegionFoam/multiRegionHeaterRadiation/

for solid and fluid regions respectvly

Those setups are working...

---------

The transient simulatiuon is running very slow. You are right!

The reason for this is the very high density of the solid region (copper) in your case!

rho =8000 means that the solid will take too much time to increase its temperature because the momentum is very high.

By the way, if the transient part of the simulation is not necessery, then the "transient" simulation calculation time could be increased by reducing the density of the solid to 1!

AND increase the maxCo.

Anyway a devergence could happend...

After the convergence happends you can increase the density one more time to get the final results.

Like that you dont need to change the ddt sheme and fvSchemes and fvSolution!

This suggestion is not official, but a small trick if you want to use the transient setups for a steady state calculation...

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

OK, if the gravity is right, then I was worng

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

The problem with your mesh is that you have a very coarse stl mesh. (I am not sure here).

Snappy setups need to be tuned to get a good mesh.

After snappy and before making the next steps, just run checkMesh. You will notice that the mesh quality is bad and checkMesh failed.

I increased the blockMesh resolution and the 2000000 cells in snappy to 20000000. but I was not succesful...

That why I made the mesh with salome, caus I like it more.

At the ende of snappy you get a massage:

Finished meshing with 76 illegal faces (concave, zero area or negative cell pyramid volume)!

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

The geometry is by the way very simple and you are able to make the mesh with blockMesh and topoSet, without using snappy

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

I am working now on the case using snappy.

I will post it later

[obiscolly50]

The transient simulatiuon is running very slow. You are right!

The reason for this is the very high density of the solid region (copper) in your case!

rho =8000 means that the solid will take too much time to increase its temperature because the momentum is very high.

By the way, if the transient part of the simulation is not necessery, then the "transient" simulation calculation time could be increased by reducing the density of the solid to 1!

AND increase the maxCo.

Anyway a devergence could happend...

After the convergence happends you can increase the density one more time to get the final results.

Like that you dont need to change the ddt sheme and fvSchemes and fvSolution!

This suggestion is not official, but a small trick if you want to use the transient setups for a steady state calculation...

Nice trick I should try that out when i'm switching to steady state.

The problem with your mesh is that you have a very coarse stl mesh. (I am not sure here).

Snappy setups need to be tuned to get a good mesh.

After snappy and before making the next steps, just run checkMesh. You will notice that the mesh quality is bad and checkMesh failed.

I increased the blockMesh resolution and the 200000 cells in snappy to 20000000. but I was not succesful...

That why I made the mesh with salome, caus I like it more.

At the ende of snappy you get a massage:

Finished meshing with 76 illegal faces (concave, zero area or negative cell pyramid volume)!

Yes you are right, the mesh ends with 76 mostly non-orthogonal (>65 degrees), but i didn't think this would be a big problem. I thought in the worst case, it would affect the quality of the result or crash the simulation, but the simulation ran but without calculating the velocities. Coming from using ANSYS fluent where meshing was way easier, i'm trying so hard to like snappy but it's been proving so difficult for me, especially for multiregion meshing

The geometry is by the way very simple and you are able to make the mesh with blockMesh and topoSet, without using snappy

Yeah i know this. But the purpose was to practice for a much bigger simulation that couldn't be simplified using blockMesh and topoSet.

I am working now on the case using snappy.

I will post it later

Thanks a lot. I'm looking forward seeing to what you come up with

[peterhess]

I got it

The problem was in the stl files you use.

I just replaced yours with others that I generated myself.

Deleted the:

setSet -batch batch.setSet

subsetMesh -overwrite isolation

I did not change anything else.

See attached file.

And have fun

https://drive.google.com/file/d/1POc...ew?usp=sharing

regards

Peter

[obiscolly50]

Originally Posted by peterhess

I got it

The problem was in the stl files you use.

I just replaced yours with others that I generated myself.

Deleted the:

setSet -batch batch.setSet

subsetMesh -overwrite isolation

I did not change anything else.

See attached file.

And have fun

https://drive.google.com/file/d/1POc...ew?usp=sharing

regards

Peter

Wow! Amazing!

I never knew that would be an issue as far as both surfaces are closed. I particularly checked using surfaceCheck to be sure. Please tell me how you generated the stl that might be different from what i did previously?

Thank you very much,
Obi

[peterhess]

Well, I used Salome before to generate the mesh.

From the geometry that I generated there based on your geometry I generated the STL files.

By the way, the quality of my STLs is lower than yours!

I increased the quality and got the same problem...

If you compare the size of my files with yours, then you will see that my files are smaller.

----------

You could increase the maxDi from 10 to about 20.

That will let the simulation run faster.

Regards

Peter

PS: Use salome! it is amazing

[obiscolly50]

Originally Posted by peterhess

Well, I used Salome before to generate the mesh.

From the geometry that I generated there based on your geometry I generated the STL files.

By the way, the quality of my STLs is lower than yours!

I increased the quality and got the same problem...

If you compare the size of my files with yours, then you will see that my files are smaller.

----------

You could increase the maxDi from 10 to about 20.

That will let the simulation run faster.

Regards

Peter

PS: Use salome! it is amazing

That's the funny thing. I actually used Salome that's why i'm wondering where i went wrong. I created my geometry in solidworks, exported the STEP file to Salome and generated the STLs from the software to ensure they were water tight.

I thought a higher size STL means better quality? It's confusing how a lower quality should work and a higher one fails. Is there any possible reasoning behind that? Also are you generating the STL's from the mesh or geometry module? I need to be clear. If from the mesh module, what rule of thumb do you use for the meshing? same size?

[peterhess]

I have no idea.

I descovered that by sudden, as I exported the STL from salome with very high quality.

The result was that I got more stand alone zones using spliteMesh.

Anyway, I increased before the mesh quality in snappy in the lines: 138 and 148. And the stand alone zones increased. I reduced the quality and I got less stand alone zones.

That was the key to look for STL quality and to generate them myself.

I decreased the quality to have fun seeing the result and that solved the problem

Anyway, I learned today something new

The STLs has been generated from the geometry.

Regards

Peter

[obiscolly50]

Originally Posted by peterhess

I have no idea.

I descovered that by sudden, as I exported the STL from salome with very high quality.

The result was that I got more stand alone zones using spliteMesh.

I decreased the quality to have fun seeing the result and that solved the problem

Anyway, I learned today something new

The STLs has been generated from the geometry. Mesh do not export STLs!

Regards

Peter

Maybe that's the problem. After importing generating my step file from solidworks, I created the step file, and generated the stl file using geometry module, but surfaceCheck said it's not water tight. So I read somewhere on the forum that's it's possible to mesh first and export stl from the meshing module to make the geometry water tight which I did (meshing actually support stl export), and it solved the water tight problem, but probably created new ones
Please tell me. How do you adjust the quality of the stl from geometry module during export?

[peterhess]

Yes the mesh exports STL. You are right...

[obiscolly50]

Originally Posted by peterhess

Yes the mesh exports STL. You are right...

Awesome! Thanks very much for your time and assistance

[wyldckat]

Greetings to all,

I'm following up a bit on this thread, after a couple of PMs that Obi sent me. I'm quoting most of the latest PM here, so that the answer can be public and contextualized (@Obi I hope you don't mind):

Originally Posted by obiscolly50

Peter was able to get the simulation running and solving for the velocities. Surprisingly, the issue was with my stl file according to him. I didn't think that would be an issue because I did a surfaceCheck and they were all closed. I created the STLs in Salome and imported into OpenFoam. At first, after splitMesh I had over 100 regions, then I used the method of subsetMesh which you talked about in an old post to reduce to the 2 required regions. The simulation ran but without calculating the velocities and I couldn't figure out why.

Peter had to recreate my geometry in Salome, but ran into the same problem using the same high resolution stl like I did. But it's surprising that when he eventually reduced the quality of the stl, he obtained only 2 regions without using the setSet or subsetMesh. I would think that the higher the resolution of the stl the better, so it's counter intuitive and I wonder why.

Could you please tell me your process of doing cht multiregion simulations for complex geometries from the stage of geometry creation to stl generation, meshing and splitting mesh. I've seen different people with different methods and it's a bit confusing. I need to know a standard method that works for most cases and stick to it for future simulations. The tutorials though informative, does not take into account complex geometries.

OK, so the first things I have to state are:

1. I rarely do simulations with "chtMultiRegion*Foam" solvers myself, so I'm not familiar with issues with STLs and potential problems with the meshing process.
2. I don't use Salome myself but have guided one or two people in how to use it for multi-region cases.

Now, based on the information on this thread and Obi's PM, my guess is that the problem is that there are doubled surfaces. For example, if you have a box inside another box, you should not have 2 STL surfaces for each side of the internal box: if you have the internal box surface present inside the outer box, then the mesher will get confused with "which side is which for what exactly?"

So my guess is that when the STLs were made coarser, all of the vertices were perfectly coincident without any doubts on how both sides of the inner box (in my hypothesis) would match.


So, what if the hypothetical boxes are side by side? Technically, you should ensure that the same exact solid block for the shared surface is used in both within each STL files, so that the solid entry has the exact vertex definitions, without any mildly different digits. Not exactly a practical solution, if you exported the STL files from elsewhere, I know... but from my experience, that's how you ensure snappyHexMesh behaves properly for multi-region meshes.


As for the extra regions: I haven't looked into the STL files myself, so my guess is that there is an ambiguous surface overlap where the additional regions appeared. For example, if two contiguous boxes were meant to have a matching vertex that is shared by both, but ended up not matching and having the two vertexes end up inside the other box.


I hope this at least somewhat helps... if it's necessary, I can try and look into the case and STL files myself, to try and give a better diagnosis on what happened.

Best regards,
Bruno