[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030422: 20030421: Problem trying to create hourly surface LI

Kevin,

If you are seeing empty areas in the contour plots, then its likely that 
your grid spacing is too small (probably for the upper air data) such that 
you don't have at least three data points within the barnes search radius
for a given point. You can use the /EX (extrapolate) flag to the search 
radius as well.

You can use OAGRID with the upper air data, and use the resultant grid file
for both oabsfc and oabsnd (since the upper air is the coarser of the data
sets). Again, once you know the grid size you want, you can just bypass the
OAGRID step all together and use GDCFIL....which would make your script much 
faster.

Steve Chiswell


>From: "Kevin Polston" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200304222135.h3MLZL7U022075

>Hey Steve,
>
>Well I had a small amount of success in trying to do the computations with the
>  grid
>files.  I ran OAGRID on the surface and upper air data but gave it a different
>  output
>file name. However....when I ran OABSFC and OABSND I kept the same grid name f
> or the
>output for both programs. I wasn't sure if that would work (thinking one would
>overwrite the other) but apparently that didn't happen....so that was good. I 
> ran
>GDPLOT2 and ran a couple of different calculations to try and subtract the hou
> rly
>surface data from the 00Z observed 500 MB data. I did get some output but it w
> asn't
>quite what I expected.  First let me say I saw no errors so that was a positiv
> e step
>and I was excited to see the output (I was saving it as a VGF file to overlay 
> on
>imagery in NMAP2). However....when I displayed the vgf file I had what I would
>  call
>"attempts at contours". For instance....I had 3 lines close together in like s
> w
>Mississippi and then a couple of other lines Virginia. These lines weren't
>connected....they were very incomplete.....I guess short line segments is a be
> tter way
>of describing it. Now they were in the "right" areas I would have expected to 
> see
>negative LI values. It's just that it was very incomplete.  So I wasn't sure w
> hat to
>try next.  Here is how I tried running it from GDPLOT2 (and I am assuming I di
> d
>everything ok with the oagrid and oabsfc and oabsnd programs).
>
>GDFILE = /usr1/nawips.metdat/gempak/grids/sfcoagridn  (this is what I called t
> he
>combined grid)
>GDATTIM = 22/04 ( I used the time of the hourly observations)
>GLEVEL = 0
>GVCORD = none
>SCALE = 0
>GDPFUN = sub(tmpc@500%pres^00,ltmp^04)
>CINT = 2//0
>LINE = 19/15/1
>
>or I tried this function
>
>GDPFUN = sub(tmpc@500%pres^00,sub(tmst(sthe@0%none^04,500),273.16))
>
>They both produced similiar results.....meaning very short line segments and m
> uch
>incompleteness.
>
>I also tried using the GDBIINT program you suggested. I am having problems wit
> h it as
>well.  I save my RUC(ETA) data in this directory and filename structure:
>/usr1/nawips/metdat/gempak/grids/03042202_ruc_full.gem
>/usr1/nawips/metdat/gempak/grids/03042200_eta_211.gem
>
>I tried using the ETA data as well and each time I got an error that said time
>  not
>found for 030422/00 when I was trying to extract the 500mb temp from those mod
> el
>grids. I left the cpyfil line blank because I wasn't sure of what to put in
>there......could that have caused the problem or would that not have made any
>difference at all?
>
>I am going to continue experimenting with this but I hope you can give me some
>  more
>insight since apparently I am not quite there yet.  One thing did occur to me 
> though.
>I have been wanting to do time differences on the data (for instance, a 2, 3, 
> 6, or 12
>hour time change on certain parameters (such as temp, dewpoint, and
>pressure/altimeter).  It occurred to me that if I can keep adding to the gridf
> ile
>(like sfcoagridn in my example) that I would be able to do time changes very e
> asily.
>The gridfile would continue to grow for each hour but couldn't I just do this 
> the:
>
>GDPFUN  = sub(dwpf^03,dwpf^00)   (or for whatever parameter I had)
>
>if I continued to just add to the existing gridfile?  I think I can but I have
> n't
>tried it yet so I wasn't sure. I will get to it later this afternoon though an
> d give
>it a try. Also, I haven't worked my way to trying your suggestions yet to stop
>  the
>gplt processes. I want to get this other stuff working before I move on.  Than
> ks for
>all your help.
>
>Kevin Polston
>Senior Instructor, NWSTC
>Kansas City MO 64152
>
>816-880-9314 ext 273
>
>
>
>
>Unidata Support wrote:
>
>> Kevin,
>>
>> Gridfiles must have the same projections in order to
>> do computations on the grid points.
>>
>> When you run OAGRID, it will create a CED projection where the
>> KX;KY is determined from the station spacing. But, surface and
>> upperair data have different station spacing. You should use
>> GDCFIL instead of OAGRID so that you can specify the same grid
>> navigations (or just use the same output grid file for
>> oabsfc and oabsnd).
>>
>> When trying to do computations with surface and upperair with
>> model RUC data, you either have to grid your surface and upper air
>> data to the same navigation as the RUC file, or, you can use the
>> utility I created called "GDBIINT" to interpolate the necessary RUC
>> data fields to the other grid file projection).
>>
>> As far as running scripts from cron and avoiding gplt problems,
>> you should create a unique work directory for each script so that
>> files are not stepped on. In a csh for example, I typically
>> create a WORK directory such as:
>>
>> set WORKDIR=/tmp/gemwrk.$$
>> mkdir $WORKDIR
>> cd $WORKDIR
>> <do stuff>
>> gpend
>> cd /tmp
>> rm -rf $WORKDIR
>>
>> The $$ above will be replaced by the process id so that your gemglb.nts and
>> last.nts files are not stepped on by other scripts.
>>
>> Also, if you are using a single program, you can avoid the gplt processes by
>> using the _gf and _nc programs which are linked directly to the device drive
> r.
>>
>> Finally, when multiple scripts are invoked at nearly the same time, you coul
> d be
>> getting a race condition between the time when a message queue is asked for
>> and when it is opened....such that another program has also obtained the
>> same message queue id. If this is the case, then using a system of directory
>  locks
>> to ensure that each script secures its queue id before another script is
>> allowed to proceed may be the best course. I typically do this when invoking
>> scripts from the LDM since restarting the LDM can cause a flurry (hours of )
>> of data to come in and kick off scripts many times when normally, you may
>> expect the data to arrive perirodically (such as getting an hours worth
>> of nexrad data all at once, and expecting a gif to be generated for each.
>>
>> Steve Chiswell
>>
>> >From: "Kevin Polston" <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200304212103.h3LL3S7U017481
>>
>> >Hi,
>> >
>> >I've got a problem and I need some help. I am trying to create an hourly su
> rfa
>> > ce
>> >lifted index using the observed 12Z or 00Z 500mb temps and also by using th
> e R
>> > UC
>> >model's 500 mb temps as a "better" version of the hourly sfcli.  My problem
>  is
>> >  I
>> >cannot seem to get the grids set up properly to do the calculation.
>> >
>> >Here are the steps I have followed so far:
>> >
>> > - on the hourly surface obs I run oagrid and create the LTMP and STHE
>> >parameters.  Then I run the OABSFC program with the same two parameters....
> sav
>> > ing
>> >this to a grid file.
>> >
>> >- For the observed upper air obs...I also run OAGRID, setting my level to 5
> 00
>> > and
>> >my coordinate system to PRES and the paramter is TMPC. I save that to a dif
> fer
>> > ent
>> >grid file than what I saved the surface grid file to.
>> >
>> >- My next step was to try and merge the two data sets. I used the GDDIAG pr
> ogr
>> > am
>> >and I believe I succesfully merged the two files. However.....when I ran GD
> PLO
>> > T2
>> >to actually do the calculation.....it didn't work. I was trying to subtract
>  th
>> > e
>> >sfc LTMP at 16Z  from the TMPC at 500 mb at 12Z but the error message was t
> hat
>> >  it
>> >couldn't find the time  for the TMPC at 16Z.  I thought I had used the inli
> ne
>> >parameters properly to specify the height, level and time for the 500 mb TM
> PC
>> > but
>> >apparently I am doing something wrong. I have tried many times but I seem t
> o k
>> > eep
>> >hitting snags . From what I have read from the manual about GDDIAG it seems
>  li
>> > ke
>> >it would be relatively simple to create another grid (surface or upper air)
>  an
>> > d
>> >then add it to the existing grid.  But when I try the calculation that is w
> her
>> > e
>> >the problem comes in.
>> >
>> >I have a similar problem when I am trying to use my latest RUC file to crea
> te
>> > a
>> >surface hourly LI. I have no problems gridding the surface data but how exa
> ctl
>> > y do
>> >I extract the 500 mb TMPC from the RUC?  I thought I had done it right one 
> tim
>> > e
>> >but I got an error message stating I had different grid sizes. Well, I like
>  my
>> >current grid area and would not want to change it.  What do I need to do to
>> >extract the 500mb RUC TMPC and then put it into my surface grid to create t
> he
>> >hourly sfcli?
>> >
>> >Another problem I have noticed ....and it might be related to the version o
> f L
>> > inux
>> >I am running.....is that when I run these scripts manually from a command p
> rom
>> > pt
>> >they run perfectly. When I stick these scripts into the cron....they will r
> un
>> > for
>> >an hour or two and then I will have a buttload of msqid processes that prev
> ent
>> >  the
>> >gempak programs from running. I am running GPEND at the end of my scripts. 
> Why
>> >  is
>> >this happening and is there anyhting I can do about it?  It is annoying and
>> >baffling why it would run from the command line prompt just fine and not cr
> eat
>> > e
>> >any residual msqid processes but stick it into the cron and then it happens
> . I
>> >  am
>> >currently running Redhat Linux 7.3.
>> >
>> >I would appreciate your help with this.  Thanks.
>> >
>> >Kevin Polston
>> >Senior Instructor, NWSTC
>> >Kansas City MO 64152
>> >
>> >816-880-9314 ext 273
>> >
>>
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service              http://my.unidata.ucar.edu/content/support 
>> ****************************************************************************
>