[MITgcm-devel] ggl90_calc

[Martin Losch]

David,

I think that the ALLOW_GGL90_SMOOTH and ALLOW_GGL90_HORIZDIFF should  
really be exclusive options. The first (your addition) is a 9-point  
running average smoother, whereas the HORIZDIFF is in effect a 5-point  
smoother (but maybe a bit more physical).

what does mskCor do (as far as I can see, it's 1 everywhere)?
what's the rationale behind dividing by TKEPrantlNumber?

Martin

On Nov 2, 2009, at 2:36 PM, Martin Losch wrote:

> Hi Jean-Michel and David,
>
> here are my  comments (after a relatively quick glance);
> On Oct 31, 2009, at 4:31 AM, Jean-Michel Campin wrote:
>
>> Hi Martin and David,
>>
>> I look at S/R ggl90_calc.F (more precisely, to the implicit diffusion
>> of TKE) and noticed few thing that I don't like too much
>> (at least misleading, but some might also be more like a bugg).
>>
>> It's all checked-in as comments in the code ("C- jmc:"):
>>> danton{ggl90}% egrep '^C- jmc:' ggl90_calc.F
>>> C- jmc: concerned about missing a deltaT since gTKE is already the  
>>> future TKE.
> I agree, there is a deltaT missing. By default, the horizontal  
> mixing is turned off, and nobody ever noticed that it does not work  
> properly, maybe we don't even _want_ horizontal diffusion?
>>> C- jmc: concerned that a(k=2) should always be zero
>>> C- jmc: concerned that c(k) from k=kLow to k=Nr should always be  
>>> zero
>>> C- jmc: this is dangerous since klowC could be zero if land column
>>> C- jmc: concerned about conservation when a or c are changed after  
>>> computing b
> I agree, the implicit solver does not look clean (I remember that I  
> changed things around a lot before I got them working properly, but  
> that does not mean that they are actually correct). Maybe it's a  
> good idea to replace this code with a call of S/R solve_tridiagonal,  
> as you have already tried? I do not think that we can use impldiff  
> (which would even be better), because GGL90TKE is defined at the  
> cell interfaces (and not the cell centers as theta/salt/uVel/vVel).  
> What do you think.
>>> C- jmc: would be much better to update the provisional TKE (i.e.  
>>> gTKE) at k=2
> I don't understand this part, We do I want to impose the surface  
> boundary conditions below the surface?
>
> M.
>
> PS. More comment for David:
> I don't understand this:
>> C     GGL90 needs convection turned on, but keep warning message
>>      IF (cAdjFreq.NE.0.  .OR. ivdc_kappa.NE.0. ) THEN
>>         WRITE(msgBuf,'(A)')
>>     &  'GGL90_CHECK: WARNING: Some form of convection has been  
>> enabled'
>>         CALL PRINT_MESSAGE( msgBuf, errorMessageUnit,
>>     &                        SQUEEZE_RIGHT , myThid)
>>      ENDIF
>
> Do you want to use GGL90 along with convective adjustment or the  
> "implicit diffusion" convection scheme? I think that the stop  
> statement should go back in and that the comment should read
>> C     GGL90 needs other types of parameterized convection (i.e.  
>> convective adjustment and "implicit diffusion") to be turned off
>
> Also it would be nice if you could include some comments about the  
> different choices for the mixing length. Would be nice if I know  
> what choices I have and what they mean (instead of just 0-3).
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel