[MITgcm-devel] Re: [MITgcm-support] Question: boundary exchange, hrcube condfiguration

[Jean-Michel Campin]

Hi Martin,

I was not refering to the corner-halo region of 1 face
but one of a tile "inside" a face:
> >in the simplest case (a tile in the middle of a face),
and since this e-mail, I though of how to do like in exch1,
(meaning with only 1 EXCH2_R81_CUBE call) but it would require
to split the list of connected neighbours in 3, and then to proceed in
3 steps (instead of only 2 trivial set of connections x, then y, 
for what we have in exch1), and it seems painfull to me.

Jean-Michel

On Tue, Jul 10, 2007 at 03:53:10PM +0200, Martin Losch wrote:
> Hi Jean-Michel (and Chris!),
> 
> I still don't understand, your argument would apply to non-cube  
> topologies too, but it does not.
> 
> In exch2_3d_r8 we have:
>        CALL EXCH2_R81_CUBE( phi, 'T ',
>      I            OLw, OLe, OLs, OLn, myNz,
>      I            exchWidthX, exchWidthY,
>      I            FORWARD_SIMULATION, EXCH_UPDATE_CORNERS, myThid )
> then there a block within
> #ifdef W2_FILL_NULL_REGIONS
> #endif
> which according to some comment is only used for debugging. defining  
> W2_FILL_NULL_REGIONS fills the face corners with zeros (or whatever  
> the fill value is) and this is not supposed to change the results, so  
> why do we need a second call (after which filling the corners does/ 
> should not change the results)?
> 
> Martin
> 
> On 27 Jun 2007, at 15:24, Jean-Michel Campin wrote:
> 
> >Hi,
> >
> >I think (but I might be wrong) that,
> >in the simplest case (a tile in the middle of a face),
> >we need a 1rst call to fill the halo region next to the tile edges
> >(i.e., [1-Olx:0,1:sNy]),
> >and a second call to fill the "corner" parts of the halo regions
> >(i.e, [1-Olx:0,1-Oly:0]).
> >
> >This could be done in just 1 call, but would require to connect to
> >8 tiles instead of only 4 in the present case.
> >
> >I would be interesting to see how to apply the same solution
> >as with exch1 (or why it's not possible).
> >
> >Now, I am trying to figure out why we need 3 exit2_rl2_cube calls ...
> >
> >Jean-Michel
> >
> >On Wed, Jun 27, 2007 at 01:44:54PM +0200, Martin Losch wrote:
> >>Hi there,
> >>
> >>could someone please explain this to Michael (and me)? Why do we need
> >>two calls to exch2_rl1_cube?
> >>
> >>Martin
> >>
> >>On 22 Jun 2007, at 14:14, Michael Schroeter wrote:
> >>
> >>>Hi,
> >>>
> >>>as Martin already reported in an earlier posting
> >>>(http://forge.csail.mit.edu/pipermail/mitgcm-support/2007-March/
> >>>004719.html)
> >>>we have some unexpected scaling behaviour on a IBM p690
> >>>(cubed sphere configuration, 16 passive tracers).
> >>>
> >>>We found out that the boundary exchange of the ptracers data seems
> >>>to be
> >>>responsible for the slow down of the code. Now we have some ideas  
> >>>for
> >>>code optimazation.
> >>>
> >>>However, there is one thing in the current code I do not unterstand.
> >>>In "exch2_3d_rl.F" the subroutine "EXCH2_RL1_CUBE" is called two  
> >>>times
> >>>with exactly the same values for the argument list parameters
> >>>(even if the cpp option "W2_FILL_NULL_REGIONS" is undefined).
> >>>Can anybody explain that to me?
> >>>
> >>>Thanks in advance.
> >>>
> >>>Regards
> >>>Michael
> >>>
> >>>-- 
> >>>Dr. Michael Schroeter                          Phone: +49(471)
> >>>4831-2084
> >>>Email: Michael.Schroeter at awi.de                Fax:   +49(471)
> >>>4831-1149
> >>>Alfred-Wegener-Institute for Polar- and Marine Research
> >>>Am Handelshafen 12, D-27570 Bremerhaven
> >>>www.awi.de
> >>>_______________________________________________
> >>>MITgcm-support mailing list
> >>>MITgcm-support at mitgcm.org
> >>>http://mitgcm.org/mailman/listinfo/mitgcm-support
> >>
> >>_______________________________________________
> >>MITgcm-devel mailing list
> >>MITgcm-devel at mitgcm.org
> >>http://mitgcm.org/mailman/listinfo/mitgcm-devel
> >_______________________________________________
> >MITgcm-devel mailing list
> >MITgcm-devel at mitgcm.org
> >http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel