CFD Online Discussion Forums - [mesh manipulation] Create patches from a very complex geometry

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

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

- - [mesh manipulation] Create patches from a very complex geometry (https://www.cfd-online.com/Forums/openfoam-meshing/146854-create-patches-very-complex-geometry.html)

Create patches from a very complex geometry

Hello everybody,

I am wondering if it is possible to create patches and different region automatically from a .stl file.

For a simple geometry I tried to isolate the faces belonged to the different regions I'd like to have in the .stl file manually. It works perfectly ;)
But now I have a very complex geometry, isolating the region is impossible by hand.

AutoPatch doesn't work, because it isolates some single points as a region (the mesh is not perfect) or the whole geometry, depending on the angle.

I know I could do it with the tool createPatches or making different blockMesh regions for each patch.

Does anyone knows the best option?? :confused:

Thanks in avdance for the help,

Julie

Have you tried surfaceToPatch? With this tool you can identify faces close to a stl surface and automatically create a path out of them.

Cheers

Fabian

Hey Fabian,

thank you a lot for your reply :)

I've tried, but I got this error:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Reading surface from "pipe.stl" ...
Patching all boundary faces according to nearest surface triangle ...
All boundary faces further away than 0.001 of mesh bounding box (-0.04 -0.2 -0.15) (0.04 0.04 0.2) will keep their patch label ...
Before patching:
patch size
defaultFaces 34385

--> FOAM FATAL ERROR:
Cannnot read "pipe.stl"

From function triSurface::read(const fileName&, const word&, const bool)
in file triSurface/triSurface.C at line 369.

FOAM exiting

I should apply surfaceToPatch after snappyHexMesh, right?

Thanks in advance for the help,
greetings

Julie

check the tutorials

When you're using snappy you can follow the chtMultiRegionFoam tutorials. They describe how to produce a multi region mesh with snappy. The basic work flow is the following:

Create a single region mesh with cellZone for each region you want to create
Run splitMeshRegions on the mesh (this will create the multi region mesh)
Run changeDictionary to set the initial and boundary conditions for the regions
Run the case

Cheers

Fabian

splitMeshRegions patch naming convention

Hi foamers,
I don't know if the following is offtopic in this thread. If it is, I hope the moderator will move my post in a more suitable place.

I'm trying to set up a case similar to snappyMultiregionHeater. In my case there are three physical regions called "aria", "acqua" and "tubo_alettato" like in the attached pictures.
Similarly to the tutorial case the regions are coming from cellZones previously defined in SHMdict file.
When it comes the turn of "splitMeshRegions -cellZones" I got this a different behaviour in the interface patches naming scheme compared to the log of splitMeshRegions in snappyMultiregionHeater:

Code:

Adding patches



For interface between region domain0 and acqua added patches

    29        domain0_to_acqua

    30        acqua_to_domain0

For interface between region domain0 and aria added patches

    31        domain0_to_aria

    32        aria_to_domain0

For interface between region tubo_alettato and acqua added patches

    17        tubo_alettato_to_acqua

    18        tubo_alettato_to_acqua_slave

For interface between region aria and tubo_alettato added patches

    1        aria_to_tubo_alettato

    2        aria_to_tubo_alettato_slave

For interface between region domain0 and tubo_alettato added patches

    33        domain0_to_tubo_alettato

    34        tubo_alettato_to_domain0

i.e.: sometimes the rule patch1_to_patch2 in region "A" does not become patch2_to_patch1 in region B. Instead it becomes patch1_to_patch2_slave.
This would be an irrelevant matter if I had not already set up many other dictionaries following the scheme of mesh splitting snappyMultiregionHeater case.

Does anybody have an idea of the above behavior?
Thanks to every reader.

Gianluca