[MITgcm-devel] new r4 SingleCpuIO efficiency

Tue May 26 14:04:01 EDT 2009

Dimitris,

to clarify:
to generate the list of blank-tile, I just put the 
 corresponding tile-number in data.exch2.
to get the list of empty tile (which I could decide later to make 
them blank-tile), I compile and run (1 iter is enough) without 
blank-tile and:
> grep 'Empty tile' output.txt
or MPI:
> grep 'Empty tile' STDOUT.*
give this list.

Now, once you decide to run with a list of blank-tiles, there is 
no way to check that there is fluid inside those tiles: they are
gone, the bathy of those tile is not loaded, so looks hard to put
a stop for this case.
May be it's an other reason to go for the warning solution ?

Cheers,
Jean-Michel

On Tue, May 26, 2009 at 07:00:00AM -0700, Dimitris Menemenlis wrote:
> 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
> 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel