Hi all,
I have such a problem
Hi all,
I have such a problem: I'm using PatchToPatchInterpolation.faceInterpolate() to map boundary conditions on a patch from the coincident patch on another mesh (imposing heat flux and temperature continuity on a solid-fluid interface in a conjugate solver). In a single-processor run it is working perfectly even if the two meshes are not conformal (the global geometry is the same). If I run the case in parallel, with the processor patch normal to the interface, the two sides (solid & fluid) of the interface on processorn are not conformal and have different geometry (there is no way of decomposing the meshes in order to obtain coincident geometry: no shared vertex). In this case PatchToPatchInterpolation.faceInterpolate() is not giving good results in the zone near processor patch, read where the two sides of the interface differ in geometry. Any hint on how to still use PatchToPatchInterpolation.faceInterpolate() is very appreciated. (I use default choices for algorithm and direction) Thanks a lot Cosimo |
Hi,
I realise this is quite an old thread but did you ever get the patchToPatchInterpolation class to work correctly in parallel? Philip |
Hi,
I'm also interested in knowing the answer! :) /FEYMARK |
It actually is a quite old thread but to my knowledge patchToPatchInterpolation is not working in parallel in the latest versions too. In order to make it work in parallel you can try one of the following ways:
Cosimo |
Hi,
I was able to get my code with patchToPatchInterpolation to work in parallel. The way I did it was: In the case, for the patches of interest define faceZones, using the setSet utility Code:
faceSet <patchName>FaceZone new patchToFace <patchName> Code:
setsToZones -noFlipMap Code:
globalFaceZones ( <faceZoneName1> <faceZoneName2>) In your code, you can create a zoneToZoneInterpolation Code:
label faceZone1ID = cp_.mesh().faceZones().findZoneID(facezoneName1); However be careful when you have a moving mesh as the faceZone meshes might not be moved correctly, you might have to correct them and keep them consistent across the processors. Hope it helps, Philip |
I am trying to use patchtopatchinterpolation.H and I ID'd my patches and declared the pointtopointinterpolation. How do I do the last step, use the interpolator to map one patch to another?
Benjamin Here is my code: 1) Set findID codes. label cathodeID = mesh.boundaryMesh(). findPatchID("bottomcathode"); label electrodeID = mesh.boundaryMesh().findPatchID("topelectrode"); 2) Declare patchtopatchinterpolation. const polyPatch& electrodePatch = mesh.boundaryMesh()[electrodeID]; const polyPatch& cathodePatch = mesh.boundaryMesh()[cathodeID]; patchToPatchInterpolation cathodeToElectrode ( cathodePatch, electrodePatch ); |
Hi Benjamin,
From your email, you need to specify the template parameter for the faceInterpolate function i.e: Code:
scalarField interpolatedQuantity = cathodeToElectrode.faceInterpolate<scalar> Philip |
Quote:
HTML Code:
vectorField interpolatedQuantity = fromPatch_To_toPatch_Interpolate.faceInterpolate<vector> ( quantity.boundaryField()[fromPatchIndex] ); Second, what does quantity refer to in your "quantity.boundaryField()[fromPatchIndex]? I am putting my scalarfield (H2O) there but I do not think that is correct. Sincerely, Benjamin |
Quote:
The quantities mentioned in my previous post are just generic and are to be replaced with your specific scalar/vector/tensor fields. I will try give a more clear example: If I want to copy my temperature field T from the boundary patch called "left" to the boundary patch called "right": Code:
label leftID = mesh.boundaryMesh().findPatchID("left"); Philip |
Nearly there...
Here is my code, pretty much an exact replica of yours:
HTML Code:
label bottomID = mesh.boundaryMesh().findPatchID("bottomcathode"); Also, what should my case/0/H2O file look like? Specifically, what type do I use for the patches I'm connecting? Lastly, just to double check, I place this code within the time loop of my solver, right? Sincerely, Benjamin |
Quote:
The distances are then calculated by either fitting spheres between the surfaces (CONTACT_SPHERE) or using a normal vector (VECTOR). To find out more, you can read through the patchToPatchInterpolation class. Best regards, Philip |
Quote:
What should my case/0/H2O file look like? Specifically, what type do I use for the patches I'm connecting? Lastly, just to double check, I place this code within the time loop of my solver, right? Sincerely, Benjamin |
Quote:
Quote:
HTML Code:
label leftID = mesh.boundaryMesh().findPatchID("left"); label rightID = mesh.boundaryMesh().findPatchID("left"); patchToPatchInterpolation interpolator ( mesh.boundaryMesh()[leftID], // from patch mesh.boundaryMesh()[rightID], // to patch intersection::FULL_RAY, intersection::CONTACT_SPHERE ); scalarField TRightPatch = interpolator.faceInterpolate<scalar>(T.boundaryField()[leftID]); Benjamin |
Update
So this is what I have so far:
HTML Code:
label bottomID = mesh.boundaryMesh().findPatchID("bottomcathode"); Benjamin |
Hi Benjamin,
The patchToPatch interpolation explicitly passes a field from one patch to another, so it allows explicit coupling of patches. Depending on the system, you may need a loop within each time-step where you solve the governing equation then explicitly update the boundaries and iterate until convergence. Alternatively if you could use implicitly coupled boundaries it would probably be faster and more stable. Best regards, Philip |
Quote:
Sincerely, Benjamin |
Quote:
So I read through your posts that you got patchtopatch coupling working in parallel. And you had already been able to work it in serial. Do you have the code in serial where you get patchtopatch coupling working? Would you be able to share that code? Sincerely, Benjamin |
Hi Benjamin,
I used patchToPatchInterpolation in the elasticContactSolidFoam solver (actually in the contactPatchPatch class) which is in the solidMechanics branch of OpenFOAM-1.6-ext. As regards implicit boundary coupling, I am not that familiar with it, I would recommend google and the forum search. Best regards, Philip |
2 Attachment(s)
Quote:
Quote:
I downloaded the open extension 1.6 and the solidmechanics files. It is extremely complex but I've filtered through it and it seems that I am on the right track. When you do use the interpolator you definitely do use a forall loop. So, I've tried modifying my code. I was hoping you could take a quick look at it to see where I have gone wrong. It just doesn't seem to be picking up those mapped patches when I run the case. It is of a really simple case so very basic. Sincerely, Benjamin |
Benjamin,
I downloaded waterFoam2.tar.gz and looked at the '.C' file, there is a lot of code commented out and it is not clear what exactly you are trying to do and where your problem is. If you tidy up the solver and add descriptive comments pointing out exactly what code is not doing what you expect, then I may be able to help. Best regards, Philip |
2 Attachment(s)
Quote:
Thank you so much! So I've cleaned up the file. I've been thinking about my problem in a physics type of way and please bear with me as I try to explain it. At the most basic level, I would like one field to solve throughout the entire domain while the other field will have a boundary condition in the exact middle of the domain. So essentially, I would like to create two middle boundary conditions on my blockMeshDict file, then "merge" the two middle boundary condition patches for one of my fields. I was thinking that patchtopatchinterpolation may not be able to do this. I think patchtopatch will take values of one patch and send it to another, but in my case file, if the values of said patch is zero or zeroGradient, all it will do is just send zero or zeroGradient to the other patch, and I'd be back at square one. Since I'd like to merge them, then I would take the internal cells adjacent to the length of my patch, solve for those cells, send those values to the other patch, solve again, and then continue solving for the rest of the cells. Perhaps, in that way the two cells will "merge" as if there was no boundary there at all. I've tried groovyBC (that was very close but the physics came out wrong), I've tried mappedPatch (only maps values from one patch to another only at the initial conditions not during the time steps), and I've tried cyclic boundaries (which work great but then I cannot set boundary conditions for those patches that I've made cyclic to each other). In essence, I may be going about this incorrectly with patchtopatchinterpolation. Let me know what you think and if my thinking process is accurate. Sincerely, Benjamin P.S. Perhaps I would need to make multiple meshes: Two local meshes and a global mesh. My global mesh will encompass the entire domain while the two local meshes will occupy half of the global mesh. I would assign a field to each mesh, and then I would need to map meshes to each other. The mapping I would have a problem with. Perhaps this is my solution though? |
2 Attachment(s)
Quote:
Thank you so much! So I've cleaned up the file. I've been thinking about my problem in a physics type of way and please bear with me as I try to explain it. At the most basic level, I would like one field to solve throughout the entire domain while the other field will have a boundary condition in the exact middle of the domain. So essentially, I would like to create two middle boundary conditions on my blockMeshDict file, then "merge" the two middle boundary condition patches for one of my fields. I was thinking that patchtopatchinterpolation may not be able to do this. I think patchtopatch will take values of one patch and send it to another, but in my case file, if the values of said patch is zero or zeroGradient, all it will do is just send zero or zeroGradient to the other patch, and I'd be back at square one. Since I'd like to merge them, then I would take the internal cells adjacent to the length of my patch, solve for those cells, send those values to the other patch, solve again, and then continue solving for the rest of the cells. Perhaps, in that way the two cells will "merge" as if there was no boundary there at all. I've tried groovyBC (that was very close but the physics came out wrong), I've tried mappedPatch (only maps values from one patch to another only at the initial conditions not during the time steps), and I've tried cyclic boundaries (which work great but then I cannot set boundary conditions for those patches that I've made cyclic to each other). In essence, I may be going about this incorrectly with patchtopatchinterpolation. Let me know what you think and if my thinking process is accurate. Sincerely, Benjamin P.S. Perhaps I would need to make multiple meshes: Two local meshes and a global mesh. My global mesh will encompass the entire domain while the two local meshes will occupy half of the global mesh. I would assign a field to each mesh, and then I would need to map meshes to each other. The mapping I would have a problem with. Perhaps this is my solution though? |
Benjamin,
I am not sure that patchToPatchInterpolation is what you want. Have you looked at solvers like chtMultiRegionFoam, or if you search for domain coupling in OpenFOAM (e.g. like methods in this presentation). I had a look at your code and it is not clear exactly what you are trying to do but you are not changing the boundary conditions - you are making a copy of the H20 boundary values "scalarField shawmut = H2O.boundaryField()[topID];" and then you make and set a new field called "interpole". Both these fields just get delete at the end of the scope. You haven't actually updated the boundary conditions - the updating method will depend on what type of boundary they are i.e. fixedValue, fixedGradient, etc.. Philip |
Dear Foamers, I did not want to make up a new topic in this thread, so I started a new one. But I think you might be the right people to ask, so may I suggest my new thread to you? :-) Would be great if you could give me a hint!
http://www.cfd-online.com/Forums/ope...tml#post420165 Best regards Florian |
1 Attachment(s)
Quote:
I'm trying to include conjugate heat transfer in interDyMFoam. Running the solver on a single processor works quite fine, but as I decompose the mesh, results become unphysical (as you can see in the attached picture). Currently, the interpolation is done via Code:
const polyPatch& ownPatch = patch().patch(); Code:
const polyPatch& ownPatch = patch().patch(); Do you have any idea, how to solve the problem? |
I've managed to compile the coupling part of the solver on OF-1.6ex. It seems there is a difference in "patchToPatchInterpolation" between OF-1.6ex and OF2.2.0.
After adding the code below to the patchToPatchInterpolation.H (OF-2.2.0), I was able to compile the solver without error messages. Code:
typedef PatchToPatchInterpolation |
1 Attachment(s)
I guess the coupling isn't the origin of the unphsysical behaviour, but the decomposition of the domain. I've assumed decomposePar devides the mesh in four equal domains. As you can see in the attached picture, it isn't the case.
So I think I have to decompose the mesh in a proper way. |
All times are GMT -4. The time now is 22:23. |