chtMultiRegion not solving for velocity field
 

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 :confused: . Below is a code excerpt from the run

Hallo,

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

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.

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.

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!

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!

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:

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.

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.

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.

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.

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!

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 :)

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

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 :D

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

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

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! :D

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

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?

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 :eek:

Anyway, I learned today something new :)

The STLs has been generated from the geometry.

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 [emoji46]
Please tell me. How do you adjust the quality of the stl from geometry module during export?

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

Awesome! Thanks very much for your time and assistance [emoji4]

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):
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