[Aurelien Thinat]

Good morning everybody,

I am looking to the cht solver of OpenFoam.

In a first time, I successfully meshed a multi domain with Gambit and then used it in OF.
Now I am looking toward the capabilities of snappyHexMesh in multi doamin meshing. For a start, I'm just willing to start with a solid cylinder into a fluid domain
I'm trying to start from the snappyMultiReginHeater tutorial (in OF-2.0.0) :
- I copy the case dir in the working folder.
- I replace the stl files by cylinder.stl and fluid.stl. fluid.stl is obtain by substracting the cylinder to the whole domain.
- I modify the regionProperties.
- I modify the snappyHexMeshDict to fit the new stl files.

But when I launch SHM, it creates a domain : "domain1" instead of cylinder. The domain fluid is correctly created.

Do you know why I got this error ?

Thank you all.

Aurélien

[Aurelien Thinat]

Hello everybody,

I am still trying to use SHM for a CHT solver use. I understod how to deal with two blocks next one to the other.

But, when I'm trying to go for a more complicated case, it just doesn't work.
I am trying to mesh a single cube (solid part) into a channel (fluid part).

Here are the view of the stl.files :





Then when I launch the script (I copy/paste and adapted a script from the tutorial). I got this :


I don't understand why I got this kind of problem. I have cut the domain in 3 parts and all the boundaries are declared.

If anyone is working on this kind of subject, I need some help.

Thank you.

[wyldckat]

Hi Aurelien,

My guess is that you aren't taking into account the solid names defined inside each STL file! OpenFOAM/snappyHexMesh takes advantage of STL's solid naming system to use said names for direct domain or boundary naming.

Therefore, I advise you to check:

1. The names you have in each STL file; look for the lines that start with "solid".
2. The names given by snappyHexMesh, by looking at the "boundary" files that should be located in "constant/polyMesh/*".

Best regards,
Bruno

[Aurelien Thinat]

Hi Bruno,

Thank for your reply.

I have created the stl by hand from several stl files :
- I have created the solids with starccm+
- I gave a name a each boundary :
For the bottom part :
-plop
- bot_to_top
- bot_to objet
- I have exported each surface in a stl file.
- Then I copy paste all those files into one "bottom.stl".


So in the bottom.stl file I have :
solid plop
(...)
endsolid plop
solid bot_to_top
(...)
endsolid bot_to_top
solid bot_to_objet
(...)
endsolid bot_to_objet

Is that a wrong way to proceed ?

Aurélien

[wyldckat]

Hi Aurélien,

OK, the STL file seems fine. Now check what the resulting boundaries generated by snappyHexMesh are. I think the naming system used by default by sHM is "stl_file_name.solid_name".
So, if you're not renaming them properly in "snappyHexMeshDict", then you'll probably find those boundary names, like: bottom.plop

Best regards,
Bruno

[Aurelien Thinat]

Good morning Bruno,

I couldn't answer your question saturday morning without the files, sorry.

Anyway, the log.snappyHexMesh :

Adding patches for surface regions

Patch Type Region
top :
1 wall top_plop
2 wall top_top_to_bottom
3 wall top_top_to_objet

bottom:
4 wall bottom_plop
5 wall bottom_bottom_to_objet
6 wall bottom_bottom_to_top

objet:
7 wall objet_objet_to_bottom
8 wall objet_objet_to_top

This looks good to me. But I don't understand the feature edge output (still in log.snappyHexMesh) :

Reading features.
Refinement level 2 for all cells crossed by feature "top.eMesh" (26 points, 34 edges).
Refinement level 2 for all cells crossed by feature "bottom.eMesh" (26 points, 34 edges).
Refinement level 2 for all cells crossed by feature "objet.eMesh" (18 points, 26 edges).
Detected 16 featurePoints out of 26 on feature top.eMesh
Detected 16 featurePoints out of 26 on feature bottom.eMesh
Detected 12 featurePoints out of 26 on feature objet.eMesh

Are the featurePoints the number of edges on each surface ? If yes, 12 edges for a cube seems normal. But why only 16 on bottom and top ? It should be 24 no ?

Finally, where I guess there is clearly something wrong :

Surface : top
faceZone : top
cellZone : top
Surface : bottom
faceZone : bottom
cellZone : bottom
Surface : objet
faceZone : objet
cellZone : objet
Found 3 closed, named surfaces. Assigning cells in/outside these surfaces to the corresponding cellZone.

Walking from location-in-mesh (0 0 0.2) to assign cellZones - crossing a faceZone face changes cellZone

Found point (0 0 0.2) in cell 272659 in global region 5 out 7 regions.

Why does it detect 7 regions from 3 closed sufaces ?

[wyldckat]

Hi Aurelien,

Sorry for taking so long to reply, but only now did I get the chance.

Originally Posted by Aurelien Thinat

Are the featurePoints the number of edges on each surface ? If yes, 12 edges for a cube seems normal. But why only 16 on bottom and top ? It should be 24 no ?

It might be related to the feature angle you used when you executed the feature extraction command. Keep in mind that said angle depends on your geometry! It might even be the case where you need to generate feature lines using two different angles (if I'm not mistaken, simply name the output file different and input both names in "snappyHexMeshDict").

Originally Posted by Aurelien Thinat

Finally, where I guess there is clearly something wrong : Why does it detect 7 regions from 3 closed sufaces ?

It might have to do with the fact that you want a multi-region mesh, therefore the zones in between are the empty volumes between the 3 solids!

The one thing I'm finding to be very strange is that in the set of blueish parallelepiped solids don't seem to represent directly the meshed geometry. If the colored zones indicate different patch zones, then something might be out of place, or at least interpreted by snappyHexMesh as such.

Playing with the feature finding angles in both applications might lead to a better result, but only with a simple test case will anyone be able to help you any further... unless they've encountered the same problem.

Best regards,
Bruno

[Aurelien Thinat]

Hello Bruno,

Thank you for answering. I'll test the impact of the feature angles and of the tesselation of the stl file. I would be able to check if snappy is sensible to the triangle's size of the stl. I'll let you know about the results.

Then I don't think I can create a less complicated test case. I have already tested 2 cubes sharing 1 interface. This was successful. So now a cube inside another one seems like, to me at least, the natural next step.

I can upload the files if anyone wants them (even the whole case).

Aurélien

[wyldckat]

Hi Aurélien,

Originally Posted by Aurelien Thinat

Thank you for answering. I'll test the impact of the feature angles and of the tesselation of the stl file. I would be able to check if snappy is sensible to the triangle's size of the stl. I'll let you know about the results.

I've seen a bug report about this, namely the effect of large triangles... here it is: http://www.openfoam.com/mantisbt/view.php?id=309

Originally Posted by Aurelien Thinat

Then I don't think I can create a less complicated test case. I have already tested 2 cubes sharing 1 interface. This was successful. So now a cube inside another one seems like, to me at least, the natural next step.

I can upload the files if anyone wants them (even the whole case).

If you could upload that case (only the complete setup, before running anything in particular ) to either here or to openfoamwiki.net, it would be great. This could be a good simple case that could later be used as a more complete tutorial.
If you wish/can add as a contribution case to openfoamwiki.net, add a new page here: http://openfoamwiki.net/index.php/Main_ContribExamples

Wait, now that I think about this, the floating object tutorial case has a similar setup! It's "multiphase/interDyMFoam/ras/floatingObject", but it doesn't use snappyHexMesh nor is a multi-region case...

Best regards,
Bruno

[Aurelien Thinat]

Ho, this bug report is really interesting. It's like the interface could be displaced by SHM. I'll test to refine the stl file as soon as possible.

Right now I'm working on another thing (a modified BC), but I'll upload the whole case after my tests, maybe tomorrow morning. About the openfoamwiki.net, I can look how it works but I won't be able to write anything before one or two weeks.

Thank you.

[Toorop]

Hi,

I think I bumped into this odd behaviour with sMH as well - my original post.
I wrote a script to set up the heatsink obj file. I find it more convenient than stl since one can use a vertex buffer (no duplicated info) and the format allows the use of quadrilaterals. So I set up my case the same way as the tutorial but with obj instead of stl files. I guess (based on the bug report) the internal polygon triangulation produces large tris and something is broken with 2.0.x!

Thank you for the information, hopefully it will be patched!

[Aurelien Thinat]

Good morning Bruno and Tibor,

I can confirm that the problem is linked to the discretization of the .stl file as mentionned is the bug report in Bruno's post.

I refined the initial mesh of the stl by 2 and here is the results :



There is still a glitch on the surface but when you look at the initial output...

Thank you for your help.

Aurélien

[wyldckat]

Hi Aurélien and Tibor,

@Aurélien: Well, if you can easily pack that example case ready to be used, then I suggest that you add your example to the bug report that I mentioned and explain them (with some detail) that you are having similar problems with a similar case. And since that case is simpler than the other one on the bug report, perhaps they can fix things more quickly!

@Tibor: that tip about the "obj" files is indeed very useful! I got check it out for myself to see what are the limitations for those files

Best regards,
Bruno

[Toorop]

Hi,

updated my OF to check what's the status about the issue. Unfortunately, I'm far from an intermediate sMH user, so I really don't know it's my fault on the settings side or something is broken with the algorithm. My wired bumpy faces are gone with the update but the snapping quality got worse.

I would like to mesh a geometry (heatsink) inside a box (air).

heatsink_sHM:
Initially, I started with only the heatsink.obj file, but couldn't mesh both regions. Today I realized that this is possible with additional options at the refinementSurfaces / heatsink:

faceZone heatsink;
cellZone heatsink;
cellZoneInside inside;

I haven't managed to grasp the meaning of cellZoneInside option, changed it, but without any effect.
The snapping is really not working here, strangely the setup is the same as with the next case.

heatsink_sHM_multi:
The other try is based on snappyMultiRegionHeater case. My interpretation: the blockMesh creates the simulation bounds and the stl files fill up the whole domain. So I created the "negative" geometry of the heatsink in obj format as well. As I said above, the mesh has a hard time following the original surface and additional domains are created - see picture below, white original obj edges, pink additional domains. At least patch naming works correctly - blockMesh boundary, air to heatsink and heatsink to air as defined in the obj file. I'm already afraid of the set up work with chtMultiRegionFoam's BCs. checkMesh doesn't report anything about the new additional domains, but complains about concaveness on cells and faces.

It would be great if someone could share his/her workflow about sMH multiregion meshing / case setup. Which option is more adequate, elegant, easier to setup, post-process?

[Aurelien Thinat]

Well, I'm using .stl files. With these files, the problem is linked to the surface mesh refinement used. With a huge cell size, SHM creates additionnal volumes or glitches on the surface.
If you can export surfaces at stl format and remesh it with another software you can try to fix your problem by this way.

I still have a problem with my simple case (bottom region is renamed Domain1 but is exactly how I want it), and I won't be able to find the time I need to fix it before few days...
Anyway if you just want to have a look at my case, I can upload it tomorrow morning (something like in 12 hours).

Aurélien

[Toorop]

Hi,

I create my mesh from a script where one can set the geometry properties, fin numbers etc. In an OBJ framework it's much more simple to define my geometry, so I want to stick with this format.

If you can upload your case I will definitely have a look at it!

[Aurelien Thinat]

Hi,

You will find the case attached on this post. You just have to create the trisurface folder.
There isn't the top.stl file right now. The stl is too heavy to be uploaded on the forum. Send me your email address in private message and I'll send it (300ko in .gz).

Keep in mind this case is not perfectly working since the bottom part is called domain0 after the mesh.

Aurelien

[Toorop]

Hi,

I have finally managed to kill my "domain generation" problem. The splitMeshRegion flag cellZonesOnly made the trick. The simple cellZones flag additionally divided my cells into separate domains because the original region wasn't continuous in space. The cellZonesOnly doesn't use "walking" as the help states. This doesn't influence the bad mesh quality and the strange pink cells, though.

@ Aurélien:
With this flag, your case gives me this error, but maybe a good starting point for the solution:

For the cellZonesOnly option all cells have to be in a cellZone.

[aqua]

Originally Posted by Aurelien Thinat

Good morning everybody,

I am looking to the cht solver of OpenFoam.

In a first time, I successfully meshed a multi domain with Gambit and then used it in OF.
Now I am looking toward the capabilities of snappyHexMesh in multi doamin meshing. For a start, I'm just willing to start with a solid cylinder into a fluid domain
I'm trying to start from the snappyMultiReginHeater tutorial (in OF-2.0.0) :
- I copy the case dir in the working folder.
- I replace the stl files by cylinder.stl and fluid.stl. fluid.stl is obtain by substracting the cylinder to the whole domain.
- I modify the regionProperties.
- I modify the snappyHexMeshDict to fit the new stl files.

But when I launch SHM, it creates a domain : "domain1" instead of cylinder. The domain fluid is correctly created.

Do you know why I got this error ?

Thank you all.

Aurélien

Hi, I am trying to solve a problem which is as follows:
1. I create two blocks(block1 and block 2) which are next to each other;
2. there is on small cubes in each block, so two cubes in all.
3 perform blockMesh, it's correct.
4 perform SnappyHexMesh: if the LocationInMesh is defined inside block1, then after snappyHexMesh, block2 will disappear. Vice versa.

Could you please help on this? Thank you so much!

[wyldckat]

Greetings Aqua,

I believe that what you are looking for is this tutorial:

tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater

Study it and you should be able to create the desired mesh.

This thread should also be useful to you: http://www.cfd-online.com/Forums/ope...oth-parts.html

Best regards,
Bruno