[Mitgcm-support] KPP units

mitgcm-support at dev.mitgcm.org mitgcm-support at dev.mitgcm.org
Wed Jul 9 15:44:24 EDT 2003


Armin, I am copying the following reply to the rest of group because it's
important to agree on units and signs of forcing variables.

>> The problem of KPP in ecco_c30 was that ecco_c30's heatflux is in W/m2
>> while KPP expects deg/s. A further difference is a factor 0.01 in ustar.

>> the factor 0.01 for ustar is found, new definition for ecco forcing
>> is now
>>             ustar(i,j) = SQRT( SQRT(
>>      &           (fu(i,j,bi,bj) + fu(ip1,j,bi,bj)) * p5  *
>>      &           (fu(i,j,bi,bj) + fu(ip1,j,bi,bj)) * p5   +
>>      &           (fv(i,j,bi,bj) + fv(i,jp1,bi,bj)) * p5  *
>>      &           (fv(i,j,bi,bj) + fv(i,jp1,bi,bj)) * p5)*recip_rhoNil )

The tentative agreement we reached with Alistair is that "units" and "signs"
for forcing variables that are made available by common block FFIELDS should
be that of model tendency terms: gu, gv, gt, and gs.  This is what the KPP
routines assume.  This is also consistent with definitions of forcing
variables in FFIELDS.h of c30 and ecco_c30.

C     fu     - Zonal velocity tendency term (converted to m/s^2)
C     fv     - Meridional velocity tendency term (converted to m/s^2)
C     Qnet   - Surface heat flux (converted to degrees/second)
C     Qsw    - Short-wave surface heat flux (converted to degrees/second)
C     EmPmR  - Evaporation - Precipitation - Runoff (converted to psu/second)

To follow this convention you would need to modify ecco_c30 forcing routines,
not kpp_calc.F.  I don't mind using a different convention, if that becomes
the general consensus, but it's dangerous to have different versions of the
code using different units.

Dimitris




More information about the MITgcm-support mailing list