[Wrfems] Bad Skin Temperature Error in EMS V3

Robert Rozumalski 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 
               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 mailing list