CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Getting Patches from STL decomposition

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   May 31, 2024, 20:13
Post Getting Patches from STL decomposition
  #1
New Member
 
george
Join Date: Feb 2021
Posts: 16
Rep Power: 5
scfd is on a distinguished road
Hello,

I have a simple multi region heat transfer case such as attached scheme.png file. To define the inlet and outlet patches of the flow channel, I am exporting the mesh as three separate patches: inlet.stl, outlet.stl, and wall.stl. Then, using this command:
Code:
cat inlet.stl outlet.stl wall.stl > MERGE.stl
I obtain an STL file with defined patches. Next, I use snappyHexMesh with the following definitions:
Code:
geometry
{
	MERGE.stl
	{
		type triSurfaceMesh;
		name fluidRegion;
		regions
		{
			inlet {name inlet;}
			outlet {name outlet;}
			wall {name wall;}
			}
		}
};
refinementSurfaces
{
	fluidRegion
	{
		level (1 1);
		regions
		{
			inlet { level (1 1); patchInfo { type patch;}}
			outlet { level (1 1); patchInfo { type patch;}}
			wall { level (3 3); patchInfo { type wall;}}
		}
	}
}
What confuses me is that the inlet, outlet, and wall patches are defined in both the solid region and the fluid region. Ideally, there should be no "wall" patch; only a boundary assigned as mappedWall by OpenFoam. However, I am not sure how to define the inlet and outlet without performing this method. These patches are automatically defined in the constant/polyMesh/boundary, constant/solidregion/polyMesh/boundary, and constant/fluidregion/polyMesh/boundary files. Shouldn't they be defined only for the fluid region? Moreover, when I specify the boundary conditions using wildcards, the "wall" defined as zeroGradient for the solid region is set as "fixedValue" for the fluid region. This doesn't seem physical or correct. The only thing that should be present is mappedWall (fluidregion_to_solidregion etc.).

Code:
//constant/polyMesh
(
    solidboundaries
    {
        type            wall;
    }
    inlet
    {
        type            patch; //why these 3 are here?
    }
    outlet
    {
        type            patch;
    }
    wall
    {
        type            wall;
    }
}
Code:
//solidregion BCs (0/solidregion/T)
boundaryField
{
    wall ??????
    {
        type fixedValue;
        value V;
    }
    solidregion_to_fluidregion
    {
        type            compressible::turbulentTemperatureRadCoupledMixed;
        value           uniform V;
        Tnbr            T;
        kappaMethod     solidThermo;
    }
}
Code:
//fluidregion BCs (0/fluidregion/T)
boundaryField
{
    wall ??????
    {
        type zeroGradient;
    }
    inlet
    {
       bc
    }
    outlet
    {
       bc
    }
    solidregion_to_fluidregion
    {
        type            compressible::turbulentTemperatureRadCoupledMixed;
        value           uniform V;
        Tnbr            T;
        kappaMethod     solidThermo;
    }
}
How can I fix this situation?

Best regards,
scfd
Attached Images
File Type: jpg scheme.jpg (30.1 KB, 5 views)
scfd is offline   Reply With Quote

Old   June 1, 2024, 06:05
Default
  #2
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,236
Rep Power: 29
Yann will become famous soon enoughYann will become famous soon enough
Hello scfd,

You post lack some information, but lets try to clarify:

When meshing a multiregion, we usually follow these steps (let me know if you do things differently):
  1. blockMesh: creates initial background mesh
  2. snappyHexMesh: mesh the geometry using background mesh + STL/OBJ files
  3. splitMeshRegions: split the mesh created by snappy into regions

blockMesh and snappy will write meshes in constant/polyMesh. So after running snappy you get a single mesh containing all your regions in constant/polyMesh. This is why you see all the patches for all regions here.

Then you run splitMeshRegions, which will read constant/polyMesh, split the mesh, create the interfaces between regions (mappedWall) and create new directories containing separate mesh for each region.

In your case, it will write constant/solidRegion/polyMesh to store the solid mesh and constant/fluidRegion/polymesh for the fluid mesh.

constant/polyMesh is useless for your simulation. chtMultiRegionFoam will not use it, it will only look for region meshes in constant/solidRegion and constant/fluidRegion.

For the boundary conditions, you need to defined it in 0/solidRegion and 0/fluidRegion, according to the boundary files located in constant/solidRegion/polyMesh and constant/fluidRegion/polyMesh, respectively.

I hope this helps,
Yann
Yann is offline   Reply With Quote

Old   June 1, 2024, 06:36
Post
  #3
New Member
 
george
Join Date: Feb 2021
Posts: 16
Rep Power: 5
scfd is on a distinguished road
Hi Yann,

Thank you for your quick response. I couldn't explain myself well. The issue here is that even though the STL patches (inlet, outlet, and wall - I'll call it wall_of_fluid to avoid confusion) belong to the fluid region, the wall_of_fluid patch exists in solidregion/polyMesh/boundary. Similarly, why does the boundary condition assigned with ".*" automatically create a bc for wall_of_fluid in both the fluid region and solid region bc dicts? Shouldn't it be only mappedWall?
Code:
0.orig/fluidregion/T:
	"."
	{
		type zeroGradient;
	}
	inlet
	{
		type fixedValue;
	}
	outlet
	{
		type inletOutlet;
	}
	"fluidregion_to_."
	{
		type compressible::turbulentTemperatureRadCoupledMixed;
	}
Code:
0.orig/solidregion/T:
	"."
	{
		type fixedValue;
	}
	"solidregion_to_."
	{
		type compressible::turbulentTemperatureRadCoupledMixed;
	}
These wildcards (".*") create boundary conditions for wall_of_fluid. While that surface is defined as fixedValue in the solid region, it is defined as zeroGradient for the fluid region. What I don't understand is why this happens. This shouldn't happen at all, and the boundary conditions should only be defined as "solidregion_to_fluidregion" and "fluidregion_to_solidregion". I would appreciate it if you could clarify this issue.

On the same surface (even though it has two different names as fluidregion_to_solidregion and wall_of_fluid, the surface is the same), there are zeroGradient, fixedValue, and compressible::turbulentTemperatureRadCoupledMixed boundary conditions. Isn't there something wrong here?

regards
scfd
scfd is offline   Reply With Quote

Old   June 1, 2024, 07:14
Default
  #4
Senior Member
 
Yann
Join Date: Apr 2012
Location: France
Posts: 1,236
Rep Power: 29
Yann will become famous soon enoughYann will become famous soon enough
Alright, have you checked in ParaView to see what is going on and what is this "wall_of_fluid" in your solid region?

Do you get some faces assigned as wall_of fluid and others as fluidRegion_to_solidRegion?


Quote:
Originally Posted by scfd View Post
These wildcards (".*") create boundary conditions for wall_of_fluid. While that surface is defined as fixedValue in the solid region, it is defined as zeroGradient for the fluid region. What I don't understand is why this happens. This shouldn't happen at all, and the boundary conditions should only be defined as "solidregion_to_fluidregion" and "fluidregion_to_solidregion". I would appreciate it if you could clarify this issue.
This is happening because there is an issue in your mesh. The wildcards will assign the boundary condition to all patches in your mesh, then you redefine boundary conditions for inlet, outlet and "fluidRegion_to.*".

Since you have a wall patch which shouldn't exist anymore in your constant/fluidRegion/polyMesh/boundary, it gets the boundary condition defined in the wildcard.

The source of the problem is the mesh not being properly defined, so this is the part you need to fix.

What's the output of splitMeshRegions?

Regards,
Yann
Yann is offline   Reply With Quote

Old   June 1, 2024, 08:00
Post
  #5
New Member
 
george
Join Date: Feb 2021
Posts: 16
Rep Power: 5
scfd is on a distinguished road
In the output of splitMeshRegions, everything is as it should be. I have never encountered something like this before. I feel like if I change my method of creating the inlet and outlet, I might get rid of this issue. I think I need to create only the inlet and outlet without defining wall_of_fluid. For this, I will define inlet.stl and outlet.stl separately in the geometry section and also define fluid.stl as a single piece to create the region. For now, I will continue to investigate. I will update this place once I solve the problem.

Code:
Number of regions:2

Region	Cells
------	-----
0	15840
1	70560

Region	Zone	Name
------	----	----
0	(0)	fluidregion
1	(1)	solidregion

Sizes of interfaces between regions:

Interface	Region	Region	Faces
---------	------	------	-----
0		0	1	11520

Reading volScalarField: cellToRegion
Adding patches
Adding patches

For interface between region fluidregion and solidregionadded patches
    5	fluidregion_to_solidregion
    6	solidregion_to_fluidregion

Region 0
-------- 
Creating mesh for region 0 fluidregion 
Mapping fields
Mapping field cellToRegion
Deleting empty patches
Writing new mesh
Writing addressing to base mesh
Writing map pointRegionAddressing from region0 points back to base mesh.
Writing map faceRegionAddressing from region0 faces back to base mesh.
Writing map cellRegionAddressing from region0 cells back to base mesh.
Writing map boundaryRegionAddressing from region0 boundary back to base mesh.

Region 1
-------- 
Creating mesh for region 1 solidregion
Mapping fields
Mapping field cellToRegion
Deleting empty patches
Writing new mesh
Writing addressing to base mesh
Writing map pointRegionAddressing from region1 points back to base mesh.
Writing map faceRegionAddressing from region1 faces back to base mesh.
Writing map cellRegionAddressing from region1 cells back to base mesh.
Writing map boundaryRegionAddressing from region1 boundary back to base mesh.
End
regards
scfd
scfd is offline   Reply With Quote

Reply

Tags
multiregion, pacth


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem using AMI vinz OpenFOAM Running, Solving & CFD 298 November 13, 2023 09:19
[snappyHexMesh] snappyHexMesh makes too many patches from STL? dbazz OpenFOAM Meshing & Mesh Conversion 4 July 13, 2022 08:54
[surface handling] How to make boundary patches in STL file nzy102 OpenFOAM Meshing & Mesh Conversion 4 January 22, 2018 16:03
Possible bug with stitchMesh and cyclics in OpenFoam Jack001 OpenFOAM Pre-Processing 0 May 21, 2016 09:00
[snappyHexMesh] How to define to right point for locationInMesh Mirage12 OpenFOAM Meshing & Mesh Conversion 7 March 13, 2016 15:07


All times are GMT -4. The time now is 17:10.