[AtoHM]

Hello!
I am working on a simulation with multiple regions. I have a stationary and several moving frames. I created the meshes separately.
I successfully merged the meshes and I can also run my simulation as desired. So my "problem" is more of the academic type.
After merging the meshes, the regions are addressible by names "region0", "region1", ... and so on.

I was wondering if there is a way to give them more descriptive names. Upon searching for it, I found that I could probably use topoSet > setSet, but I need to provide a point inside. My aim is however, to name these regions before I perform mergeMesh. At this stage there is only one region per mesh and I can just do "rename region0 to <my_fancy_name>". This would - ideally - not include any manual input, as there can be no confusion as to what belongs to the region and what does not. I want to streamline this process by scripting, therefore the manual input of coordinates is an obstacle.
Happy for any suggestions, thanks!

[Yann]

Hi AtoHM!

I am not sure which solver you are using. Correct me if I am wrong but I guess regions names correspond to cellZones?

If yes, does mergeMeshes preserve cellZones?

If it does, then you can probably name your regions when meshing, by defining the region name either in blockMeshDict or in snappyHexMeshDict.
If mergeMeshes looses cellZones, the only way is to name the regions after merging meshes. There might be a clever way to use topoSet to avoid manual inputs, but I agree with you it would be easier to get the proper names right from start.

Let me know what you think,
Yann

[AtoHM]

Thanks for your time Yann!


This is independend of the solver I guess. Using an in-house solver for the simulation.
The mentioned regions are not really cellZones from what I understand. Each one just refers to a single mesh that was created in one mesh case.
After mergeMesh, the regions can be exposed by running checkMesh. It writes a file called "cellToRegion".
checkMesh output looks like this

*Number of regions: 4
    The mesh has multiple regions which are not connected by any face.
  <<Writing region information to "3/cellToRegion"
  <<Writing region 0 with 1245633 cells to cellSet region0
  <<Writing region 1 with 343845 cells to cellSet region1
  <<Writing region 2 with 343845 cells to cellSet region2
  <<Writing region 3 with 343845 cells to cellSet region3

After I read your comment I felt dumb for a moment - providing a name in SHM seems obvious, I thought I missed it. But actually I gave a name which does not correspond to the "region0" ... descriptions.

The "cellToRegion" file just holds an integer for each cell: 0 -> belongs to region0, 1 -> belongs to region1 and so on. I don't know how to use that file.
I will dig deeper on the naming in sHM.
Thanks!

[Yann]

OK, it seems checkMesh assigns your regions to cellSets.
If this is just a matter of being able to identify parts corresponding to each regions, I guess you can use either cellSets or cellZones.

Where do you need the information? Is it only about checkMesh or you also get those names elsewhere for post-processsing?

Originally Posted by AtoHM

After I read your comment I felt dumb for a moment - providing a name in SHM seems obvious, I thought I missed it. But actually I gave a name which does not correspond to the "region0" ... descriptions.

How do you define this name in SHM?

Since checkMesh creates the sets, the easy thing would be to just use topoSet to rename the sets, but the tricky part is to know which sets correspond to which name without manual intervention. I am not sure how to achieve this...

Another way, as you said in your first post, would be to use topoSet with the regionToCell source to reproduce what checkMesh does. As you said, you need an insidePoint, but can't you automatically retrieve it by looking for the locationInMesh point in the snappyHexMeshDict of the corresponding region? This could be scriptable, as long as you use SHM to mesh all your regions.

No real solution, just ideas and questions!

[AtoHM]

Ah I missed, checkMesh actually creates the sets as well, not just the cellToRegion file. But as pointed out, that does not really help here.


I want the regions have some reasonable naming when later I assign rotating motion using MRFOptions or dynamicMeshDict. Right now they depend on the sequence of mergeMesh operations I use.


I use the following layout in sHMDict to assign the name

geometry
{
    geometry.stl
    {
        type triSurfaceMesh;
        name geometry;
        regions {
            ....
        }
     }
}

It appears that "geometry" name stays local to snappy and is not carried through. On the other hand, I used that syntax for all mesh cases. Now when merging, maybe mergeMesh recognizes that and avoids clashing names by using these default descriptions.
// I will try to create a cellZoneInside in surfaceRefinement for my geometry.stl. Lets see how that works out



Getting the locInMesh for each case might work in some cases, good idea. Unfortunately, as you might noticed, 2 of the meshes are just a translated copy of the region1. If I looked up locationInMesh from that case, it would be wrong, because the mesh was translated.
This is way more complicated than it should be

[Yann]

Hi AtoHM,

How do you define your regions in dynamicMeshDict?
I usually work with cellZones, so I define my cellZones names right in snappyHexMesh using this syntax:

    refinementSurfaces
    {
        geometry
        {
            level (2 2);

            cellZone myZoneName;
            cellZoneInside inside;
	}
    }

That being said, for my applications I usually just mesh my whole geometry at once and I don't use mergeMeshes so I am not sure whether mergeMeshes preserve the cellZones or not.
I may have come to a similar issue when dealing with overset meshes and I think I remember loosing the cellZones after merging the meshes so I had to recreate it with topoSet after merging...

Originally Posted by AtoHM

I use the following layout in sHMDict to assign the name

geometry
{
    geometry.stl
    {
        type triSurfaceMesh;
        name geometry;
        regions {
            ....
        }
     }
}

It appears that "geometry" name stays local to snappy and is not carried through. On the other hand, I used that syntax for all mesh cases. Now when merging, maybe mergeMesh recognizes that and avoids clashing names by using these default descriptions.

There are some ambiguities with the naming convention in snappyHexMeshDict. The name you define here is the name of the surface of your geometry. This name is used to name the patches created during the mesh, but it does not have any effect on the internal mesh, which does not have any name. Same goes with the "regions" section underneath: it refers to the named surfaces which might be contained in the STL file, not to regions as a volume in your geometry.

[AtoHM]

Hi Yann,


I use it in dynamicMeshDict similar to here: https://github.com/OpenFOAM/OpenFOAM...ynamicMeshDict
Where instead of passing an arbitrary cellZone-name, it also permits to use "region0", "region1", and so on. The simulation runs fine.


I'm currently trying with the cellZone definition in refinementSurfaces as you suggested. As I have only one region per mesh, I am not yet certain if it has any effect. I have to fix a quality issue in the mesh first, then I will check if after mergeMesh, the given name is used instead of "region0".
I will check if the cellZones are preserved.

[AtoHM]

Ok, I found a way to do it using topoSet without supplying a location.


As I pointed out, mergeMesh carries along the association of cells to the regions (regionToCell file). After using mergeMesh, one can use checkMesh which writes out polyMesh/sets/region* files.

Then, since I know in the script which sequence I used for merging (I know which regions corresponds to which mesh or body), I can produce automatically a topoSetDict which creates cellZones with my desired names:

    {
        action  new;
        type    cellZoneSet;
        name    Tank;
        source  setToCellZone;
        set     region0;
    }

Thats basically what I was looking for, although slightly more complicated.