Project

General

Profile

ml2pl issues: possibly erroneous values at 1000mb layer with extrapolation turned on; two warning messages

Added by Luke Davis about 6 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!


Replies (1)

RE: ml2pl issues: possibly erroneous values at 1000mb layer with extrapolation turned on; two warning messages - Added by Uwe Schulzweida about 6 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".

    (1-1/1)