[Wrfems] Bad Skin Temperature Error in EMS V3
rozumal at ucar.edu
Wed Sep 9 09:20:58 MDT 2009
First, I've CCd the EMS users and clarified the nature of the problem in
the subject line since this is of interest to some users
and a bane to others
The problem you've encountered is one that has manifested itself in a
variety of ways and has no real robust solution, just workarounds.
So summarize, the problem is that ems_run is failing while running the
WRF "real.exe" program, which takes
all the meteorological data and creates the model initial and boundary
Specifically, the error message you are seeing,
DYNAMICS OPTION: Eulerian Mass Coordinate
d01 2009-09-09_06:00:00 Timing for input 0 s.
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: module_initialize_real.b LINE: 1166
NOTE -> grid%tsk unreasonable
was caused because a skin temperature value(s) was found to be below a
predefined minimum. The skin temperature
is one of the most important fields as it defines the temperature of
the model surface, i.e, SST over water points and ground
(NOT 10m) temperature over land points. This field partially controls
the surface fluxes in the model.
In your case the model was initializing the skin temperature over water
points as 0 kelvin, which is somewhat of an atypical
condition in the real world. Thus, the model was crashing.
"So why is this happening to me?"
To understand why this problem occurs requires an explanation of how the
WRF preprocessor initializes water points, and more
importantly, smaller lakes and rivers that are included in your
simulation. This questions has been asked a few times by users
and I have not provided a detailed answer, but I'm in the typing mood so
here it goes in semi comprehendable bullet form:
A. Some fields in the model are masked, that is values are valid over
only a portion of the domain. The best example of a
mask is the land mask, which uses 1s for land points and 0s for
water points (usually). An example of a masked field
would be SST where values over water points are valid while those
over land are invalid.
B. Some masked fields, such as SST have realistic values over invalid
regions while others may use values such as 0 or
10**-30. It depends on the data set. Those that use realistic
values are easier to work with as there is some room for
error during the data set -> initial conditions interpolation
process. Data sets with non-physical values can be problematic
but that is another discussion.
C. When you create a computational model domain in which the
resolution is greater than that of the data set(s) used
to generate the initial conditions, you may also introduce bodies
of water (lakes, rivers, hot tubs) that are not resolved
in the initialization data set(s). The grid spacing of your
computational domain is 6km while the NAM data set used to
initialize your run is 12km. What potentially exacerbates this
problem is that NCEP removes some smaller 1 and 2-point
bodies of water that may actually be resolved at 12km. This make
for cleaner forecast products.
D. The NAM does include the SST temperatures as part of the skin
temperature field. The WRF knows these are to
be used as SST values because the included NAM land mask (1=land
0=water) defines which values to use as water
temperatures and which to use for the skin temperature field.
E. So, in your 6km domain, you have lakes and rivers that are not
present in the 12km NAM data. The NAM skin temperature
field is used to initialize the WRF skin temperature over all
the LAND points, but what about the water points in your domain
that are defined as LAND in the NAM?
Remember that the NAM does not know about your small water
points and thus the derived SST field does not apply
to these areas.
F. This is how the WRF works to initialize model skin temperatures
over water points:
1. It uses VALID values from an existing SST field included
as part of the initialization data set. The SST values may
come from the 12KM NAM (but there isn't an independent
SST field) or another source such as MODIS or the high
resolution SST data set like ssthr.
One problem with MODIS data is that even though the grid
spacing is ~2km, small body water points over the CONUS
are defined as invalid.
2. If no valid water temperatures are available from an SST
field, the WRF will USE THE CLOSEST AVAILABLE WATER
POINT IN THE INITIALIZATION DATA SET. This means that a
water temperature from the Gulf of Mexico could
be used to initialize your small lake in Kansas!! Hey,
it might not be exact but it is a start; however, because
the water temperatures are held fixed (In the current
release) during the simulation, this might be a problem.
But, what if there are NO water points available from
your initialization data set? Normally this is not the case as both the GFS
and the NAM have regions defined as water, like the
oceans, but when you are using personal tiles your are only getting
a subset of the full NAM or GFS data set. Consequently,
your may not have ANY water values in your initialization data set
This is where the WRF fails to provide your lonely small
bodies of water with some temperature love, and thus, when the
water point temperatures are used to create the skin
temperature field, the values are 0 and you run goes nowhere.
Note that if you use the full nam218 grid your run will
start successfully, this is cause the WRF can grab an SST
value from the Gulf to use. But this is not a solution
for those on a bandwidth budget.
F. So what's a confused modeler to do? Possible workarounds include:
1. Use a primary initialization data set that has water
coverage (E.g. Full NAM 218).
2. Include an secondary SST data set that does not have
invalid or masked values over land (MODIS masks values).
The 8 degree high resolution SST data set can be used
(--sfc ssthr) for this purpose.
3. Edit the wrfems/data/tables/wps/METGRID.TBL.ARW (or
METGRID.TBL.NMM) file and change:
mandatory=yes # MUST HAVE THIS FIELD
interp_land_mask = LANDSEA(1)
interp_water_mask = LANDSEA(0)
fill_missing=0. <-- Change to some realistic water
temperature value such as 290
Note that the last workaround should only be done as a last
resort. It will set ALL previously undefined water temperatures
to the specified value (290).
G. I will modify the WRF code in the V3.1 release so this problem
does not happen again. I think the best approach
would be if should no other source of SST temperatures be
available, use the closest available skin temperature over LAND.
This has it's own problems as small body water temperatures
will be dependent upon the adjacent land temperatures, and may
have issues in the winter (frozen Vs open water), but it will
allow the runs to start.
There are more robust solutions, one which involves allowing users to
manually specify the temperature and/or state (open or frozen) of
each water point in the domain. You could eliminate points as well, or
just add new ones! This would require a lot of effort though.
I'm open to other suggestions.
jeremy martin wrote:
> Mr Rozumalski,
> We recently updated our workstation WRF to version 3 and I have ran
> into kind of a strange problem. We run two different domains here, one
> for operational uses and a smaller domain we use to test out different
> parameterizations, resolutions etc.
> The operational run works fine, but when running my test domain it
> crashes while making the initialization grids. I have attached the
> run_realrun.log that has the error. I am pretty sure I did not modify
> anything from the default autorun and prep conf files, which should be
> identical to the operational run that works fine, so I cannot really
> figure out what the problem may be. I am guessing it is user error on
> my part, but was hoping that you may have seen this error before.
> Thanks for your time,
> Jeremy Martin
Robert A. Rozumalski, PhD
NWS National SOO Science and Training Resource Coordinator
COMET/UCAR PO Box 3000 Phone: 303.497.8356
Boulder, CO 80307-3000
More information about the Wrfems