|
[Sponsors] |
[snappyHexMesh] Snappy : Multi-region meshing |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 165
Rep Power: 16 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 165
Rep Power: 16 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#3 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128 ![]() ![]() ![]() ![]() ![]() ![]() |
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:
Bruno
__________________
|
|
![]() |
![]() |
![]() |
![]() |
#4 |
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 165
Rep Power: 16 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#5 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128 ![]() ![]() ![]() ![]() ![]() ![]() |
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
__________________
|
|
![]() |
![]() |
![]() |
![]() |
#6 | |||
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 165
Rep Power: 16 ![]() |
Good morning Bruno,
I couldn't answer your question saturday morning without the files, sorry. Anyway, the log.snappyHexMesh : Quote:
Quote:
Finally, where I guess there is clearly something wrong : Quote:
|
||||
![]() |
![]() |
![]() |
![]() |
#7 | ||
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128 ![]() ![]() ![]() ![]() ![]() ![]() |
Hi Aurelien,
Sorry for taking so long to reply, but only now did I get the chance. Quote:
Quote:
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
__________________
|
|||
![]() |
![]() |
![]() |
![]() |
#8 |
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 165
Rep Power: 16 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#9 | ||
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128 ![]() ![]() ![]() ![]() ![]() ![]() |
Hi Aurélien,
Quote:
Quote:
![]() 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
__________________
|
|||
![]() |
![]() |
![]() |
![]() |
#10 |
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 165
Rep Power: 16 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#11 |
Member
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 17 ![]() |
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! |
|
![]() |
![]() |
![]() |
![]() |
#12 |
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 165
Rep Power: 16 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#13 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128 ![]() ![]() ![]() ![]() ![]() ![]() |
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
__________________
|
|
![]() |
![]() |
![]() |
![]() |
#14 |
Member
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 17 ![]() |
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; 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? |
|
![]() |
![]() |
![]() |
![]() |
#15 |
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 165
Rep Power: 16 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#16 |
Member
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 17 ![]() |
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! |
|
![]() |
![]() |
![]() |
![]() |
#17 |
Senior Member
Aurelien Thinat
Join Date: Jul 2010
Posts: 165
Rep Power: 16 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#18 |
Member
Tibor Nyers
Join Date: Jul 2010
Location: Hungary
Posts: 91
Rep Power: 17 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#19 | |
Member
Aqua
Join Date: Oct 2011
Posts: 96
Rep Power: 14 ![]() |
Quote:
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! |
||
![]() |
![]() |
![]() |
![]() |
#20 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,978
Blog Entries: 45
Rep Power: 128 ![]() ![]() ![]() ![]() ![]() ![]() |
Greetings Aqua,
I believe that what you are looking for is this tutorial: Code:
tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater This thread should also be useful to you: http://www.cfd-online.com/Forums/ope...oth-parts.html Best regards, Bruno
__________________
|
|
![]() |
![]() |
![]() |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
How I can introduce my power heat (W) in chtMultiRegionFoam? | aminem | OpenFOAM Pre-Processing | 32 | August 29, 2019 02:23 |
[mesh manipulation] Importing Multiple Meshes | thomasnwalshiii | OpenFOAM Meshing & Mesh Conversion | 18 | December 19, 2015 18:57 |
[snappyHexMesh] New multi region meshing tutorial with sHM | Tobi | OpenFOAM Meshing & Mesh Conversion | 0 | November 24, 2014 17:42 |
[snappyHexMesh] Snappy. Mesh region between 2 concentric stls | be_inspired | OpenFOAM Meshing & Mesh Conversion | 3 | May 20, 2014 13:21 |
[snappyHexMesh] How to generate geometry - multi region stl, obj | wersoe | OpenFOAM Meshing & Mesh Conversion | 0 | June 1, 2013 03:02 |