[hajott]

Hello,
I am setting up a multiRegion case similar to the multiRegionHeater tutorial for chtMultiRegionFoam (OF2.3).
But I am creating the individual regions separately with blockMesh and cannot use splitMeshRegions as it is done in the tutorial.

The faces of the coupled patches are congruent, and I know which face on one side is coupled to which face on the other side of each patch. I have to construct the files constant/<regionx>/polyMesh/{point,face,cell,boundary}RegionAddressing.

Is there any documentation about the format of these files?
Or a description, how I can generate them, knowing the patch-to-patch coupling?

Thank you
Hajo

[derekm]

Look at the heat exchanger tutorial

[hajott]

Thank you for suggesting the heatExchanger tutorial.

However, this tutorial first splits the mesh into rotor blades and surrounding air and then uses "createBaffles" to define interfaces on the internal patches.

I have two separate meshes, which touch at one (or more) common patches. I don't see, how I can apply createBaffles on these two meshes, where the patches to be connected are boundary patches to the two individual meshes.

[thiagopl]

Hi hajott,

I didn't understand yet the problem related to your specific geometry. I'm facing some problems with chtMultiRegion.
Could you please post some skecth of your geometry?

[hajott]

Dear Thiago,
I cannot show the actual geometry, but I attach a sketch to better describe the situation. We have a subdivision of a reactangular volume into three parts with some complicated boundary from one part to the next.

I have three blockMeshDicts to describe the Anode geometry (solid), the Cathode geometry (solid) and the fluid geometry. These blockMeshDicts are extremely complicated, so that I cannot merge them in a single blockMeshDict - they have been generated years ago using a (no longer existing) automatic tool, and I would go crazy if I wanted to join matched vertices and renumber all hexes and patches.

My question is how I can generate the faceRegionAddressing and similar files that are needed to run coupled simulations as chtMultiRegionFoam. Do you have a solution? Maybe one could first merge the three geometries while keeping the information which are the interface patches, if such a tool exists. Then one could again use splitMeshRegions in the same way as done in the multiRegionHeater tutorial. But I have no idea how to perform the merging step.

[thiagopl]

Hi hajott,

Now I understand but I don't have a solution unfortunately.

[derekm]

If your meshs are conformal i have a solution.I have a test case I can send you on
Saturday. It uses block mesh -region

[hajott]

Dear Derek,
this would be very kind.
What is meant by "conformal"? The three meshed volumes have "congruent" patches, such that for example adjacent patches X at the Anode side and patch Y at the fluid side have exactly the same geometry (vertex positions of each patch face of X and Y are identical) although I am not sure if the topology (ordering of the faces per patch) is identical on both sides. However, if the face ordering is not the same, I think I could write a tool to correct this. I will check.

Thank you
Hajo

[derekm]

Originally Posted by hajott

Dear Derek,
this would be very kind.
What is meant by "conformal"? The three meshed volumes have "congruent" patches, such that for example adjacent patches X at the Anode side and patch Y at the fluid side have exactly the same geometry (vertex positions of each patch face of X and Y are identical) although I am not sure if the topology (ordering of the faces per patch) is identical on both sides. However, if the face ordering is not the same, I think I could write a tool to correct this. I will check.

Thank you
Hajo

Conformal:
each cell face in the patch in one region should match exactly the cell face in the patch of the adjoining region
here is the case - very simple: two regions, two blockmesh files

[hajott]

Dear Derek,
I don't see how your example solves my question. Your scripts Allrun and Allrun.pre first generate a blockMesh, then define cellZones to cut the mesh in regions and finally use splitMeshRegions to generate the subMeshes and the interface patches. This is exactly the same procedure as the multiRegionHeater, which I have mentioned above doesn't help in my case:

I already HAVE different meshes for the different regions (Anode, Cathode and fluid in my sketch above). These meshes with their interface patches ARE conformal. But I CANNOT apply your procedure, because I don't have a topoSetDict that explains how the regions are cut out of the whole domain and how to create the boundary patches.

Do you still have a solution to my question?

[derekm]

Originally Posted by hajott

Dear Derek,
I don't see how your example solves my question. Your scripts Allrun and Allrun.pre first generate a blockMesh, then define cellZones to cut the mesh in regions and finally use splitMeshRegions to generate the subMeshes and the interface patches. This is exactly the same procedure as the multiRegionHeater, which I have mentioned above doesn't help in my case:

I already HAVE different meshes for the different regions (Anode, Cathode and fluid in my sketch above). These meshes with their interface patches ARE conformal. But I CANNOT apply your procedure, because I don't have a topoSetDict that explains how the regions are cut out of the whole domain and how to create the boundary patches.

Do you still have a solution to my question?

I uploaded the wrong case
here is the correct one. The previous one "regiontest" was the basis for the two blockmesh version that you require i.e. regiontest2

[hajott]

Which OpenFOAM version do you use?
I have a segmentation fault in the faceAgglomerate step with OF2.3.1.

Are you sure this is the case that you wanted to send? There is a topoSetDict, but it is never used. Moreover, there are two regions (heater and bottomAir). The bottomAir ist fully contained in heater. They are not two regions that touch each other. How does this make sense?

[derekm]

Originally Posted by hajott

Which OpenFOAM version do you use?
I have a segmentation fault in the faceAgglomerate step with OF2.3.1.

Are you sure this is the case that you wanted to send? There is a topoSetDict, but it is never used. Moreover, there are two regions (heater and bottomAir). The bottomAir ist fully contained in heater. They are not two regions that touch each other. How does this make sense?

on Openfoam 2.3.1 it worked perfectly for me ,but i hadnt tested in parallel. I hadnt cleaned out every redundant file.
The two regions touch in a patch, they work together, they transfer heat , it illustrates the methods required but is not based on a real scenario.
other anomalies exist .e.g/ bottomair isnt on the bottom...

I had built this test case quickly specially to help you understand the technique, it obviously does not fit your requirements as it has not been completely cleaned up.
I have now cleaned it up so there are no more confusing files or geometry and called the air region top air

[hajott]

Thank you for updating the geometry.
I have still a segmentation fault in faceAgglomerate.

Maybe there is something wrong with my OpenFOAM installation. I will try to find the problem in the debugger.

Anyway, the faceAgglomerate utility seems to be sufficient to create the face-to-face addressing that I have been asking for, so that I can consider my problem solved when I find the reason for the crash.

Thank you!
Hajo

[derekm]

Originally Posted by hajott

Thank you for updating the geometry.
I have still a segmentation fault in faceAgglomerate.

Maybe there is something wrong with my OpenFOAM installation. I will try to find the problem in the debugger.

Anyway, the faceAgglomerate utility seems to be sufficient to create the face-to-face addressing that I have been asking for, so that I can consider my problem solved when I find the reason for the crash.

Thank you!
Hajo

i trust you know faceagglomerate crashes with hanging pointer if nFacesInCoarsestLevel is not set high enough in ViewfactorsDict
and that a bug in ViewfactorGen has recently been fixed to allow setting of maxDynListLength

[EmadTandis]

Originally Posted by hajott

Thank you for updating the geometry.
I have still a segmentation fault in faceAgglomerate.

Maybe there is something wrong with my OpenFOAM installation. I will try to find the problem in the debugger.

Anyway, the faceAgglomerate utility seems to be sufficient to create the face-to-face addressing that I have been asking for, so that I can consider my problem solved when I find the reason for the crash.

Thank you!
Hajo

Hello Hajot
I am not sure that my problem is like yours. I have two meshes with a interface (regionCoupling patch) whose faces match together. But their addressing are not correct. for exmaple patch1 on mesh 1 and patch2 on mesh2 are region coupling type whose shadowPatch() functions refer to each other. But:
patch1.Cf()[i]=patch1().shadowPatch().Cf()[k]
I need to change addressing in order to have match faces on both side (i=k)


I hope I could convey my problem. If so, have you found any solution?

[shanyeyun]

Hi, I have send you a message. Don't know if you have solved the problem.
I have the same issue need to be solved.