CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Native Meshers: snappyHexMesh and Others

Snappy : Multi-region meshing

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   November 15, 2011, 05:54
Default Snappy : Multi-region meshing
  #1
Senior Member
 
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7
Aurelien Thinat is on a distinguished road
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 is offline   Reply With Quote

Old   November 18, 2011, 11:05
Default
  #2
Senior Member
 
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7
Aurelien Thinat is on a distinguished road
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.
Aurelien Thinat is offline   Reply With Quote

Old   November 18, 2011, 17:55
Default
  #3
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,312
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   November 18, 2011, 18:12
Default
  #4
Senior Member
 
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7
Aurelien Thinat is on a distinguished road
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
Aurelien Thinat is offline   Reply With Quote

Old   November 19, 2011, 03:44
Default
  #5
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,312
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   November 21, 2011, 04:04
Post
  #6
Senior Member
 
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7
Aurelien Thinat is on a distinguished road
Good morning Bruno,

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

Anyway, the log.snappyHexMesh :
Quote:
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) :

Quote:
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 :
Quote:
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 ?
Aurelien Thinat is offline   Reply With Quote

Old   November 22, 2011, 15:54
Default
  #7
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,312
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Aurelien,

Sorry for taking so long to reply, but only now did I get the chance.
Quote:
Originally Posted by Aurelien Thinat View Post
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").

Quote:
Originally Posted by Aurelien Thinat View Post
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
wyldckat is offline   Reply With Quote

Old   November 23, 2011, 05:04
Default
  #8
Senior Member
 
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7
Aurelien Thinat is on a distinguished road
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
Aurelien Thinat is offline   Reply With Quote

Old   November 23, 2011, 06:05
Default
  #9
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,312
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Hi Aurélien,

Quote:
Originally Posted by Aurelien Thinat View Post
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

Quote:
Originally Posted by Aurelien Thinat View Post
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
wyldckat is offline   Reply With Quote

Old   November 23, 2011, 08:22
Default
  #10
Senior Member
 
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7
Aurelien Thinat is on a distinguished road
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.
Aurelien Thinat is offline   Reply With Quote

Old   November 23, 2011, 12:11
Default
  #11
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
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!
wyldckat likes this.
Toorop is offline   Reply With Quote

Old   November 24, 2011, 04:52
Default
  #12
Senior Member
 
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7
Aurelien Thinat is on a distinguished road
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
Aurelien Thinat is offline   Reply With Quote

Old   November 24, 2011, 16:08
Default
  #13
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,312
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
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
wyldckat is offline   Reply With Quote

Old   November 29, 2011, 12:22
Default
  #14
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
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:
Code:
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?
Attached Images
File Type: png heatsink.png (12.5 KB, 99 views)
File Type: png heatsink_snapErr.png (25.3 KB, 126 views)
File Type: png heatsink_tentacle.png (59.7 KB, 141 views)
Attached Files
File Type: gz heatsink_sHM.tar.gz (43.0 KB, 17 views)
File Type: gz heatsink_sHM_multi.tar.gz (81.9 KB, 39 views)
Toorop is offline   Reply With Quote

Old   November 29, 2011, 12:40
Default
  #15
Senior Member
 
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7
Aurelien Thinat is on a distinguished road
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
Aurelien Thinat is offline   Reply With Quote

Old   November 29, 2011, 12:45
Default
  #16
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
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!
Toorop is offline   Reply With Quote

Old   November 30, 2011, 04:10
Default
  #17
Senior Member
 
Aurelien Thinat
Join Date: Jul 2010
Posts: 154
Rep Power: 7
Aurelien Thinat is on a distinguished road
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
Attached Files
File Type: zip CHT-mesh-1.zip (32.4 KB, 25 views)
File Type: zip constant.zip (1.1 KB, 12 views)
File Type: zip bottom.zip (59.0 KB, 12 views)
File Type: zip objet.zip (31.9 KB, 18 views)
Aurelien Thinat is offline   Reply With Quote

Old   December 19, 2011, 09:20
Default
  #18
Member
 
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 8
Toorop is on a distinguished road
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:
Code:
For the cellZonesOnly option all cells have to be in a cellZone.
Toorop is offline   Reply With Quote

Old   January 4, 2012, 12:37
Default
  #19
Member
 
Aqua
Join Date: Oct 2011
Posts: 96
Rep Power: 5
aqua is on a distinguished road
Quote:
Originally Posted by Aurelien Thinat View Post
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!
aqua is offline   Reply With Quote

Old   January 4, 2012, 16:36
Default
  #20
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,312
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings Aqua,

I believe that what you are looking for is this tutorial:
Code:
tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater
Study it and you should be able to create the desired mesh.

This thread should also be useful to you: how to get both parts ?

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Multi Region Meshing bruce OpenFOAM Native Meshers: snappyHexMesh and Others 12 July 31, 2013 10:09
Multi region meshing & recovering the original patch names fluidpath OpenFOAM Native Meshers: snappyHexMesh and Others 4 May 19, 2013 19:13
Using starToFoam clo OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 33 September 26, 2012 04:04
StarToFoam error Kart OpenFOAM Meshing & Mesh Conversion 1 February 4, 2010 05:38
Import gmsh msh to Foam adorean Open Source Meshers: Gmsh, Netgen, CGNS, ... 24 April 27, 2005 08:19


All times are GMT -4. The time now is 16:48.