[antonessiu]

Good year everybody,
sorry for my bad english...

I successfully meshed a multi domain with Fluent 13 mesher and then used it in OF1.7.1, but, i love open source then I am looking toward the capabilities of snappyHexMesh in multi doamin meshing.

The geometry is very simple, an heated pipe and a cold fluid through it.

I have follow this steps for case setup (reported in past post) based on
snappyMultiReginHeater tutorial (in OF-1.7.1)

1) copy the case dir in the working folder.
2) modify the blockMeshDict (whole domain)
3) replace the stl files by SOLIDO.stl and FLUIDO.stl. stl files are obtain by exporting SALOME geom.
4) modify the regionProperties.
5) modify the snappyHexMeshDict to fit the new stl files.

When I launch SHM the background mesh don't diasappear and it creates a domain0, SOLIDO and FLUIDO mesh.

I have read thousand post and i:
-modify the locationInMesh (pointed in FLUIDO, SOLIDO and domain0)
-increase background mesh quality
- etc ..
but without success!!!!

PLEASE HELP ME!!!

Do you know how to delete the domain0 mesh?

Thanks

[antonessiu]

i have increase the stl quality with solid works 2007 but the problem persist ......
anybody has similar problem ?

Help me!!!

[wyldckat]

Greetings Antonello,

Attached is your case fixed to eliminate the "domain0" zone. I had to look into the tutorial case and noticed that the "snappyMultiRegionHeater" case has a tight wrap of the "blockMeshDict" over the STL files, which explains why you were having this problem with "domain0".
I've used OpenFOAM 2.1.x, but I think the changes I've made should work in 1.7.1 as well.

Basically, the fixes were:

• Had to fix several files in "0" where "MaxX" was defined as "nonuniform" and defined it as "uniform".
• Had to add two options to "snappyHexMeshDict" for working in OpenFOAM 2.1.x.
• Used setSet to define a cell set that only included the desired mesh zones:

  setSet -batch batch.setSet

  Where "batch.setSet" has this inside:

  cellSet isolation new zoneToCell SOLIDO
  cellSet isolation add zoneToCell FLUIDO
  cellSet isolation subset

• Then write only this cellSet has the whole mesh

  subsetMesh -overwrite isolation

• Then it's business as usual with splitMeshRegions.

Best regards,
Bruno

[antonessiu]

Dear Bruno,
Thank you so much for your help!
This is the strength of the Forum !!!!!
Finally I created the mesh i wish and works!

I hope that this answer can help many peolple!!!!
Now i can study deeply snappyHexMesh functionality
Thank you so much again!

[kalyangoparaju]

Bruno,

Should this procedure be followed always if we want a multi region mesh? I have 3 different closed stls which make the inlet, porous and outlet of a pipe. When I mesh, I have all the regions ( like antonnio had). I exactly did what you said and it did help to an extent but not exactly.

I was actually wondering, instead of going through all this, isn't it easy to just build a single mesh with a single stl file and then split the regions using setSet command (cellZone using boxToCell) and assign them to what ever regions I want ? this works perfectly for a mesh imported from fluent and i am trying to do it for a mesh built in SHM.

let me know what you think

Kalyan

[wyldckat]

Greetings Kalyan,

Originally Posted by kalyangoparaju

Should this procedure be followed always if we want a multi region mesh? I have 3 different closed stls which make the inlet, porous and outlet of a pipe. When I mesh, I have all the regions ( like antonnio had). I exactly did what you said and it did help to an extent but not exactly.

There should always be more than one way to do anything... question is if it's the way you're looking for

Originally Posted by kalyangoparaju

I was actually wondering, instead of going through all this, isn't it easy to just build a single mesh with a single stl file and then split the regions using setSet command (cellZone using boxToCell) and assign them to what ever regions I want ? this works perfectly for a mesh imported from fluent and i am trying to do it for a mesh built in SHM.

I'm not sure I understand you, but the missing info I'm seeing from your description is:

1. If the STL is closed between zones, then the mesh can only be done in a single go if you tell sHM to allow multiple zones AND properly tag them in the dictionary. Check the dict for tutorial in question.
2. If you try to use the "boxToCell" cellZone, then your geometries must be perfect parallelepipedic shapes. Otherwise, you are going to be selecting one too many or too few cells that lie on a curved surface.

Best regards,
Bruno

[kalyangoparaju]

Bruno,

Now that I have your attention, I will try to explain my problem.

When I have 3 closed stls and I put them in triSurface and run snappy, there is a particular line in the output which says walking through the faceZones and finally it creates a mesh both inside and outside the tube ! I thought this is the way snappy works for multi regions but now I have to figure out a way to say snappy that the tube boundaries ( i mean the circumference wall) are not faceZones which you want to walk through but rather the front and the back of each of stls are faceZones which you MUST go through.

The problem comes when I define the surface of the stl as a faceZone in snappy something like below

geometry

{

porous.stl

{
type triSurfaceMesh;
name porous;

{
regions
{
front;
{
name front_surface
}}
......
.....
.....
....
refinementSurfaces
{
porous
{
levels (1 2);
//faceZone porous; // commenting out so that it doesn't take the whole stl as faceZone
cellZone porous;// for assigning values in porousZones
cellZoneInside inside;
regions
{
front_surface
{
levels (1 2);
faceZone front_surface; // So that it takes this surface as a faceZone and walks through to build a mesh , theoretically
}}}
...
..
..
..

And as expected, this doesn't work. When I have this style of writing the Dict, only the region in which the locationInMesh point is present is being meshed and rest of it is not.

How exactly do I go about solving the problem. I hope I was sorta clear.

Also, yes I agree with you regarding the boxToCell thing. Fortunately, I am ok with that now. But unfortunately, the cells are mid way at the cutting points and hence it is not exactly the point rather 1-2 cells layers ahead or behind.

I hope you have an answer :-)

Kalyan

[kalyangoparaju]

Bruno,

Specifically,this is what is happening


multi_region_mesh.jpg

The mesh is supposed to be inside the octagon, but it ends up being everywhere. The pic shows the 3 stls. You can see the higher density near the interface.

Kalyan

[wyldckat]

Hi Kalyan,

Mmm... I'm not managing to understand you correctly from your description. I have two requests to help understand the problem better:

1. A schematic drawing or draw directly in that picture you attached, the zones you want to get in the end.
2. Any chance you can share a simpler version of this geometry? This way it would be easier to check things for myself, the same way I did for the original poster!

Best regards,
Bruno

[kalyangoparaju]

Bruno,

Here is another picture ( edited in MS paint ;-) )

The arrow indicates the direction of flow. The geometry, I think, is pretty easy to understand. It has walls everywhere.. completely closed ( except inlet and outlet) and the central rectangular zone is supposed to be the porousZone.

Untitled.jpg

For this, I made 3 stl's. The inlet stl, porous stl and the outlet stl with their respectively blocks as seen in the figure and red rectangle is the worst possible representation of the blockMesh which I put it around this geometry.

Since its 3 stls, all of them are closed ( which is required for meshing). And the rest of it is what I tried to explain in the previous post. I put in all the 3 stls in the snappyHexMesh dict and gave a location in mesh which is around the center of the porousZone. As is in the ChtMultiRegion tutorial, I defined the stls as faceZone and cellZone. When snappy runs, it walks from this point in mesh through the faceZones ( this is what it exactly says in the output) and meshes everywhere inside and also outside the geometry. A slice of which I attached to the previous post.

Today, I tried a different way of doing this. I made 3 case directories for each of these geometries and meshed them individually using SHM. Then I used mergeMeshes to get them together. Till here it was awesome, but when I tried using stitchMesh so that the patches which are now merged together and are in form patch turn to interior faces, the utility stops saying duplicate point found. I don't seem to understand the error.

I know I am jumping between 2 methods but I would glad if you can atleast help with solving one of those.

Thanks,
Kalyan Goparaju

PS - The way you help people in this forum is absolutely terrific :-)

[wyldckat]

Hi Kalyan,

Without an example case, I'm unable to test it. Either way, I've picked up on this post which should help you a lot:

Originally Posted by elvis

there is a brilliant tutorial (download and untar it "tar -xzf ") I believe it will guide you throught most of your SHM questions

The full link to where the tutorial is: http://www.openfoamworkshop.org/2012...enedeVilliers/

Best regards,
Bruno

[kalyangoparaju]

Thanks a lot bruno. That was indeed a fantastic presentation. It definitely helped me sort out my issue but not the way I wanted it to.

The work around I have is, I merged all the stls into 1 stl and am meshing it and then creating the zones using setSet. I still haven't figured out how to mesh multiple stls for internal flow :-(

Kalyan

[SeMar]

Sorry for warming up an old thread.
This one helped me a lot in setting up a multi region mesh. Now I have the geometry I wanted.
What is still missing is the assignment of patches to the geometry for boundary conditions. After the given process (as in wyldckat's post #3) all the patches I defined earlier in the stl files are gone.
Is there a possibility to get the multiregionmesh and keep the patchnames?

[wyldckat]

Greetings SeMar and welcome to the forum!

Mmm... good question! Unfortunately without an example to work with, I'm only able to provide ideas:

• With the application createPatch is probably the only way you can recreate them. You can find several examples by running the following commands:
  

  find $FOAM_UTILITIES -name createPatchDict
  find $FOAM_TUTORIALS -name createPatchDict

• Almost all use sets as references for the patches one wants to create. Which implies that you should also isolate the respective face sets for each patch.

Best regards,
Bruno

[SeMar]

Hello Bruno,

I managed to build an example case. The actual geometry is a litte bit more complicated, so I'd like to avoid defining patches with simple geometric shapes. Also cutting the geometry with the backgrondmesh from blockMesh as you did in the first example is not working with the actual geometry.
The essence of the case is to simulate a buoyant airflow over a solid region, which is getting warmer. The inlet is at the top of the cavity, the outlet at the bottom. The sidesurfaces are walls. In the center of the cavitiy (oven) a solid hexaeder is placed.

Im attaching the example case, derived from

$FOAM_TUTORIALS/heatTrasfer/chtMultiRegionFoam/snappyMultiRegionHeater/

and modified with your instructions from post #3

Best regards

Sebastian

snappy_oven.zip

[wyldckat]

Hi Sebastian,

I finally managed to look into this. Apparently there isn't an easy way in snappy to preserve the patches, because they are inside the mesh, which would result in internal patches and those are not allowed in OpenFOAM. "faceZones" option would be nice for each surface, but I couldn't figure out if and how they were supported...

Anyway, the trick is to use surfaceToPatch for recreating the desired patches!

The following code is an excerpt of the modified Allrun script:

# Yes, we also should remove 0, to avoid contamination
rm -rf constant/polyMesh/sets 0

runApplication blockMesh

#runApplication surfaceFeatureExtract -includedAngle 150 constant/triSurface/oven.stl oven
#mv log.surfaceFeatureExtract log.surfaceFeatureExtract.ofen
#runApplication surfaceFeatureExtract -includedAngle 150 constant/triSurface/hexaeder.stl hexaeder
#mv log.surfaceFeatureExtract log.surfaceFeatureExtract.pizza

runApplication snappyHexMesh -overwrite

#Take out the unwanted regions
runApplication setSet -batch batch.setSet -constant
runApplication subsetMesh -overwrite wholeOven

#With the mesh recomposed to it's natural structure, redefine the patches again from STL
runApplication surfaceToPatch constant/triSurface/oven.stl

#Move the new mesh back to the constant folder... there isn't an -overwrite for surfaceToPatch
mv 0.001/polyMesh/* constant/polyMesh/

#clean up the time folders
rm -r 0 0.001

#copy back the base fields
cp -r 0.org 0

#split the mesh into the desired regions
runApplication splitMeshRegions -cellZones -overwrite

Now, this excerpt assumes that the following steps have been done prior to running this new Allrun (you only have to do these once for the new script):

1. Move the folder "0" to "0.org":
   

   mv 0 0.org

2. Remove unnecessary files:
   

   rm 0.org/*Level 0.org/cc*

And I think that's it!


I haven't attached the fully modified Allrun script just out of laziness


Best regards,
Bruno

[GRAUPS]

Bruno,

First of all, thank you for all the help you provide within the CFD Online threads. I have a case that I am trying to mesh that is very similar to Kalyan's internal flow case from post #10. My case is a cylinder with an inlet region, outlet region, and porous region in the middle. I used three closed stl files to define it.

After meshing, including layer addition, I wish to be able to keep the interfaces between the meshed internal zones as faceZones, that is the main goal. However, it seems like I'm having similar issues as Kalyan had, where it is not crossing over the faceZones correctly and instead of keeping the internal mesh for internal flow and the intersections as faceZones, it meshes the outside domain and only part of the cylinder.

After reading through the above posts, I know my case is similar but not exactly the same and have been unable to determine a course of action. I'm including my case with this post in the hopes it will help find a solution. I'm using OF 2.1.1. Let me know if you need any further info from me.

cylinder_cfd.zip

Thanks!

EDIT: I've updated the zip a couple times since my first post to clean some things up.

[wyldckat]

Greetings Brock,

I've taken a look at your case, but I don't have the time to test the following suggestion:

1. Several hours ago I gave some help with a similar issue here: http://www.cfd-online.com/Forums/ope...tml#post392838
   In that case, the "faceZones" were actually converted to baffles, which you don't need. But the trick I suggested there was to do the mesh in two passes. This trick you will also probably need to apply in your case!
2. So, the suggestion is as follows (based on the case in the link above):
   1. First mesh the cylinder and ignore the desired face and cell zones.
   2. On a second pass, use only the snapping capabilities and use the porous cylinder only for selecting the porous zones.
   3. Then try using topoSet or setSet for selecting and create/rename the porous "faceZones" on each side to the desired "faceZone" names.
3. Either way, it's a matter of playing with the ability to use snappyHexMesh for snapping to "faceZones", without the need to create the respective "cellZones"... but the opposite isn't true, namely it's not possible to create "cellZones" without "faceZones", at least according to the tests I've made.

Best regards and good luck!
Bruno

[GRAUPS]

Originally Posted by wyldckat

So, the suggestion is as follows (based on the case in the link above):
First mesh the cylinder and ignore the desired face and cell zones.
On a second pass, use only the snapping capabilities and use the porous cylinder only for selecting the porous zones.
Then try using topoSet or setSet for selecting and create/rename the porous "faceZones" on each side to the desired "faceZone" names.

Hmmm... this is an intriguing suggestion that just might work, because the second time around your feeding it only the cyclinder (in my case) as the domain instead of an outside block created by blockmesh. As long as this...

Originally Posted by wyldckat

This means that we can try and model mesh with snappyHexMesh, at least in an attempt to force certain faces to be along a ghostly geometry

... remains true, your suggestion should work. Thanks for the suggestion, I'll give this a try hopefully in the next week and post back my results.

Originally Posted by wyldckat

Either way, it's a matter of playing with the ability to use snappyHexMesh for snapping to "faceZones", without the need to create the respective "cellZones"... but the opposite isn't true, namely it's not possible to create "cellZones" without "faceZones", at least according to the tests I've made.

It's really too bad that you can't drill down and define faceZones at the region (or solid) level as opposed to the stl level. This would solve everyone's problems!

[wyldckat]

Originally Posted by GRAUPS

It's really too bad that you can't drill down and define faceZones at the region (or solid) level as opposed to the stl level. This would solve everyone's problems!

I'm not sure I understand your statement, but perhaps this might do what you want:

1. Use setSet or topoSet to select the faceSets where you want to have "faceZones".
2. Use setsToZones for converting from sets to zones

I didn't mention this before because this only works well when we have orthogonal and uniform meshes, at least in a way that we can easily select the faces using a box selection.
An example of this kind of faceSet selection I made just the other day... here: http://www.cfd-online.com/Forums/ope...tml#post392721