[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