[MITgcm-devel] new r4 SingleCpuIO efficiency

[Dimitris Menemenlis]

Jean-Michel, thank you for quick answers.

> The 2nd isssue is easier: I think (would need to check) that
> Olx needs to be smaller than sNx and same thing for Oly,sNy.
> With exch-1, we ended having 2 special case for 2-D set-up
> (x-z or y-z) for this reason (if I remember well).
> Now, for a simple set-up (no seaice, Hydrostatic ...),
> compiled with zero optimisation, the GLOBAL_SUM_SINGLECPU
> will help to get same results independent of the tiling.

What you say above is consistent with the few tests that I ran. That is,
when Olx < sNx and Oly<sNy, the solutions are identical for different
tile sizes.

> The 1rst issue: the check-depth is on the "safe" side:
> if there is zero depth at the edge of a tile touching a blank-tile,
> then it's relatively clear that it is OK.
> I don't know if this is safe to allow a non-zero depth
> next to a blank-tile (because it might depend of which piece of
> the algorithm we consider). But it could well be that I am
> wrong, that the default initialisation provides a "safe" set-up.
> But regarding your check of hfacW,S, ... , does this includes
> the overlap ?

The check of hfacW,S,C and Depth.data did not include the overlap.
For these tests, I was using
the cs32 s176t_8x4 configuration with data.exch2 taken from
MITgcm/utils/exch2/code-mods/data.exch2.16_blk
The above configuration has some non-zero depths next to blank tiles.

I rerun three tests:

  (1) s12t_32x16
  (2) s192t_8x4
  (3) s176t_8x4 with data.exch2.16_blk

after turning off seaice, compiling with zero optimization,
using GLOBAL_SUM_SINGLECPU,
and using Olx=Oly=2 < sNx and sNy.

I find that all three tests are identical, indicating that,
at least for this particular cs32 setup,
it is OK to have a non-zero depth next to a blank tile.

D.