[MITgcm-devel] gmredi_check.F

[Jean-Michel Campin]

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