[Chris T]

Hi Everyone,


I'm trying to use the command

polyDualMesh 75 -concaveMultiCells -overwrite

in a multi-region case of mine.
I'm currently confused about what is the right way to use the polyDualMesh mesh utility for a multi-region case. Is the utility applied to the initial mesh in constant/Polymesh directory or to the mesh of the individual regions obtained by splitMeshRegions -cellZones?


Also what would be the proper order of commands? I currently follow the following:
- copy polyMesh directory in constant (obtained from salome)
- "splitMeshRegions -cellZones -overwrite"
- "checkMesh -allTopology -allGeometry"
- "checkMesh -allTopology -allGeometry" for all individual regions
- "polyDualMesh 75 -concaveMultiCells -overwrite"
- "checkMesh -allTopology -allGeometry"
- "splitMeshRegions -cellZones -overwrite" - "checkMesh -allTopology -allGeometry" for all individual regions


I'm not sure if the order is correct and if the utilities I use are applied to the right data.
A few weird things that happen when I follow the above: 1) new regions are created that are separate from the region I have in the initial mesh. 2) when I visualize the new regions, though it appears that the "polyhedrixation" was successful, only part of the mesh is vissible.



I will appreciate any recommendations.


Best regards,
Chris

[Alczem]

Hey!


I had a similar interest with polyDualMesh. As far as I know, you cannot use it for a multiregion mesh because it does not preserve the faceZones. The best I got, thanks to another user (I cant find the thread right now), was to import the Salome mesh, save the faceZones file somewhere else, convert the mesh using polyDualMesh and then copy faceZones back to the polyMesh folder.


The facezones are somewhat intact and at the right place, but they are warped quite a bit and the edges are not "snapped' properly anymore. I guess you could try splitMeshRegions after that but the result would probably look rough Apart from that, you could mesh the regions independantly, convert them separately and merge them afterwards. Good luck!

[Chris T]

Hi Alczem,


Thanks for your answer! You pretty much answered my question regarding the compatibility (or rather lack thereof ) between a multi-region case and polyDualMesh.


Regarding the suggestion:

you could mesh the regions independently, convert them separately and merge them afterwards

I was considering this for my case for more than one reasons. One of the other reasons was to be able to have more then one boundary between regions rather than the default of region1_to_region2 that results from splitMeshRegions.
Do you know of any resource I could look into for that process. I know how to do the conversion and everything. My main concerns with joining regions manually is: 1) What should I do manually (e.g. do I need to add files?, 2) Since the meshes are not guarantee to be conformal (with nodes coincident) at the boundaries what step should I take to make sure I have correct coupling between regions (e.g. should add extra code to interpolate data at boundary and will this be more computationally costly?)

[Alczem]

Hey!


Merging meshes is pretty straightforward, you have to have a master case and a target case and use mergeMeshes with the proper options. You can refer to the doc for that:


https://www.openfoam.com/documentati...rgeMeshes.html


This command won't care if the meshes are conformal or not, it will just put the meshes "side by side" in a common polyMesh file.


The trickiest part is to have your non-conformal interfaces communicate. Without going into to much details (because I used this just once some time ago ), you have to modify your boundary file and change the type of the interfaces to ACMI or AMI, not sure. I am sure you can find several examples online. From what I remember, you have to pay close attention to the type of transformation and the tolerance between the two boundaries you are trying to set up. Once it is done, make the appropriate changes to the boundary conditions.


Hope it answers the question and helps, good luck!

[Chris T]

Thanks a lot for the resources and suggestions!
I will give it a try when I find free time or when it will be necessary for my case. It sounds straight forward how you describe it.
I would think transformations and the tolerances will not be an issue in my case since I prepare my different regions in the same files in FreeCAD and then mesh in Salome. They are already one object composed of multiple regions with touching boundaries.

[Chris T]

Dear Alczem,

Hi. I finally got to try the MergeMesh function and to follow your advice in using it.
I got a bit confused though. I'm not sure if I'm applying it correctly or maybe we didn't fully understood each other in our previous exchange.

Let me first tell you what I've tried and what the problem/confusion is.

As mentioned above I work on a multiregion case. In particular I have three regions. At first I tried to use mergeMesh on two of the regions *without* using the polyDualMesh utility(for now). In doing that I realized that the mergeMesh produces a singular mesh with one polyMesh directory. I only recover the two separate mesh region by using ~splitMeshRegions -overwrite~. After that the two separate meshes pop out in constant directory next to the polyMesh similar to the structure of multiregion cases as I know them.

My questions are:
1. Is this procedure of merging and splitting again necessary or is it redundant? I notice that this process give me new files in the individual regions mesh files like "boundaryRegionAddressing". Is this something useful or could I achieve the same effect by copying the individual region meshes in a constant dir directly (without merging and spliting)?
2. Is this procedure scalable to more than two regions?
so far I tried

cp -r receiver_Mesh/ receiver
mergeMeshes -overwrite receiver salt_Mesh/
mv receiver merged_r-s
mergeMeshes -overwrite merged_r-s air_Mesh/
mv merged_r-s merged_r-s-a
splitMeshRegions -case merged_r-s-a -overwrite

where receiver_Mesh/, salt_Mesh/, and air_Mesh/ are exported from salome using this script. On the surface it seems to be working based on what I see from the directory structure. But I haven't run the case yet therefore I don't know if there is an underline flaw to this method.

3. [note] It appears that the "-cellZones" flag I used for "splitMeshRegions" is no longer necessary for splitting merged meshes.
4. How do I properly apply the AMI boundary condition. So far I altered the file constant/polyMesh/boundary using

for i in receiver_to_salt receiver_to_air salt_to_receiver air_to_receiver
do
  foamDictionary constant/polyMesh/boundary -entry entry0/$i/type -set "cyclicAMI"l
done
foamDictionary constant/polyMesh/boundary -entry entry0/receiver_to_salt/neighbourPatch -set salt_to_receiver
foamDictionary constant/polyMesh/boundary -entry entry0/receiver_to_air/neighbourPatch -set air_to_receiver
foamDictionary constant/polyMesh/boundary -entry entry0/salt_to_receiver/neighbourPatch -set receiver_to_salt
foamDictionary constant/polyMesh/boundary -entry entry0/air_to_receiver/neighbourPatch -set receiver_to_air

5. What is the appropriate way to apply
type compressible::turbulentTemperatureRadCoupledMixed; for the T field
and also wall functions?
with automatic decomposition using "splitMeshRegions -cellZones" on a singular salome mesh with different labeled regions the internal boundaries (also mentioned as "inter-region interfaces") where automatically labeled as "type mappedWall;" with "sampleMode nearestPatchFace;" and also automatically specified sampleRegion and samplePatch.

in other cases I've seen so far cyclic AMI is used for same material regions not fluid boundary walls where in my case the boundary interfaces are also material interfaces.

Best,
Chris

[Alczem]

Hey Chris!


Multiregion cases are indeed tricky, and I never had to use the mergeMeshes utility in this context, so I apologize for the poor explanation

1. Is this procedure of merging and splitting again necessary or is it redundant? I notice that this process give me new files in the individual regions mesh files like "boundaryRegionAddressing". Is this something useful or could I achieve the same effect by copying the individual region meshes in a constant dir directly (without merging and spliting)?

The splitMeshRegions utility does create necessary files for multiregion cases and I don't think you can ignore them, they have to be in the polyMesh folders of the different regions. The merging step is usually not necessary if your mesh includes all the regions you need and you can identify them as cellZones (Salome can do that for instance). The merging becomes necessary if you mesh your regions in an independant manner, one after the other, and import them separately, and that is your original goal with polyDualMesh. But it creates only one big polyMesh folder, so you need to split after that. It will create the required files allowing the identification of each region in the constant and 0 folders.

2. Is this procedure scalable to more than two regions?

Well I think it is easier to start with just two regions to get the process down and then scale it up. If it works with two regions, it will probably work for more, but start small.

3. [note] It appears that the "-cellZones" flag I used for  "splitMeshRegions" is no longer necessary for splitting merged meshes.

You would have to check the source code, maybe the utility automatically detects several regions since you merged them, and they are not coupled by internal faces in common. That is good news though if the regions are created properly, we just need to figure out a way to make the adjacent boundaries communicate. And that is where the AMI comes into play.

4. How do I properly apply the AMI boundary condition

I am not taht comfortable with AMIs and ACMIs, you need to find some examples online. But I am quite sure that someone before you tried to set up multiregion cases using mergeMeshes and coupling conditions.

5. What is the appropriate way to apply
type compressible::turbulentTemperatureRadCoupledMixed; for the T field

For solid-fluid coupling, only the T file needs special treatment. The other files for the fluid region can be treated as a single region case. Here is an example for the boundary condition for the fluid and solid regions:

fluid_to_solid

{
         type            compressible::turbulentTemperatureRadCoupledMixed;
         Tnbr            T;  //Temperature field of the neighbour region
         //qrNbr           qr; // or none. Name of qr field on neighbour region
         qr              qr; // or none. Name of qr field on local region
         kappaMethod    fluidThermo;
         value           $internalField;
     }


solid_to_fluid

{
         type            compressible::turbulentTemperatureRadCoupledMixed;
         Tnbr            T;  //Temperature field of the neighbour region
         qrNbr           qr; // or none. Name of qr field on neighbour region
         //qr              qr; // or none. Name of qr field on local region
         kappaMethod    solidThermo;
         value           $internalField;
     }

It boils down to name the existing fields in the two regions involved. So for instance, if radiation is involved, a qr field exists for the fluid region but not for the solid region hence the lines commented out. Again, plenty of more detailed examples online.




Hope it helps the big issue comes from coupling the adjacent boundaries after merging and splitting, hopefully you can find an example online. I am not sure how but it feels like it is definitely achievable maybe try to get a case working without the merging step, but just with a mesh already including the two cellZones, so you can get a feel of how the files are managed? Good luck!


EDIT:



here is a thread with useful information:


Merging meshes for chtMultiRegionFoam

[Chris T]

Hi Alczem,

Thanks for your reply again!
Regarding 4 and 5. The more I read and the more I compare with my old simulations the more I'm convinced that the cyclicAMI type for boundaries is not appropriate in my case. I have only see cyclicAMI used in same material regions. In my case I need to enforce wall type in my interfaces to be able to apply wall function and also to apply "compressible::turbulentTemperatureCoupledBaffleMi xed;" at the solid-liquid interface and compressible::turbulentTemperatureRadCoupledMixed at the solid-gas interface. From the documentation here https://openfoam.org/release/2-3-0/non-conforming-ami/ it appears that cyclicACMI could be suitable to enforce a wall type to the patch. In any case it appears to me that both cyclicAMI and cyclicACMI are made for moving meshes which is not the case for my case.

I lean towards using

receiver_to_salt
    {
        type            mappedWall;
        nFaces          95779;
        startFace       4406107;
        sampleMode      nearestPatchFaceAMI;
        sampleRegion    salt;
        samplePatch     salt_to_receiver;
    }

in the polyMesh/boundary file of the merged mesh. Instead of

receiver_to_salt
    {
        type            cyclicAMIl;
        nFaces          95779;
        startFace       544714;
        neighbourPatch  salt_to_receiver;
    }

The issue is that in this case the nodes are not coincident in the two meshes and special case is needed to couple the interfaces. Notice that the option"sampleMode nearestPatchFaceAMI;" is present so hopefully this will take care of the proper coupling.


For the fields I'm planning to use the exact same schemes as before.