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

[Dimitris Menemenlis]

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20100129/ce7e1cf1/attachment.htm>