|
[Sponsors] |
[mesh manipulation] polyDualMesh for multiregion case and proper order of commands |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
December 5, 2022, 06:46 |
polyDualMesh for multiregion case and proper order of commands
|
#1 |
New Member
Chris
Join Date: Jan 2022
Posts: 22
Rep Power: 4 |
Hi Everyone,
I'm trying to use the command Code:
polyDualMesh 75 -concaveMultiCells -overwrite 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 |
|
December 6, 2022, 03:07 |
|
#2 |
Senior Member
Join Date: Dec 2021
Posts: 209
Rep Power: 5 |
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! |
|
December 6, 2022, 07:35 |
|
#3 | |
New Member
Chris
Join Date: Jan 2022
Posts: 22
Rep Power: 4 |
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: Quote:
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?) |
||
December 7, 2022, 03:14 |
|
#4 |
Senior Member
Join Date: Dec 2021
Posts: 209
Rep Power: 5 |
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! |
|
December 8, 2022, 07:11 |
|
#5 |
New Member
Chris
Join Date: Jan 2022
Posts: 22
Rep Power: 4 |
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. |
|
April 25, 2023, 02:29 |
|
#6 |
New Member
Chris
Join Date: Jan 2022
Posts: 22
Rep Power: 4 |
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 Code:
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 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 Code:
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 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 |
|
April 25, 2023, 04:32 |
|
#7 | ||||
Senior Member
Join Date: Dec 2021
Posts: 209
Rep Power: 5 |
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 Quote:
Quote:
Code:
3. [note] It appears that the "-cellZones" flag I used for "splitMeshRegions" is no longer necessary for splitting merged meshes. Quote:
Quote:
Code:
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; } 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 |
|||||
April 26, 2023, 02:40 |
|
#8 |
New Member
Chris
Join Date: Jan 2022
Posts: 22
Rep Power: 4 |
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 Code:
receiver_to_salt { type mappedWall; nFaces 95779; startFace 4406107; sampleMode nearestPatchFaceAMI; sampleRegion salt; samplePatch salt_to_receiver; } Code:
receiver_to_salt { type cyclicAMIl; nFaces 95779; startFace 544714; neighbourPatch salt_to_receiver; } For the fields I'm planning to use the exact same schemes as before. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[mesh manipulation] The extracted patch Labels in not proper for different test case. | sunagra27 | OpenFOAM Meshing & Mesh Conversion | 0 | May 31, 2021 03:08 |
MRFSimpleFoam wind turbine case continuity error | ysh1227 | OpenFOAM Running, Solving & CFD | 1 | August 16, 2016 09:25 |
MRFSimpleFoam wind turbine case diverges | ysh1227 | OpenFOAM Running, Solving & CFD | 2 | May 7, 2015 10:13 |