[MITgcm-devel] iMin, iMax, jMin, and jMax in EXTERNAL_FORCING_T

[Jean-Michel Campin]

Hi Dimitris,

On Fri, Jan 29, 2010 at 08:07:29AM -0800, Dimitris Menemenlis wrote:
> Jean-Michel thanks for getting back.
> 
> Can I rephrase my question a little differently then:
> What is the correct range for EXTERNAL_FORCING_T computations?
> 
> The i-j-Min-Max range going in EXTERNAL_FORCING_T is:
>           iMin = 1-OLx+2
>           iMax = sNx+OLx-1
>           jMin = 1-OLy+2
>           jMax = sNy+OLy-1
> 
> Yet most computations (except for OBCS_SPONGE_T) are carried out
> in a smaller domain:
>         iMin = 1
>         iMax = sNx
>         jMin = 1
>         jMax = sNy
> 

I think it's right to set the forcing (T & S) in the interior only,
and when it's needed in some part of the overlap (e.g.: fresh-water
flux when using real-fresh water form), there are exchanges.
For U & V forcing, this is different (see comment inside
external_forcing.F), but we know why.

So, the interesting comes later:
> As far as I can see there is no exchange on gT between
> EXTERNAL_FORCING_T and the application of diffusion terms that follow
> in THERMODYNAMICS.  Is this correct?
can you identify any horizontal diffusion acting on gt ?
There are some subtil stuff with implicit gravity waves, but I think
it's done carefully.
And when a scheme requires valid overlap, e.g. shapiro filter, 
the scheme take care of calling exchanges where needed.

> In adjoint cube-sphere computations, if I squint the right way, I can see
> lines at the tile edges.  I am wondering whether the above discrepancy
> in computation domain could be part of the cause?

All tile eges or only face eges ?
There are ways to check for "discrepancy in computation domain" 
and overlap update problem (e.g., #define DYNAMICS_GUGV_EXCH_CHECK
in dynamics.F, and some DEBUG_CS_CORNER_UV in gad_advection.F),
and you could check by adding an exchange on gT, it should not 
change the solution (with zero compiler optimisation).
The last time we turned-on DYNAMICS_GUGV_EXCH_CHECK was
because of piece of code that got removed under an
#ifndef ALLOW_AUTODIFF

Cheers,
Jean-Michel
> 
> Dimitris
> 
> On Jan 29, 2010, at 7:17 AM, Jean-Michel Campin wrote:
> 
> > Hi Dimitris,
> > 
> > Here is what I think (might not be completly true, but ...)
> > 1) Hard coded loop range can speed-up the compiler optimisation.
> > 2) removing those arguments from the EXTERNAL_FORCING_ S/R 
> > could embarasse people that have their own version of these S/R
> > and I think it's why Alistair was reluctant to change this.
> > 
> > Cheers,
> > Jean-Michel
> > 
> > On Thu, Jan 28, 2010 at 04:02:55PM -0800, Dimitris Menemenlis wrote:
> >> Jean-Michel or Martin, is there a reason why iMin, iMax, jMin, and jMax
> >> are passed to EXTERNAL_FORCING_T but then are ignored?
> >> 
> >> Most computations (with exception of OBCS_SPONGE_T) are carried out in a 1, sNx, 1, sNy domain.
> >> 
> >> In particular, SHELFICE_FORCING_T only applies forcing a 1, sNx, 1, sNy domain.
> >> 
> >> Is this the correct way to proceed?  Thanks, Dimitris
> >> 
> >> 
> >> _______________________________________________
> >> 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