[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
19991216: model elevation question
- Subject: 19991216: model elevation question
- Date: Fri, 17 Dec 1999 14:24:18 -0700
Matt,
the error message implies that the terrain.gsf data file
is not being found. Since you know that the file does exist,
you might need to verify that:
1) Your file permissions allow you to access the file from the
path.
2) The line in your script where you define
TOPOFL = /data1/nawips-5.4/terrain/terrain.gsf
check for any typos in the path or hidden cntrl characters
(sometimes text editors can stick in a ^H or something if you backspace
and fudge a character).
3) try running the program interactively instead of from your redirection
to eliminate the above possibility.
Steve Chiswell
Unidata User Support
>From: "Matthew G. Fearon" <address@hidden>
>Organization: Desert Research Institute
>Keywords: 199912172026.NAA22512
>Steve,
>
>Thank you for this information. It will be very helpful to me.
>I followed all the procedures after retrieving the terrain.tar.Z
>file. I made a direct access binary file from the ascii as well. I
>received the normal completion message after running
>tercnvrt. When I run gdtopo however, I receive the following
>error
>
>$GEMEXE/gdtopo << EOF
> GDFILE Grid file $GEMDATA/HRCBOB.GRD
> GAREA Grid area WV
> GDATTIM Grid date/time LAST
> TOPOFL Topography file name
> Parameters requested: GDFILE,GAREA,GDATTIM,TOPOFL.
> GEMPAK-GDTOPO> GEMPAK-GDTOPO> GEMPAK-GDTOPO> GEMPAK-GDTOPO> GEMPAK-GDTOPO> [G
> DT
>OPO -12] Topography file does not exist.
> Parameters requested: GDFILE,GAREA,GDATTIM,TOPOFL.
> GEMPAK-GDTOPO> GEMPAK-GDTOPO>
>
>rm *.nts
>
>Here is my gdtopo program:
>
>$GEMEXE/gdtopo <<EOF
>GDFILE = us.west
>GAREA = 25;-125;45;-105
>GDATTIM = 990101/1200
>TOPOFL = /data1/nawips-5.4/terrain/terrain.gsf
>r
>
>exit
>
>EOF
>
>#$GEMEXE/gpend
>rm *.nts
>
>The terrain.gsf file does exist. Do you know what may be
>the problem ? Please reply at your convienence. Thank you
>again for all your help.
>
>Matt Fearon
>address@hidden
>
>
>
>
>Unidata Support wrote:
>
>> Matt,
>>
>> All models use some smoothed form of surface data since using
>> terrain data at a higher resolution than the grid and/or large
>> discontinuities inadjacent grid point values will cause the model
>> to blow up with anomalous gravity waves and non-hydrostatic
>> forcing.
>>
>> The ETA model employs a step terrain. There are some points about
>> the difference in actiual station elevation and the model elevation in
>> the 32km ETA whitepaper at:
>> http://www.nws.noaa.gov/om/447body.htm
>>
>> You can also look at the FSL RUC 40km topography at:
>> http://maps.fsl.noaa.gov/40kmtopocol.gif
>> They also have ascii 40km and 60km topography datasets for download at:
>> http://maps.fsl.noaa.gov/MAPS.domain.cgi
>>
>> We do have a 5 minute (approx 10km) gridded topography dataset for
>> Gempak which you can use as a gridded data set (eg gdlist, gdpoint etc).
>>
>> To use the gempak terrain dataset, download from the gbuddy ftp account
>> nawips-5.4/contrib/terrain.tar.Z
>>
>> and unpack on your system with:
>>
>> zcat terrain.tar.Z | tar xvf -
>>
>> This will create a directory called terrain which containe
>> the ascii terrain data set (63 Mb) and a program directory called
>> gdtopo which can be used to convert the data into a gempak
>> grid file.
>>
>> First you need to convert the ascii terrain file into a direct access
>> file (like a gempak map datafile). To do this, you need to build the
>> tercnvrt program from the fortran code with:
>>
>> f77 -o tercnvrt tercnvrt.f
>>
>> Then run tercnvrt to create the direct access file, eg:
>>
>> prompt% tercnvrt
>>
>> Please enter name of original terrain dataset: terrain.ascii
>> ^^^^^^^^^^^^^
>> Now enter name of file which will
>> contain sector of terrain data: terrain.gsf
>> ^^^^^^^^^^^
>>
>> Now build and install gdtopo by cd'ing into the gdtopo directory
>> and building with:
>>
>> make all
>> make install
>> make clean
>>
>> (This will install the gdtopo program into the $GEMEXE directory and
>> install the ancillary pdf files as well).
>>
>> Now you can create a grid file for some area. Since the maximum number of
>> grid points by default in a gempak grid file is ~97,000 points, this
>> is approximately 311x311 grid points (for the 5 minute data set this is
>> roughly 25 degrees x 25 degrees). In otherwords, even though the database
>> covers the entire globe, you can only view a 25 degree square at a time
>> as a gempak grid file. As an example, I created a file called us.west
>> in the terrain subdirectory that is a 20x20 degree file (garea =
>> 25;-125;45;-105) as an example which you can use.
>>
>> To create your own grid file area, run gdtopo:
>>
>> GDFILE = us.west
>> GAREA = 25;-125;45;-105
>> GDATTIM = 990101/1200
>> TOPOFL = terrain.gsf
>> GEMPAK-GDTOPO>r
>>
>> The gdattim is only used to create a grid time in the output file but
>> really doesn't do anything else.
>>
>> An example of running gdcntr with the us.west grid file that is produced:
>> GDATTIM = 990101/1200
>> GLEVEL = 0
>> GVCORD = pres
>> GFUNC = topo
>> GDFILE = us.west
>> CINT = 200
>> LINE = 5/1/1/0
>> MAP = 6
>> TITLE = 1
>> DEVICE = ps
>> SATFIL =
>> RADFIL =
>> PROJ = ced
>> GAREA = grid
>> CLEAR = y
>> PANEL = 0
>> TEXT = .5
>> SCALE = 0
>> LATLON = 7/10/1//1;1
>> HILO =
>> HLSYM =
>> CLRBAR =
>> CONTUR = 0
>> SKIP = 0
>> FINT = 200
>> FLINE = 30-7
>> CTYPE = c
>> LUTFIL =
>> STNPLT =
>> GEMPAK-GDCNTR>r
>> Creating process: ps for queue 251454
>>
>> Grid file: us.west
>> GRID IDENTIFIER:
>> TIME1 TIME2 LEVL1 LEVL2 VCORD PARM
>> 990101/1200 0 PRES TOPO
>>
>> GAREA: grid
>>
>> MINIMUM AND MAXIMUM VALUES -4765.00 3790.00
>>
>> LINE CONTOURS:
>>
>> LEVELS: -4600.00 -4400.00 -4200.00 -4000.00 -3800.00 -3600.00 -3400.00
>> COLORS: 5 5 5 5 5 5 5
>> LINTYP: 1 1 1 1 1 1 1
>> LINWID: 1 1 1 1 1 1 1
>> LABEL: 0 0 0 0 0 0 0
>>
>> LEVELS: -3200.00 -3000.00 -2800.00 -2600.00 -2400.00 -2200.00 -2000.00
>> COLORS: 5 5 5 5 5 5 5
>> LINTYP: 1 1 1 1 1 1 1
>> LINWID: 1 1 1 1 1 1 1
>> LABEL: 0 0 0 0 0 0 0
>>
>> LEVELS: -1800.00 -1600.00 -1400.00 -1200.00 -1000.00 -800.00 -600.00
>> COLORS: 5 5 5 5 5 5 5
>> LINTYP: 1 1 1 1 1 1 1
>> LINWID: 1 1 1 1 1 1 1
>> LABEL: 0 0 0 0 0 0 0
>>
>> LEVELS: -400.00 -200.00 0.00 200.00 400.00 600.00 800.00
>> COLORS: 5 5 5 5 5 5 5
>> LINTYP: 1 1 1 1 1 1 1
>> LINWID: 1 1 1 1 1 1 1
>> LABEL: 0 0 0 0 0 0 0
>>
>> LEVELS: 1000.00 1200.00 1400.00 1600.00 1800.00 2000.00 2200.00
>> COLORS: 5 5 5 5 5 5 5
>> LINTYP: 1 1 1 1 1 1 1
>> LINWID: 1 1 1 1 1 1 1
>> LABEL: 0 0 0 0 0 0 0
>>
>> LEVELS: 2400.00 2600.00 2800.00 3000.00 3200.00 3400.00 3600.00
>> COLORS: 5 5 5 5 5 5 5
>> LINTYP: 1 1 1 1 1 1 1
>> LINWID: 1 1 1 1 1 1 1
>> LABEL: 0 0 0 0 0 0 0
>> Enter <cr> to accept parameters or type EXIT:
>>
>> I hope this helps you with your work.
>>
>> Steve Chiswell
>> Unidata User Support
>>
>> >From: "Matthew G. Fearon" <address@hidden>
>> >Organization: Desert Research Institute
>> >Keywords: 199912170024.RAA17299
>>
>> >Steve,
>> >
>> >I attached my question below. I just figure I would mention briefly
>> >what I am trying to accomplish first.
>> >
>> >I have created a text file of 40km eta model hght@0%none field or
>> >what is consider the ground surface in the eta model. I have done
>> >this for each grid point for the entire eta grid and each hght has a
>> >corresponding latitude and longitude. I then compared the true
>> >ground surface of certain sounding stations to the heights
>> >from the eta model by locating the closet lat/lon relationship. From
>> >this comparison, I am noticing that the eta heights are always quite
>> >higher than the true ground surface of the sounding sites, except for
>> >FSX which is lower. I attached a list below, the heights are in meters:
>> >
>> >stn sounding eta
>> >RNO 1341.5 1776.8
>> >UIL 54.880 229.29
>> >OAK 3.0500 109.45
>> >FSX 2134.1 1740.0
>> >EKO 1551.8 1872.2
>> >BOI 871.95 1371.6
>> >DEN 1612.8 2238.7
>> >TUS 786.59 1084.6
>> >GGW 695.12 832.76
>> >
>> >Do you know if there is a prewritten grid file containing the true
>> >ground
>> >surface elevation (hgt above mean sea level) that I could match to the
>> >lat/lons that are available from the 40km eta ?
>> >
>> >Your suggestions would be greatly appreciated.
>> >Thank you in advance,
>> >
>> >Matt Fearon
>> >address@hidden
>> >
>> >
>>
>> ****************************************************************************
>> Unidata User Support UCAR Unidata Program
>> (303)497-8644 P.O. Box 3000
>> address@hidden Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service http://www.unidata.ucar.edu/
>> ****************************************************************************
>
