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

[Patrick Heimbach]

Dimitris,

not sure how to narrow this down.
Is problem visible only in the xx_* adjustment fields or also in full  
uwind variables?
What I'm trying to get at is whether this is purely related
to something in the ctrl package or in the exf package or in model/src.
Depending on the case, the routines external_forcing_* wouldn't have
anything to do with it and you're on a wrong track.

Several things to check:
Plot the *full* uwind, vwind fields as obtained from pkg/diagnostics
both for iter0 and for iterX

Since you're adding xx_uwind onto first guess, it should also be visible
in the full field, except for iter0 where xx_uwind == 0
What about wind stresses?
Is there a problem there as well?

-p.

On Jan 29, 2010, at 9:28 PM, 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.
>
> 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

---
Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach