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

[Jean-Michel Campin]

Hi Dimitris,

On Fri, Jan 29, 2010 at 06:28:06PM -0800, Dimitris Menemenlis wrote:
> Jean-Michel, again thank you for very helpful answer.
> 
> I cannot identify horizontal difusion acting on gt.
> 
> The artifacts happen at tile edges.
> An example is the adjoint-model-based adjustment fields
> shown on slide 10 of Hong's ECCO2 meeting presentation:
> Progress towards a 16-month CS510 adjoint state estimate.

slide 10 & 11 are plots of atmos wind ; Do you see the same problem
in other fields (air temp ? air humidity ? ...) ?

Thanks,
Jean-Michel

> 
> I will try your suggestion of adding exchanges on gt, etc., as a check.
> 
> Thanks, Dimitris
> 
> On Jan 29, 2010, at 9:57 AM, Jean-Michel Campin wrote:
> 
> > 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
> > 
> > _______________________________________________
> > 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