ml2pl issues: possibly erroneous values at 1000mb layer with extrapolation turned on; two warning messages
Added by Luke Davis about 8 years ago
I have included an "orig" file (data on model levels), an "interp" file (data on interpolated levels), and a "diff" file (temperature-difference between the files). I am concerned about the big values I see in "4xdaily_inst_diff.nc" at 1000mb -- it looks almost like a discrete jump going from the 975mb level to the 1000mb level -- check it out in ncview/panoply.
Anyway on to the warning messages:
1. "Surface geopotential has an unexpected range (min=0 max=0)": My model has perfectly flat topography so I create a "zs" variable that contains nothing but zeros (because my lowest model half-level is always at sigma=1, i.e. at the sea-level surface). I checked the source code and found these lines:
if ( gridsize > 1 && minval >= 0 && maxval <= 9000 )
cdoWarning("Surface geopotential has an unexpected range (min=%g max=%g) [timestep:%d]!", minval, maxval, tsID+1);
...so, why would the surface geopotential range be expected to be outside of [0m2/s2, 9000m2/s2], and this is an error if not? Could this be causing weird values at the near-surface layer.
2. "VCT is empty": I looked at the source code and saw the lines
if ( !(suma>0&&sumb>0) ) cdoWarning("VCT is empty!");
so I guess the fact that my hybrid-a levels are zero raises the error. Seems like this error message could be improved.
Thanks in advance!
| 4xdaily_inst_interp.nc (8.82 MB) 4xdaily_inst_interp.nc | |||
| 4xdaily_inst_diff.nc (1.25 MB) 4xdaily_inst_diff.nc | |||
| 4xdaily_inst_orig.nc (8.82 MB) 4xdaily_inst_orig.nc |
Replies (1)
RE: ml2pl issues: possibly erroneous values at 1000mb layer with extrapolation turned on; two warning messages - Added by Uwe Schulzweida about 8 years ago
Thanks for your input, we have improved the error message!
The temperature is indeed handled in a special way on the last level. Here is the code for this level:
double
extra_T(double pres, double halfp, double fullp, double geop, double temp)
{
double peval;
const double zlapse = 0.0065;
const double zrg = 1.0 / PlanetGrav;
double tstar = (1.0 + zlapse * PlanetRD * zrg * (halfp / fullp - 1.0)) * temp;
const double ztsz = tstar;
const double z1 = tstar + zlapse * zrg * geop;
if (tstar < 255.0) tstar = 0.5 * (255.0 + tstar);
double ztmsl = tstar + zlapse * zrg * geop;
if (ztmsl > 290.5 && tstar > 290.5)
{
tstar = 0.5 * (290.5 + tstar);
ztmsl = tstar;
}
if (ztmsl > 290.5 && tstar <= 290.5) ztmsl = 290.5;
if (pres <= halfp)
peval = ((halfp - pres) * temp + (pres - fullp) * tstar) / (halfp - fullp);
else
{
double ztmsl = z1;
tstar = ztsz;
const double zhts = geop * zrg;
if (zhts > 2000. && z1 > 298.)
{
ztmsl = 298.;
if (zhts < 2500.) ztmsl = 0.002 * ((2500. - zhts) * z1 + (zhts - 2000.) * ztmsl);
}
double zalph;
if ((ztmsl - tstar) < 0.000001)
zalph = 0.;1
else if (geop > 0.0001 || geop < -0.0001)
zalph = PlanetRD * (ztmsl - tstar) / geop;
else
zalph = PlanetRD * zlapse * zrg;
double zalp = zalph * log(pres / halfp);
peval = tstar * (1.0 + zalp * (1.0 + zalp * (0.5 + 0.16666666667 * zalp)));
}
return peval;
}
A workaround to switch of this special treatment is to renamed the variable t to something else and to remove the standard_name "air_temperature".