Merging two different mesh
 

Dear all,

I was wondering if it is possible to create two different structured mesh with two different blockMeshDict file and then merge them together.

Does anybody know if it is possible to do this?

Best Regards,

Fabio

Sent from my ASUS_X008D using CFD Online Forum mobile app

Thanks for your reply.

For "mastermesh", "slavemesh" do you mean the name of the BlockMeshDict files?

Please let me know,

Regards,

Fabio

Hi,

No. Not the names of the blockMeshDict files.

You need to create the two meshes and then call mergeMesh.

mastermesh should indicate the name/location of the case where the first mesh is located

slavemesh should indicate the name/location of the case where the second mesh is located

Hope this helps.

Cheers,
Antimony

Read this.

http://www.sourceflux.de/blog/genera...snappyhexmesh/

It gives you a visual explanation

Eg: folder named run contains masterMesh and slaveMesh, so type into your terminal

Ciao

Thanks for the very clear explanation.

Best Regards

Fabio

Hi everybody,

actually I am facing the same question. However, getting through mergeMesh, it should not connect the two meshes. So I guess stitchMeshes can maybe do the work but actually I found, that it does not work properly. Imagine you have a block structured mesh (piston + liner) which needs to be merged with the mesh including the valve. How would you proceed? Using ACMI boundary conditions would make the deal here but I don´t want to waste computational costs regarding mapping / interpolation etc.

multiple blocks in Block mesh and then issues with snapyHexMesh
 

Hi all,


I have spent a long time to figure this out and I couldn't.


I have a seven-block mesh and merged common surfaces using mergepatchpairs in the blockMeshDict. checkMesh of this mesh seems fine.


After this step, I position an STL object somewhere in the mesh and run the snappyHexMesh to prepare my mesh.



I get so many warning of this type and usually the meshing fails:


"
FOAM Warning :

From function static Foam::vectorField Foam::snappySnapDriver::calcNearestSurface(bool, const Foam::meshRefinement&, const labelList&, const labelList&, const scalarField&, const indirectPrimitivePatch&, Foam::pointField&, Foam::vectorField&)
in file snappyHexMeshDriver/snappySnapDriver.C at line 2021
For point:3631049 coordinate:(-5.4045 0 -0.445) did not find any surface within:0.0200667 metre.

"


These warning start right after the onset of mesh morphing and the coordinates given in the warning are the location of merged patches.

The problem was not the mesh, it was a snapControls parameter named:



nFeatureSnapIter


which was causing the issue. I commented this it out and the problem was resolved.




version OpenFOAM 1912.

Merge one mesh into another in OpenFOAM
 

Hi Tobias


Did you address the issue? I'm facing the same problem.

My calculation domain is quite large and importing stl files directly into the large domain can lead to poor model accuracy. And also, building the model in a small domain and then importing it to the large domain (using mergeMesh) will cause a huge computational cost in interpolation, similar to the overset method. I'm wondering if it's possible to somehow build the model in the small domain and then import it into the large domain, but the two domains are fully merged with no overlap. MergeMeshes, StitchMesh, SubsetMesh and snappyHexMesh on't seem to work.


Do you have any suggestions for this?


Best regards,


Tianyuan

Hi,


well yes partially:

ESI-OpenCFD Version


- Potentially merging the different meshes with cyclicAMI on cost of interpolation. I guess the interpolation does not necessarly increase the computational cost drastically as I was thinking at the beginning. It depends on the number of faces one needs to interpolate. Furthermore, based on the face-to-face area ratio, the interpolation might lead to high or lower accuracy (not investigated).

- Here, the mayor slowdown might come from the `explicit` coupled regions (cyclicAMI) which should increase the pressure iterations (potentially the V-cyclces)
- However, ideally one could use the conservative AMI which lead to almost no interpolation inaccuary but its only possible with transient solvers that call mesh.update(). Furthermore, the ESI-OpenCFD version has a big problem with dynamic meshes in general (I made some profiling here). Since a lot of things are cleared out in each time-step (such as agglomeration table and others), things get really slow compared to staticFvMesh scenarios

cfd.direct Version
- Potentially, using the conservative AMI as well. The major difference should be the fact that here, we really change the mesh in terms of topology. This however, should enable stitchMesh to get ready to connect both regions (not tested). Side note: ESI-OpenCFD version uses some halo faces for the conservative AMI hence, no change in the topology of the mesh


Other than that, no idea at the moment.
Tobi