[Hr_kules]

Hey guys,


i have a mutliregion case with three regions, one is solid, two are fluids. The geometry is build with stls and meshed with snappyhexmesh. The meshing states that everything ran without any errors, which is good so far. But if i split the mesh, or this time use the option -makeCellZones i get a totally wrong assignment of the regions with the cellzones, which i suspect is linked with the wrong assignment of the boundaries after spliting the mesh.
The boundary files are attached, as well as the meshlog that includes:
-blockMesh
-surfaceFeatures
-snappyHexMesh
-createBaffles
To the screenshot:
I have visualized all the cellzones in paraView, on the left side is fluidcold, there everything seems fine and the boundaries also match, in the middle is the solid plate supposed to be, however openfoam states that this is the hot fluid. On the right side is the cellzone that is supposed to be the hot fluid, however it is named plate.

Any help is really appreciated, if any further information is required, i will provide it as soon as i can!

[Hr_kules]

Anybody got an idea?

[Yann]

Hi Nico,

To be able to properly assign cells to a cellZone, snappy needs to have a closed volume. This is what it complains about with the warning plotted at the beginning of your snappy log.

I have seen you based your case on the shellAndTubeHeatExchanger tutorial where the exact same thing happens with snappyHexMesh (same warnings). Since I mostly use the OpenCFD branch, I did not have a chance to dig into this specific tutorial (which exists only in the foundation branch) so I am not sure why it is done this way. There are significant differences about the meshing process of multiregion cases between both branches so maybe I am missing something with the version you are using.

I am sorry my message is not very helpful! I have seen you struggle with this for a long time and rarely get answers so I thought I could give a bit of feedback even if I do not have a solution for you.
Yann

[Hr_kules]

Hi Yann,
yes the shell and tube heat exchanger was my main pattern on how to do this. I was under the impression if i do everything like in this tutorial besides the different geometry it should work.


The version i am using is version 9 (if that helps with arring the information)
Do you know any good information on how to do multiregion meshing? I found two written tutorials sadly one is not really applicable, the other doesn't really say a lot, so my level of confusion and despair is maximum.
I also tried meshing each region istelf and then merge the meshes, however the thermal coupling turned out to be very bad, so i wanted to try the multi region approach again.


Nico

[Yann]

I am used to the OpenCFD branch where you can provide one single STL file for the whole geometry, and then use the locationsInMesh to define a point in each region with the associated region name. Snappy then deals with the cellZone definition according to the points you defined.

This feature is not implemented in the foundation branch, so the other way around is to use one closed STL file for each region, and use this closed surface to define the corresponding cellZones using this syntax:

some_region
{
	level           ( 1 1 );
	cellZone        myRegionName;
	mode            inside;
}

And then use splitMeshRegions with the -cellZones or -cellZonesOnly options.

The shellAndTubeHeatExchanger tutorial seems to use another method since STL files are not closed volumes but I am not sure how different it is since I did not spend time working on it.

For the two first methods I described, it is important to have clean STL files, and the surfaceCheck utility can come in handy to check for STL related issues.

Yann

[Hr_kules]

Hey Yann,


i treid to use your input and i am now able to create somewhat nice and clean cellZones!
However the boundaries still don't necessary match the cellZones. I am intrigued by the command surfaceToPatch to somewhat manually assign the boundaries.


Hopefully this should help

[Yann]

Hi Nico,

Glad to know you solved your cellZones issue.
I never used surfaceToPatch so I cannot really help with that but let us know how it goes if you try using it!

Yann

[Hr_kules]

Hey Yann,


this may come out of thin air, but you mentioned, that a feedback would be appreciated, so surfaceToPtach doesn't solve the underlying issue, i also started to redefine the stls so that they are closed. I also changed to approach similar to the heated duct tutorial. This produces very clean cell zones and the interfaces are just like i want them. However after testing the two fluid regions seperated by the solid region with only one corrugation and seeing the results i wanted i was eager to test it with more and already with two corrugations to make it someday look like a heat exchanger plate. I sadly land at the same issue i am trying to tackle for a long time now. And every change i make to the snappyhexmeshdict results in 24 faces in wrong boundary definitions.


Since i changed the approach i thought you may know some hints, if not, i can at least deliver the information that surfaceToPatch after meshing doesn't solve anything


Cheers

[Yann]

Thanks Nico, feedback is always welcome in order to inform other users on your own failures and successes! It's always good to know where are the dead ends before spending days, if not weeks, trying to solve an issue!

I also experienced issues such as your when meshing multiregion cases. I am not sure why this happens, I guess it might be related to the snapping phase.
You can try to play with the blockMesh position relatively to your geometry: sometimes, a slight change in the blockMesh position can ease the job for snappy and help to get rid of some errors.
Another way around is to fiddle with the features and surfaces refinement levels.

Those are not real solutions, only workarounds which might help...

Regards,
Yann

[Hr_kules]

Hey Yann,

if the feddback is any helpfull for others, i am very happy to help! After some tests, i have noticed, that there seems to a relation between the background mesh from blockMesh and the refinement of the edges with featureEdgeMeshes derived from the stls.
I was wondering wether there are some general rules of thumb for setting up the background mesh and the desired refinement levels apart from tedious trial and error.

Something like this could solve the problem once and for all, as for some bodies i got the desired mesh and more important: matching boundaries.

Cheers

[Yann]

AFAIK, there is no rules of thumbs but I would definitely be interested to learn if someone knows such rules!

What you describe is consistent with what I experienced when dealing with multiregion meshing with snappy. I am not sure to understand why it happens, I feel like snappy can sometimes have a hard time to satisfy mesh quality criteria and it leads to such errors.

Moving the blockMesh of playing with refinement levels can make the job easier for snappy or create more problems. As you said this leads to tedious trial and error.

Multiregion meshing with snappy is tricky because snappy meshes all regions at once. At the interfaces, cells are snapped onto the geometry, but since cells remain on both sides, it can easily create quality issues such as non-orthogonality at the interface. Since snappy always tries to satisfy the mesh quality criteria, it can "damage" the interface while trying to get better quality check.

I don't know if there is a solution to this. For a while I thought to open an issue on the bugtracker but I always lacked of a simple case to demonstrate the issue.

Yann

[Hr_kules]

Hey Yann,

It is somewhat reasuring, that i am not the only one having this issue. Like i said, i have some parameter configurations seen that would work for my case, if i change the dimensions if my geometry, the parameters change to some unkown degree.
I am quite compelled tonoffer my case, as it is simple enough to demonstrate the issue. I may had to double check with my supervisor. On a side note i have noticed that the issue gets somewhat worse if i try to get close(r) to an actuall heat exchanger plate, es they are unfortunately a lot thinner than wide or long (and i mean a lot).
For this reason i am compelled to upscale the stl, as they are just created via an python script and a handfull of values and downsize it after meshing, because the refinement of the eMesh really seems to tackle the issue the Best and a thinner geometry would force me to further increase the refinement Level, but the meshing crashes due to high amounts of cells.

Cheers