CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

PatchToPatchInterpolationfaceInterpolate

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   March 13, 2013, 23:45
Default
  #21
Member
 
Ronald McDonald
Join Date: Jul 2012
Posts: 38
Rep Power: 5
mcdonalds is on a distinguished road
Quote:
Originally Posted by bigphil View Post
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
Hi Phil,

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?
Attached Files
File Type: gz watercase.tar.gz (5.2 KB, 0 views)
File Type: gz waterFoam.tar.gz (3.1 KB, 0 views)
mcdonalds is offline   Reply With Quote

Old   March 14, 2013, 00:28
Default
  #22
Member
 
Ronald McDonald
Join Date: Jul 2012
Posts: 38
Rep Power: 5
mcdonalds is on a distinguished road
Quote:
Originally Posted by bigphil View Post
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
Hi Phil,

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?
Attached Files
File Type: gz watercase.tar.gz (5.2 KB, 2 views)
File Type: gz waterFoam.tar.gz (89.9 KB, 1 views)
mcdonalds is offline   Reply With Quote

Old   March 14, 2013, 05:18
Default
  #23
Senior Member
 
bigphil's Avatar
 
Philip Cardiff
Join Date: Mar 2009
Location: Dublin,Ireland
Posts: 568
Rep Power: 19
bigphil will become famous soon enoughbigphil will become famous soon enough
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
bigphil is offline   Reply With Quote

Old   April 12, 2013, 11:37
Default
  #24
New Member
 
Florian
Join Date: Mar 2012
Location: Munich
Posts: 12
Rep Power: 5
Flor is on a distinguished road
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!

Boundary type for patchToPatchInterpolation

Best regards
Florian
Flor is offline   Reply With Quote

Old   October 2, 2013, 10:53
Default
  #25
Member
 
Join Date: May 2012
Posts: 55
Rep Power: 5
styleworker is on a distinguished road
Quote:
Originally Posted by bigphil View Post
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>
quit
then the command
Code:
setsToZones -noFlipMap
Then in your decomposeParDict, add the line:
Code:
globalFaceZones ( <faceZoneName1> <faceZoneName2>)
then when you decompose your case the full faceZone meshes will be included on each processor.

In your code, you can create a zoneToZoneInterpolation
Code:
label faceZone1ID = cp_.mesh().faceZones().findZoneID(facezoneName1);
label faceZone2ID = mesh.faceZones().findZoneID(faceZoneName2);

zoneToZoneInterpolation faceZoneInterpolator
        (
         mesh.faceZones()[faceZone1ID](), // from                                                                                          
         mesh.faceZones()[FaceZone2ID](), // to zone                                                                                        
         );
then you can use this interpolator just like a patchToPatch interpolator and it works in parallel.

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
Actually, I'm facing the same problem as described by cosimobianchini in the first post.
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();
    const polyPatch& nbrPatch = coupleManager_.neighbourPatch().patch();

    patchToPatchInterpolation interpolator(nbrPatch, ownPatch);
After reading your post, I'v tried to adapt your solution:

Code:
    const polyPatch& ownPatch = patch().patch();
    const polyPatch& nbrPatch = coupleManager_.neighbourPatch().patch();

    //initiate solid and fluid meshes
    const fvMesh& meshSolid = patch().boundaryMesh().mesh();
    const fvMesh& meshFluid = coupleManager_.neighbourRegion();

    //get ID of facezone (facezone_names equivalent to patch_names)
    label faceZone1ID = meshSolid.faceZones().findZoneID(patch().name());
    label faceZone2ID = meshFluid.faceZones().findZoneID(coupleManager_.neighbourPatchName());

    zoneToZoneInterpolation interpolator
            (
             meshFluid.faceZones()[faceZone2ID](), // from
             meshSolid.faceZones()[faceZone1ID]() // to zone
             );
Unfortunately I'm getting some error messages during solver compilation.

Do you have any idea, how to solve the problem?
Attached Images
File Type: jpg decompose.jpg (20.4 KB, 8 views)

Last edited by styleworker; October 2, 2013 at 12:05.
styleworker is offline   Reply With Quote

Old   October 2, 2013, 12:04
Default
  #26
Member
 
Join Date: May 2012
Posts: 55
Rep Power: 5
styleworker is on a distinguished road
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
    <
        PrimitivePatch<face, List, const pointField&>,
        PrimitivePatch<face, List, const pointField&>
    >   zoneToZoneInterpolation;
Even the case runs, but unfortunately with the same unphysical results. At least the zoneToZoneInterpolations worked

Last edited by styleworker; October 2, 2013 at 14:26.
styleworker is offline   Reply With Quote

Old   October 2, 2013, 14:27
Default
  #27
Member
 
Join Date: May 2012
Posts: 55
Rep Power: 5
styleworker is on a distinguished road
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.
Attached Images
File Type: jpg decomp_wrong.jpg (16.0 KB, 6 views)
styleworker is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -4. The time now is 02:04.