|
[Sponsors] |
[snappyHexMesh] Using snappyHexMesh to create a multi-region mesh for a whole building |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
April 24, 2014, 16:06 |
Using snappyHexMesh to create a multi-region mesh for a whole building
|
#1 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hello guys,
I am having a problem that I do not know how to solve. On the big picture I have a house modeled in Solidworks and I am trying to perform a conjugate heat transfer analysis on it. I have followed the multiRegion snappy tutorial but I still cannot get it to work. For both trials, I have concatenated internal and external surfaces into two stls. The first trial deals with two stls that are not closed; therefore, it doesn't surprise me that it doesn't snap both inside and outside simultaneously. Yet, the second trial deals with closed stls and still I end up not getting a desirable result. In fact, both trials give me the same end result. The outside wall mesh looks fine however once I get inside the geometry I cannot see the mesh of the internal wall. Please note that this is a very coarse mesh on blockMeshDict (40 40 40) in order to speed up snappy's output. Also please find attached the sample for closed stl files. I would greatly appreciate if you guys could take a look since I have been stuck in this problem for more than a week. I am trying to get this working so I can proceed with my simulation and submit my thesis. Please let me know if you are able to download in Dropbox. https://www.dropbox.com/s/g0u22x3hqy...ntativaOne.zip Cheers! |
|
April 26, 2014, 08:27 |
|
#2 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Greetings Lucas,
OK, let's see if I'm able to explain this in a clear way... I'll try using a reference list, implied by the tutorials present in OpenFOAM:
Anyway, to solve this, you need to:
Code:
top1 { level (4 4); cellZone top1; faceZone top1; cellZoneInside inside; } Best regards, Bruno
__________________
|
|
April 26, 2014, 16:21 |
|
#3 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Bruno,
I understand where you are coming from but I am slightly confused on how to proceed. From my understanding, it seems that you are suggesting to save STLs for external and internal surfaces. I can certainly do this, however, my problem lies on saving STLs for the holes in the dome of the house. The reason for that is because these holes were created in Solidworks and it is not possible to close them perfectly from the outer and inner side of the dome. This is due to the presence of the layers of brick. Thus, this justifies why when you see the STLs for the blocks they are not rectangular solids. This is what I am envisioning, please correct me if I am wrong: 1. Save all STLs for internal and external surfaces (therefore wall thickness shall not be included) with the exception of the air openings 2. Save all air openings (rectangular and cap of the dome) as an individual STL for solids and not faces 3. Choose a point that falls inside the internal STL and define cellZoneInside as inside for the external, block, door, and cap STL Is that what you mean? I am afraid that the cracks in between the dome and the air openings will create a leakage while meshing. Thank you so much Bruno. Cheers Lucas Lucas |
|
April 27, 2014, 17:21 |
|
#4 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hey Bruno,
I made the updates you suggested but I am not sure if it is working fine or not. Please find attached some images below of the mesh sliced for the internal walls and the dome. From the images, you can clearly see the internal part of the house even though you cannot identify when walking in the geometry. You will notice that the format of the internal house is clearly denoted in the drawings just like the thickness of the dome. Please let me know what your thoughts are. New Updated Case: https://www.dropbox.com/s/moms7x6b9u...tivaDoming.zip Thanks for your help! Lucas |
|
April 27, 2014, 18:26 |
|
#5 | ||
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Hi Lucas,
Sorry, I didn't manage to answer you more this weekend. I'll try to have a look tomorrow to your case. Regarding this part: Quote:
Commercial CFD software usually provides this facility, namely the ability to tweak the geometries, prior to meshing. With OpenFOAM, you'll have to rely on other software, such as Blender and/or Meshlab. Quote:
About "all air openings": if the air is meant to travel from within the building to the outside, directly and clearly through these openings, then these air openings should not be in separate STL files and therefore not in independent regions. In other words, if the air is meant to travel from the inside to the outside, then the region for the air should be a single one, as it will allow it to flow from the inside to the outside and vice-versa... Although... perhaps using cyclicAMI patches might do the trick, if each "air opening" might need to be occasionally closed... Anyway, I'll try to have a better look into the latest test case tomorrow. Best regards, Bruno
__________________
|
|||
April 28, 2014, 15:37 |
|
#6 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Hi Lucas,
I've finally managed to look at your latest case. It looks a bit better, but there are a few details I can't understand clearly:
Bruno
__________________
|
|
April 28, 2014, 16:22 |
|
#7 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hey Bruno,
Thank you so much for taking a look into my files. What I personally find very interesting about this problem is the fact that if I slice a plane through my mesh I can clearly see that the dentro.stl and fora.stl were meshed simultaneously. The biggest proof is that the mesh actually takes the shape of the floor of the dentro.stl. As you can see in the third picture attached I have labeled in red exactly the shape that I am talking about.This leads me to a very interesting conclusion. It seems that I do not need to see the walls inside the case study as long as a sliced plane clearly denotes the existence of both STLs. Would you agree to that? Answering your questions: 1 and 2. The blocks*, top*, and door files represent air openings in the house. As you can see in the attached pictures there are no actual doors or windows in these houses in southern Turkey. There are simply holes in the walls. Yet, since I want to mesh both air and walls simultaneously for a conjugate heat transfer problem I need to have a closed geometry. Therefore, answering your question, in the dentro.stl those blocks are supposed to represent air and not bricks. Source: http://padfield.com/turkey/harran/index.html 3. Since this is a conjugate heat transfer problem I anticipate to have seven regions for the solid (i.e. north, south, east, west, ceiling, dome short, and dome tall) and fourteen regions for the fluid (i.e. all blocks, top caps, and door). Please notice that I have so many entities because I will be applying different boundary conditions to each face (i.e. velocity and temperature). In other words, a boundary condition will be imposed on the surface. My goal with this research is to understand how the edges of the bricks (illustrated in the dentro.stl) can affect thermal comfort inside the house. Thus, I would be running a case with bricks (the file you have) and a case with no bricks. 4. These files were created in Solidworks. I have saved individual STLs for internal and external surfaces and I was very careful making sure that every STL was saved as ASCII and started with solid <filename> and finishes with endsolid <filename>. Furthermore, I concatenated all STLs for the internal and external faces by using the following command in the terminal: Code:
cat <internal1>.stl <internal2>.stl .... <internalN>.stl > internal.stl 5. I have initially used SketchUp however I ran into serious issues. Most design softwares (i.e. Rhino, SketchUp, Cinema4d, etc) are not oriented to engineering practice and are very dangerous for CFD simulations since they do not perfectly close a geometry. I had multiple open edges that led to leakages in my mesh and I was never able to output a decent result. So, in order to overcome these leakages I have used Meshlab. The problem with Meshlab is that it always identified non-manifold edges and whenever I tried to delete them, in order to fill holes, my entire geometry was simply gone. On top of that, Meshlab has been constantly crashing in my Mac while attempting to fill holes. I have no experience with Blender. Please let me know what your thoughts are. Thanks a lot! Lucas Mutti *PS: The fourth image illustrates a more refined mesh (80 80 80) of what I am exactly pointing out with the red arrows. |
|
May 1, 2014, 06:59 |
|
#8 | |||||||
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Hi Lucas,
OK, it's a holiday today in Portugal, I'm a bit more rested today and managed give some thought into this. The first topic I want to address is how to examine the mesh. Instead of using a slice, do these steps:
Quote:
Quote:
Quote:
In case you do want more solid regions, please postpone their creation to after you've mastered the basics. Quote:
Quote:
Quote:
I'm not familiar with Rhino and Cinema4d, but if they are similar to Blender, then they should have powerful surface meshing capabilities. Quote:
This 2 pass meshing strategy should do the trick, at least with the current features you have. Best regards, Bruno
__________________
|
||||||||
May 1, 2014, 21:53 |
|
#9 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hey Bruno,
Thanks for the input. I will take it into consideration. Cheers! |
|
May 9, 2014, 00:27 |
|
#10 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hi Bruno,
I ran into another problem which I am not sure how to proceed. It turned out that based on our previous conversation I decided to keep it simple as two different stl files: dentro (fluid) and fora (solid). With that being said, I preferred to keep all openings in the dentro stl because I have noticed that all openings were still clearly labeled under the /polyMesh/boundary script. Aside to that, I have been working on getting conjugate heat transfer problems set up. I was able to do so with no trouble; however, I have ran into an issue while trying to run the conjugate heat transfer case for the snappy files. In other words, I have done exactly the same thing as shown on the "mesh/snappyHexMesh/snappyMultiRegionHeater". Yet, it seems that whenever I run the splitMeshRegions command (same command under the ./Allrun files of the tutorial) I notice that my regions swap and a new domain is formed. For instance my fora region (solid) becomes dentro and my dentro region (fluid) becomes domain1. I have been reading previous discussions but I frankly do not understand why that is happening. Have you experienced such problem before? HTML Code:
http://www.cfd-online.com/Forums/openfoam-meshing-snappyhexmesh/112637-multiple-regions-3.html#post489673 Lucas |
|
May 9, 2014, 14:34 |
|
#11 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Hi Lucas,
It feels like the problem is that there was still some mesh bleeding out of the desired regions, which made splitMeshRegions to go with the option of "all of these other regions will go to this other domain, because there is no clear separation". But there is something I don't understand: how did you deal with the space between the "dentro" and the "fora" geometries? In other words, how are you telling snappyHexMesh that the space between the 2 STLs is a 3rd region? Best regards, Bruno
__________________
|
|
May 9, 2014, 14:48 |
|
#12 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hey Bruno,
Thats a very good question. I am not telling sHM that the space between dentro and fora is a 3rd region. I saved STL files for the internal and external surfaces. It seems to me that the reason why this doesn't work is because the external STL is covering the internal one. With that being said, it seems to me that it would be the case of saving STL files for each individual walls (front, back, and sides) instead of saving a combined STL file with all external surfaces. I think that the reason why this approach is better is because it clearly tells sHM where the boundaries of the geometry are. I will try to do this in Fluent first and see how it goes because it will take plenty of time. Cheers! Lucas |
|
May 11, 2014, 19:21 |
|
#13 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hey Bruno,
I tried to convert this Fluent mesh to OpenFOAM but it didn't workout. When I try ansysToFoam, nothing other than Create time is printed. When I try fluent3DToFoam it says that it can't read the script due to a token. Also, when I try the fluentMeshToFoam command it doesn't workout. Lastly, I tried to run the mshToFoam but it also doesn't run. Would you be able to try this mesh for me please? https://www.dropbox.com/s/4eypsof93htqj64/harran.msh Regards, Lucas |
|
May 11, 2014, 21:42 |
|
#14 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hey Bruno,
Sorry but I figured it out where the problem is. I was not aware that .msh files could be saved as binary or ASCII. I changed the settings to ASCII and it ran ok by using the fluent3DMeshToFoam. Thanks for the help, Lucas |
|
May 19, 2014, 14:29 |
|
#15 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hey Bruno,
I came across a problem which I am not sure on how to solve. According to Foam, my code is diverging and I don't understand why. I doubt this has something to do with the fact of using a Fluent mesh instead of an OpenFOAM file. I have been playing with my controlDict, fvSchemes, and fvSolution scripts but it still doesn't seem to work. I am attaching below the case study. https://www.dropbox.com/s/prgk5wudsmrewkn/fluent.zip Cheers, Lucas |
|
May 24, 2014, 03:33 |
|
#16 |
Member
Lucas Mutti
Join Date: Aug 2013
Posts: 47
Rep Power: 13 |
Hey Bruno,
After spending some time on this problem, I decided to pursue the mesh via Ansys Workbench in order to avoid leakages that I was encountering. At the beginning, I thought I was able to set up the case properly; however, after a few revisions, I noticed that something was wrong. I believe the mesh generated on Fluent is fine and all boundaries were labeled accordingly. The issue lies in the changeDictionary for the solid and fluid. For instance, in every conjugate heat transfer problem the following command is necessary to guarantee the communication between both solid and fluid domains: Code:
"fluid_to_.*" { type compressible::turbulentTemperatureCoupledBaffleMixed; Tnbr T; kappa fluidThermo; kappaName none; value uniform 288.49; //Average of internal surface temperatures of kitchen and datalogger } Cheers Lucas |
|
May 31, 2014, 13:56 |
|
#17 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Hi Lucas,
Sorry, I didn't managed to look into this issue any sooner. And I don't know if the latest case you're using now is still the one at the Dropbox link. Nonetheless, I had a quick look just now and you're missing an important option when using changeDictionary, namely the option "-literalRE". In other words, change in Allrun to this: Code:
for i in fluid solid do changeDictionary -region $i -literalRE > log.changeDictionary.$i 2>&1 done Essentially what this option does is to not interpret "fluid_to_.*" as a regular expression, because in this case it means that it is looking for the entries that start with "fluid_to_", so that it can change their content to what you defined in the dictionary file. And since they don't already exist in the field files, then they are not applied. Best regards, Bruno
__________________
|
|
December 1, 2017, 19:35 |
snappyHexMesh mutiRegion returning an empty box
|
#18 |
New Member
Patrice Perreault
Join Date: Nov 2017
Posts: 1
Rep Power: 0 |
I have a similar problem: I am looking to mesh the individual layers defining a plate-reactor system: a reacting chamber (2 inlets, 1 outlet), on top of which sits a quartz plate, on top of which sits a empty region to supply heat via 2 inlets/2 outlets, on top of which sits a second quartz plate, and finally a 5 cm high zone to allow natural convection.
The reactingChamber stl file was stitch from various stl files (to account for the inlets, the outlet, and the walls), as the hotAr region (hot Argon flowing to countercurrently to supply heat). I built this case from the snappyMultiRegionHeater tutorial. I execute first blockMesh, then surfaceFeatureExtract, and snappyHexMesh. It seems that everything is going well, but when opening paraView, I only see an empty box (the blockMeshDict geometry, i.e. the box surrounding the whole system). Contrary to the snappyMultiRegionHeater, I don't see the various files (e.g. snappyMultiRegionHeater{bottomAir}.OpenFOAM, etc). See attached for the case, and what goes in the triSurface folder (constant). Thank you so much for your help. cprHeat.zip convectAir.zip reactingChamber.zip |
|
June 19, 2019, 02:17 |
|
#19 |
New Member
arya123xyz
Join Date: Sep 2015
Posts: 4
Rep Power: 10 |
Hi Bruno,
Whether sHM will work without an stl/obj file in triSurface. I need a single box(domain) with refinement inside. So I don't require any object inside the domain. A single domain with inside refinement and highly clustered cells at the centre. Is it possible to do with only refinement box mentioning in snappyHexMeshDict ? When I tried without any object the error was like "Introducing baffles to block off problem cells ---------------------------------------------- #0 Foam::error:rintStack(Foam::Ostream&) at ??:? #1 Foam::sigSegv::sigHandler(int) at ??:? -------------------------- Segmentation fault (core dumped)" |
|
July 23, 2019, 18:39 |
|
#20 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Quick answer @arya123xyz, although a late one: In theory, it should be possible, but:
Code:
checkMesh -allTopology -allGeometry
__________________
|
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[Other] conformed FSI mesh for unstructured fluid region | ashish.svm | OpenFOAM Meshing & Mesh Conversion | 10 | August 2, 2019 08:40 |
[snappyHexMesh] snappyHexMesh does not create any mesh except one for the reference cell | Arman_N | OpenFOAM Meshing & Mesh Conversion | 1 | May 20, 2019 17:16 |
OpenFoam "Permission denied" and "command not found" problems. | iyidaniel@yahoo.co.uk | OpenFOAM Running, Solving & CFD | 11 | January 2, 2018 06:47 |
[blockMesh] Include list of points | Hikachu | OpenFOAM Meshing & Mesh Conversion | 0 | June 20, 2011 09:03 |
Compilation error OF1.5-dev on Suse10.3 | darenyang | OpenFOAM Installation | 0 | April 29, 2009 04:55 |