[MITgcm-devel] gmredi_check.F

[Holly Dail]

Jean-Michel -

Thank you very much for the detailed analysis!  Sounds like at this point I should #undef ALLOW_EDDYPSI, especially as your analysis of case (b) below concerns me ... that should be the case for my adjoint runs and the worst case scenario is pretty unpleasant.

Thanks again -
Holly

On Feb 8, 2011, at Feb 8 , 6:16 PM, Jean-Michel Campin wrote:

> Hi Holly,
> 
> I looked at ALLOW_EDDYPSI + GMREDI code:
> 
> Without compiling gmredi pkg (#undef ALLOW_GMREDI),
> things are fine (except that there is no run-time parameter to
> decide, at runtime, to use or not taueddy):
> with #define ALLOW_EDDYPSI, the model call the 2 S/R 
> TAUEDDY_EXTERNAL_FORCING_U & _V to add 
>    f*d.eddyPsiX/dz to gU
> and f*d.eddyPsiY/dz to gV 
> with eddyPsiX,eddyPsiY beeing read from file.
> 
> With #define ALLOW_GMREDI & GM_AdvForm=T, we compute GM_PsiX & GM_PsiY
> and add eddyPsiX to GM_PsiX and eddyPsiY to GM_PsiY (I don't know
> precisely what this means).
> 
> And I think that with GM_InMomAsStress=T, the U,V or psiX,psiY
> component are switched and therefore wrong (+ may be a sign error in
> or 1 of the 2):
> since: (GM_PsiX,GM_PsiY) = K_gm * (Sx,Sy) (with Sx,Sy the 2 components
> of the slope),
> we should add to gU:
> -f*d.GM_psiY/dz
> and to gV:
> +f*d.GM_psiX/dz
> (since in the GM-advective form, U_bolus= -d.GM_psiX/dz and 
> V_bolus = -d.GM_psiY/dz, and in the limit of Geostrophic balance
> the 2 should match)
> but instead we do the same thing as for eddyPsiX,eddyPsiY 
> (as written above). If we want to fix this, changing sign and switching
> psiX <-> psiY is not enough since the locations on the grid don't match.
> 
> In conclusion: the GM_InMomAsStress code have some serious problems
> but the stop in gmredi_check.F is not right (should be only if 
> GM_InMomAsStress=T) and I am going to change this.
> 
> There are also few combinations that should have a stop, such as:
> a) GM_AdvForm=T & GM_InMomAsStress=T but #undef ALLOW_EDDYPSI :
>   in this case, GM is dropped (even if GM_background_K > 0).
> b) #define ALLOW_EDDYPSI and #define ALLOW_GMREDI but useGMRedi=F
>  In this case, if we are lucky, we don't get the contributions from 
>  taueddy_external_forcing (eddyPsiX,eddyPsiY are ignored) whereas we do get
>  them if ALLOW_GMREDI is undef ; and if the are not lucky, since 
>  GM_InMomAsStress is not initialised, it might be =T 
>  and then uninitialized GM_psiX,Y are added to gU,gV (might give random 
>  results).
> 
> This might be a reason to keep #undef ALLOW_EDDYPSI if you are not
> using it (again, since there is not runtime parameter to control this).
> 
> Cheers
> Jean-Michel
> 
> On Tue, Feb 08, 2011 at 12:23:36PM -0500, Jean-Michel Campin wrote:
>> Hi Holly,
>> 
>> I am going to check this (but I remember that there was a 
>> serious problem related to this piece of code, but
>> not sure which part is safe to use).
>> 
>> Cheers,
>> Jean-Michel
>> 
>> On Tue, Feb 08, 2011 at 11:48:42AM -0500, Holly Dail wrote:
>>> Jean-Michel -
>>> 
>>> I've just updated to checkpoint 62R, and my simple forward run now fails because I am using GMREDI and have ALLOW_EDDYPSI set in my CPP_OPTIONS.h.  The following code in gmredi_check.F causes a failure in this configuration; this code is a new checkin from you, and I'm wondering if you could explain why EDDYPSI should not be compatible with GMREDI and/or how I should proceed ... many other places in GMREDI assume the possibility of having EDDYPSI set.  
>>> 
>>> 161    #ifdef ALLOW_EDDYPSI 
>>> 162           WRITE(msgBuf,'(A)') 
>>> 163         &   ' GMREDI_CHECK: Bug in ALLOW_EDDYPSI + GM-Redi' 
>>> 164           CALL PRINT_ERROR( msgBuf, myThid ) 
>>> 165           STOP 'ABNORMAL END: S/R GMREDI_CHECK' 
>>> 166    #endif
>>> 
>>> Thanks for the help!
>>> Holly
>>> _______________________________________________
>>> 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