Snappy : Multi-region meshing
 

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

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 :


http://data.imagup.com/11/1136293576.jpghttp://data.imagup.com/11/1136293662.pnghttp://data.imagup.com/11/1136293846.jpg


Then when I launch the script (I copy/paste and adapted a script from the tutorial). I got this :
http://data.imagup.com/11/1136294011.pnghttp://data.imagup.com/12/1136294127.png

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.

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

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

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

Good morning Bruno,

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

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

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 :
Why does it detect 7 regions from 3 closed sufaces ?

Hi Aurelien,

Sorry for taking so long to reply, but only now did I get the chance.
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").

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

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

Hi Aurélien,

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

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

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.

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!

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 :
http://www.hostingpics.net/viewer.ph...0967bottom.png
http://hpics.li/660e92bhttp://www.imagup.com/data/1136790235.htmlhttp://data.imagup.com/11/1136790235.png

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

Thank you for your help.

Aurélien

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

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

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

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!

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

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:

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!

Greetings Aqua,

I believe that what you are looking for is this tutorial: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

hi, Bruno, Thank you so much for your reply. I will try that.
Cheers!

Aqua

Hello Aurélien，

I am doing the same example: there are two cubes next to each other, cube1.stl and cube2.stl. but i couldn't make it to get the correct snappyhexmesh. Could you please, if possible, send me your case?
Thank you sooooo much!!!

Aqua

Hi Aqua,

You should have a look to the tutorial of snappyHexMesh for CHT solver. Copy/paste the case directory and change the .stl file by your own. Then edit the snappyHexMeshDict and change the name of the .stl file too.

I don't have my first test case anymore.

Aurélien

Hello，Aurélien，
Thank you so much for your reply. what i did is:
1. modify the blockMeshDic to change the block;
2. put my iblock.stl and oblock.stl into the file "triSurface"
3. change bottomAir and topAir to iblock and oblock under the file "constant"
4. change regionProperties
5. change snappyHexMeshDict.
I would say, I did what i can think of. But only iblock has mesh, oblock doesn't....

Besides, there are some files named domain1 and domain2 created, I don't know why...

Even in the bounday file for iblock, something like this appeared:
iblock_to_domain1
{
type directMappedWall;
nFaces 1190;
startFace 127154;
sampleMode nearestPatchFace;
sampleRegion domain1;
samplePatch domain1_to_iblock;
offsetMode uniform;
offset (0 0 0);
}
iblock_to_domain2
{
type directMappedWall;
nFaces 2835;
startFace 128344;
sampleMode nearestPatchFace;
sampleRegion domain2;
samplePatch domain2_to_iblock;
offsetMode uniform;
offset (0 0 0);

I don't understand why something like iblock_to_domain2 would appear....

thank you so much!

Aqua

Yes, try to refine your blockMesh and the surface mesh of the stl.

Thank you so much for your reply. May I ask, which software do you use to edit stl file? I have proe, but it doesn't work...

Thank you!

Aqua

I used starccm+

Hello,
I tried starccm+ too, and created different boundaries for different surfaces. such as in the picture. Then right click "import", choose "export surface", to stl file. BUT, when I open the stl file in ICEM, all the boundaries disappeared and there is only ONE part, as you can see in another picture.

I am so struggling about this. Could you please tell me how to solve this?

Thank you so much!

Aqua

- You have to create 1 region per boundary.
- Then export each one in a different stl file "boundary1.stl" boundary2.stl" etc.
- Open each boundary*.stl, rename it "solid boundary1 (...) endsolid boundary1"
- Copy paste everything in "cube.stl" : it should look like :
'solid boundary1
...
endsolid boundary1
solid boundary2
...
endsolid boundary2
solid boundary3
...'

And relaunch SHM.

Thank you so much!!!!! Finally I know how to do this!

All the best!!!

Aqua

Hello，Aurélien，
I got it managed to modify the stl file(two blocks next to each other: iblock and oblock, see the attachment). And after SHM, there is no error. But the weired thing is:
-two time step files were created, 0.001 and 0.002(see the attachment), in which there was the file polyMesh. in the tutorial case, under constant/bottomAir, there is polyMesh, under constant/topAir, there is also the polyMesh, etc.
-so i copied the polyMesh in file 0.002 to constant and check it in paraFoam, seems like the mesh is ok (see the attachment) .

I am not sure whether the mesh is right or not. Could you please help on this question: why i didn't get polyMesh under constant/iblock/, but i got it in the file 0.002?

Also, in paraFoam, under Mesh Parts, there is no iblock faceZone, why?

Thank you so much!

Hello，Aurélien，
after SHM, I run splitMeshRegions, then under the file 0.002, there are the two files named iblock and oblock, including their own polyMesh! Is that right now?
Thank you so much!
Aqua

Hi, Bruno,
I created a simple mesh for two stl files, named iblock.stl and oblock.stl. they are next to each other, having an interface.
But, do you remember what i want to do? I want to simulate two cars passing by each other, using moving mesh. So, the situation would be like in the picture as attachment. So, it's not a multiregion problem actually. there is only AIR. But in the case snappyMultiRegion, the mesh was created under each file named bottomAir, topAir, heater, leftsolid and right solid.
So, is there some way to put all the mesh in one file? in my case, it will be, how i can put polyMesh under iblock, and polyMesh under oblock together as in one polyMesh?
Thank you so much!

Aqua

Hi Aqua,

Well, since you wanted two strictly defined environments, I thought that the easiest way would be to use the multi-region feature in snappyHexMesh.

OK, since you don't need a multi-region, then all you need is the two cubes representing the cars. Then just define the location point on the outer volume surrounding both cars.
As for having that wall dividing the two sides of the mesh, you don't need to strictly define it with an STL file; you can simply define the outer bounding box in two connected parts in the "blockMeshDict" file. snappyHexMesh will only change that mesh if the cubes are too close to that zone.

Best regards,
Bruno

Hello Bruno,
thank you so much for your reply. Sorry that I didn't make it clear: I have two cars, which would pass by each other in the simulation. Since I will use moving mesh, so, there has to be another two boxes, containing the two cars, and the two boxes will move towards each other. Like in the attachment:
icube and ocube stand for the two cars. block1 contains icube, block2 contains ocube. interface between block1 and block2 will be set as GGI, and block1 and block2 will move towards each other...
Do you have some good idea? Thank you so much!
Aqua

Hi Aqua,

OK, then let's step back and look at existing examples. Which tutorial are you basing yourself for your case? Namely, which tutorial(s) are you going to base yourself for GGI?

Best regards,
Bruno

Hi, Bruno,
For GGI, I want to use the tutorial "turbopassengerotating" in OF16ext. But I have to use SHM for the complicated cars. So, currently i am looking for how to creat the mesh first...
thank you！
Aqua

Hi Aqua,

OK, the tutorial you are talking about is "incompressible/icoDyMFoam/turboPassageRotating". I haven't tested my theory yet, but I propose the following procedure:

1. You create a "blockMeshDict" that has the two environments in a single box.
2. Still on that "blockMeshDict", create "overlapGgi interface1" and "overlapGgi interface2" that define the wall that separates the two outer/environment boxes.
3. After running blockMesh, you can now simply have the two cars in STL format and run snappyHexMesh! snappyHexMesh should be able to generate the surrounding mesh and preserve the wall between them!

Any other missing feature can later be generated by either using topoSet or setSet.

If creating the separation wall leads to snappyHexMesh only generating the mesh on one side, then remove that separation wall from "blockMeshDict". You can recreate that wall after the mesh has been created with snappyHexMesh, simply by using topoSet or setSet and/or createPatch.
It might also be possible to simply skip the dedicated separation wall if you create the cellZones manually... which again, you can create with at least setSet.

If you don't know how to use setSet, run it and type in the command:Good luck!
Bruno

Morning Bruno,
thank you so much for your reply!
Yes, for me the situation would be: "snappyHexMesh only generating the mesh on one side".
Another thing I want to confirm is, when you said " create a "blockMeshDict" that has the two environments in a single box." sorry I don't understand this part:
blocks
(
hex (0 1 2 3 4 5 6 7) (20 20 1) simpleGrading (1 1 1)
hex (8 9 10 11 12 13 14 15) .....
);
you see, I may creat two hex as the outer envirment boxes. so there will be two hex boxed. But how to "creat them in a single box"?
Thank you so much!

Hi Aqua,

Unfortunately I'm not experienced enough on this subject. My guess is that you should generate the mesh in two steps:

1. Generate the mesh as if you weren't going to use GGI.
2. Then after the mesh is completely made, use one (or more) of the mesh manipulation utilities, such as createPatch, topoSet or setSet.

I also suggest that you post your question in the forum at http://www.extend-project.de/ - simply because there you should find more people dedicated to using OpenFOAM 1.6-ext and GGI!

Good luck!
Bruno