[MITgcm-devel] new r4 SingleCpuIO efficiency

[Dimitris Menemenlis]

JM, another option is to stop if there is fluid inside a blank tile and to issue a warning if there is fluid in an adjacent grid cell.

How do you generate list of blank files?  I checked in a little bit of matlab code yesterday for doing this on cube but it is not general and it does not take into account edges.  I remember vaguely that Chris had a way of doing this by running MITgcm without blanks.  It'd be good to make sure that this list does not include blank tiles with fluid in adjacent grid boxes.

D.

Dimitris Menemenlis
818-625-6498
-----Original Message-----
From: Jean-Michel Campin <jmc at ocean.mit.edu>
Date: Tuesday, May 26, 2009 6:32 am
Subject: Re: [MITgcm-devel] new r4 SingleCpuIO efficiency
To: "MITgcm-devel at mitgcm.org" <MITgcm-devel at mitgcm.org>Reply-To: "MITgcm-devel at mitgcm.org" <MITgcm-devel at mitgcm.org>

Hi Dimitris,

I had a quick look at few pieces of code:
- the default atmospheric set-up initialisation is full depth,
  but looks like the code is OK (I think we are lucky here).
- mom_vi_*coriolis works also: it relies on the additional values
  (size_face+1) of the grid-files, which are generally (except the 
  mising corners) over-witten by the EXCH. So, as long as the
  grid-files are correct, seems to be OK.
  The mom_vi_u,v_coriolis_c4 with useAbsVorticity=T mask the
  absolute vorticity so that is also OK.
  (it's not the best thing to do, would be better to mask the 
   relative vorticity and then add coriolis, and then this
   blank-tile non-zero-depth would become a problem).

I would propose, either:
 to comment out exch2_check_depth call, or
 to change the error into a warning (and not stopping).
little preference for the "warning" solution. What do you think ? 

Cheers,
Jean-Michel

On Mon, May 25, 2009 at 08:17:39PM -0700, Dimitris Menemenlis wrote:
> 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.
>
> _______________________________________________
> 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