[Wrf-users] landuse, tmn, changing to land points

Michael John Shaw michaejs at cires.colorado.edu
Fri Nov 10 09:57:52 MST 2006


As some follow up on this post, my understanding is that seaice
points are converted to land points from water points, and then considered
silty clay loam.  Does anyone have an idea of whether that matters with,
e.g., Noah LSM?  I would imagine that considering seaice silty clay loam
could be an issue considering they're very different thermally,
hydraulically, etc.  I suspect the lu_index of 24 (or 0, depending on
physics it seems according to the output files, anyhow) would result, in
the model, in treatment as ice with accompanying thermal and hydraulic
properties, albedo, etc..  True?

It does appear that TMN makes sense for both input and output, despite
the startling number of "error" messages.  It does appear that the error
messages are resulting from the water points that were converted to land
points where there is seaice, but there is no reservoir temperature per
se, so TSK is used to estimate a TMN for such points, resulting in
fictitious temperatures within the domain.

Still wondering if anyone has a sense of why lu_index is 24 (or 0,
depending on which physics options I use, it appears) for all seaice, and
1 for all other points (land, permanent ice other than seaice,
boreal forest, sea surface...everywhere there's no seaice) in the output
files, and what field in the wrf_real_input files is being used to assign
lu_index (or if there should be some land use index in the wrf_real_input
files that for some reason I do not have - vegcat looks like landuse to
me).

I'm using ncep 1 or ncep 2 reanalysis data for forcing, and both
mm5pconvert and wrfsi for preprocessing.  Let me know if it'll help to
know more platform specifics and version numbers, etc..

Thanks.




On Wed, 8 Nov 2006, Michael John Shaw wrote:

> Hi.
>
> I have a few questions.
>
> First, lu_index seems to only indicate seaice versus non-seaice in my
> output, and like seaice is incorporated as "permanent ice".  It does not
> appear that there is another reasonable landuse variable to check this
> (xlus e.g.?) in my output or input files.  It does appear that vegcat
> could serve as landuse, though from a quick look into the code, it looks
> more like lu_index is important to have correct.  Incidentally, the
> output file indicates that mminlus is "USGS" (if I ncdump, e.g.), at
> least when I've tried using ncep1 data (which was processed with
> mm5pconvert), but not with ncep2 data (which was processed
> with wrfsi all the way through).  Perhaps relatedly, this is echoed by
> wrf:
>
>
>
> WRF V2.1.1 MODEL
>  DYNAMICS OPTION: Eulerian Mass Coordinate
>  med_initialdata_input: calling input_model_input
>  INPUT LANDUSE =
>  LANDUSE IN INPUT FILE DOES NOT MATCH LUTABLE: TABLE NOT USED
>  INITIALIZE THREE Noah LSM RELATED TABLES
>   INPUT LANDUSE = USGS
>   LANDUSE TYPE = USGS FOUND           27  CATEGORIES
>   INPUT SOIL TEXTURE CLASSIFICAION = STAS
>
>
>
> which seems to indicate that there is a landuse mismatch, yet USGS landuse
> IS being obtained.  Any thoughts on this?
>
> I also get lots of tmn errors echoed by real.exe, yet my tmn looks ok in
> output.  In the input files (wrf_real...), tmn looks very different
> from the output values - it's a nearly uniform field that gets
> slightly cooler toward the pole.  The errors are, e.g.,
>
>
>
> i,j=            5           11
>  landmask=    1.000000
>  tsk, sst, tmn=    273.1546        273.1154        0.000000
>  error in the TMN
>  is the echo by real.exe.
>
>
>
> Any thoughts?
>
> Finally, real.exe echoes a bunch of this:
>
>
>
>  changing to land at point             6           10
>   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18 19
> 20  21  22  23  24
>   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  0
> 0   0   0   0   0
>
>
>
> followed immediately by this:
>
>
>
> forcing artificial silty clay loam at 2035 points, out of   3726
>
>
>
> Any thoughts?  I'd love to get some feedback before digging much more into
> the code, e.g..
>
> It is hard to tell from any other output whether landuse is being properly
> utilized (though lu_index being such a mess does not look like a good
> sign!).
>
> Thanks.
>
> _______________________________________________
> Wrf-users mailing list
> Wrf-users at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/wrf-users
>




More information about the Wrf-users mailing list