CFD Online Discussion Forums - [snappyHexMesh] Using snappyHexMesh to create a multi-region mesh for a whole building

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)

- - [snappyHexMesh] Using snappyHexMesh to create a multi-region mesh for a whole building (https://www.cfd-online.com/Forums/openfoam-meshing/134237-using-snappyhexmesh-create-multi-region-mesh-whole-building.html)

Using snappyHexMesh to create a multi-region mesh for a whole building

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!

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:

Multi-region meshing with snappyHexMesh requires that each region is defined in a single STL file.
Each region is if as it was a box without secret compartments. This box I'm referring to could be be a cube, a sphere or the inside of a really complex room.
Each STL file must have a "faceZone" and a "cellZone" associated to it, which is defined in "castellatedMeshControls.refinementSurfaces" for each STL.

Now, your STL files are not following properly these references. For example:

The files "block*.stl" and "top*.stl" have geometries that are repeated inside the file "dentro.stl"...
... This is bad, because this means that the file "dentro.stl" is not a single geometry. Worse even, is that this file is containing both the inside of the room and the floor.
The geometry "door.stl" is repeated in the files "fora.stl" and "dentro.stl". This cannot be.

How to fix this? Well, to begin with, you should not have gone head first into solving your target case. You should have started with a smaller example and then gradually increase the geometrical complexity. Something like an outer box and an inner box would have been a simple and perfect example and you would have solved this issue a lot sooner... specially because you wouldn't have had to worry much about mesh refinement...

Anyway, to solve this, you need to:

Separate all boxes into their own STL files. This also goes for the floor box that is in the "dentro.stl" file.
No box should be repeated in any other STL file.
Surfaces that connect each box should be present in their respective boxes.
If the space between the outside wall and the inside wall is also meant to be meshed, then you need an STL file for it as well. It's sort-of like a donut-shaped box.

Once you have one STL per box, you can now use the settings you already have in your file, for example:

Code:

        top1

        {

             level (4 4);

             cellZone top1;

             faceZone top1; 

             cellZoneInside inside;

        }

Now, there's the other complicated part: refinement levels. Once you have followed the steps above, it'll be easier to help you with the refinement levels, if you provide the updated case.

Best regards,
Bruno

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

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

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:

Originally Posted by lramutti (Post 488423)

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.

Generating meshes can get seriously complicated, proportionally to the level of detail in the geometries. Therefore, the models that come from CAD software usually have to be further manipulated with another tool, in order to make the geometry suitable for meshing.
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:

Originally Posted by lramutti (Post 488423)

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

When generating multi-region meshes, the "point inside" isn't very important, because everything will get meshed, both inside and outside.

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

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:

The geometries represented by the STLs named "block*", what purpose do they have?
Are they meant to be made of bricks, are they made of air, which windows on each side, or are they meant to act as permanently open tunnels?
The same questions applies to the "top*" and "door" STL files.
How many regions is your simulation meant to have? In other words:
1. Is the air meant to be exchanged between the outside and the inside?
2. Is heat meant to be exchanged directly through the walls of the building?
What software are you using to create these final STL files?
Or better yet, are you using Solidworks to export one STL file/surface at a time and then manually merging/editing the files (perhaps with a text editor)?
Can you use SketchUp, Blender and/or Meshlab?

Best regards,
Bruno

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

This same approach was taken for both dentro and fora.stl's.

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.

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:

Make sure you check the "Use VTKPolyhedron" check box for the ".OpenFOAM" file.
Then apply the "Extract cells by region" filter.

And example of this is shown in this post: http://www.cfd-online.com/Forums/ope...tml#post372605 post #6

Quote:

Originally Posted by lramutti (Post 488752)

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?

Multi-region meshing does this, it allows us to mesh everything, both inside and outside. The problem is how to make sure the cell zones are assigned the way we want them to be assigned. Worst even is when there are leaks, as this might lead snappyHexMesh to twist cell's faces the wrong way :(

Quote:

Originally Posted by lramutti (Post 488752)

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

OK, given that repairing the STL files to fix the leaks is not possible in the short term, then my suggestion then is to rely on a two pass meshing procedure:

For the first pass:
1. You will have a base mesh created with blockMesh, that is tightly bound to the outside simulation. In other words, it's what you already have, but the idea is to make sure that the base mesh covers the whole simulation volume, so that additional/non-essential cutting is not required. At least as a first approach to this problem.
  Note: this means that for a first approach, the building foundation is not meant to be meshed. Once things are working, you can then upgrade the complexity of the case.
2. Instead of defining all blocks for this first mesh with snappyHexMesh, define only:
  1. A single STL file that only has all of the geometry of the walls. In other words, it contains almost all of the surfaces from both "dentro.stl" and "fora.stl", except it does not contain the surfaces that plug the holes, i.e. windows and doors. The objective is to have only the walls+bricks themselves, letting the air flow freely from the inside to the outside of the building and vice versa.
  2. Since you might want to assign specific patch names to the floors, have a separate STL file that has only the inside floor. Hopefully this will assign the patch names, without damaging the meshing process.
3. The result of this mesh is simple: you will have 2 regions, where the 1st region is air and the second region are the walls.
4. Honestly, I would then try to do some simulation tests, by assigning temperature to the outside walls of the building (as if it was the effect of the sun on the walls) and to make the air come from the outer patches of the mesh, namely the ones that are originally part of the base mesh.
The second pass:
1. After the first mesh is done, we need to assign more regions, namely the tunnel-like openings. This means that you'll need those individual STL files, namely the blocks and tops.
2. This second pass should only include these necessary STL files, which means you should use a second dictionary file. For example, you can run snappyHexMesh like this:
  
  Code:
  
  snappyHexMesh -dict snappyHexMeshDict.secondpass

Keep in mind that for simulating, you will need to go through the same/similar steps as given in the tutorial "mesh/snappyHexMesh/snappyMultiRegionHeater".

Quote:

Originally Posted by lramutti (Post 488752)

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).

Regarding the solid regions: the way I see it, you only need 1 or 3 regions; for example, one for the walls as a single region and then 2 more for the building foundation and for the terrain outside. Keep in mind that a region is a volume and a patch is a surface; which means that each region can have several patches, for example you will have the inside north patch and the outside north patch.

In case you do want more solid regions, please postpone their creation to after you've mastered the basics.

Quote:

Originally Posted by lramutti (Post 488752)

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.

Mmm... I hope you know the material properties of the bricks and walls.

Quote:

Originally Posted by lramutti (Post 488752)

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

This same approach was taken for both dentro and fora.stl's.

OK, understood. Should work without problems.

Quote:

Originally Posted by lramutti (Post 488752)

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 know the feeling. SketchUp is pretty neat for sketching, problem is being accurate where the points truly are... there have been many times that I had to remove points and draw things again, for them to be perfectly in place.
I'm not familiar with Rhino and Cinema4d, but if they are similar to Blender, then they should have powerful surface meshing capabilities.

Quote:

Originally Posted by lramutti (Post 488752)

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.

I did try Meshlab with your geometry as well on Linux and it crashed when I tried to plug holes...

This 2 pass meshing strategy should do the trick, at least with the current features you have.

Best regards,
Bruno

Hey Bruno,

Thanks for the input. I will take it into consideration.

Cheers!

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

Cheers

Lucas

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

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

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

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

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

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

               }

However, I have noticed this command is not appearing in the 0 folder for some strange reason but the code is working fine. How could there be a a communication between the solid and fluid domain if the mentioned command is not appearing in the 0 folder? Should I ignore this problem?

Cheers

Lucas

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

Always keep in mind that most of OpenFOAM's applications have a "-help" option ;) It might not give detailed help, but it does give some information...

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

snappyHexMesh mutiRegion returning an empty box

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.

Attachment 59909

Attachment 59910

Attachment 59911

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)"

Quick answer @arya123xyz, although a late one: In theory, it should be possible, but:

You must turn off snap and layer phases at the start of the "snappyHexMesh" file.
You need to at least add a geometrical searchable box in the "geometry" bracket-block.
You need to also add it to the refinement regions section of the dictionary.

Beyond this, it's possible that the mesh you have before running snappyHexMesh might not be valid. Run:

Code:

checkMesh -allTopology -allGeometry

to check what it tells you.