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

20011025: 20011023: 20011022: 20011019: gempak ltg gridding


Brian,

You can go the way of the old MDR radar products where a grid is overlayed
and if a strike occurs in the box, you count it. That is slightly different 
than calculating the probability of a strike occuring within some distance 
of a location - which is what the radius count does. 

The difference being the probability of a strike within a certain region
(eg grid box), or the probability of a strike within X meters (more like
the way hurricane landfall probabilities are computed.

The way to do the former is to use the gtrans() function and
translate all the lat/lon locations of the strikes from M (map space)
to grid point locations (G). So, if a strike location interpolates to
grid point space 45.7;83.1, you would increment the count
of the grid point 46;83. You would have to assume the .5 rounds up
or down in all cases to handle the case where the point lands on x.5 or y.5.

In GDCFIL, you choose the KX;KY and projection accordingly to control the
shape of the grid cell. a CED projection will have a constant dlat and dlon
(though dx converges poleward....the effect of a non flat earth).

Steve Chiswell
Unidata User Support







>From: Brian Colle <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200110252137.f9PLbI110690

>
>Steve,
>
>
>I tried the programs and they seem to work; however I ran into a couple of
>specific problems related to my application. The idea of counting stations
>using a radius parameter is not completely accurate for a regularly spaced
>grid since if you make the radius equal to the grid spacing (dx) some
>lightning strikes are not counted, or > dx some lightning is counted twice
>for 2-4 other grid points. It seems the most accurate way of doing this
>problem is using squares around each grid box, but this may be a much
>more difficult problem logistically looking at your code?? The other
>approach to minimize this radius error is to decrease the grid spacing,
>but the file size increases dramatically.
>
>Also, how can we setup our grid to have uniform distance in the x,y (still
>able to plot a map) such that the radius is applied equally in all
>dimensions. 
>
>Thanks again for your help.
>
>Brian
>
>On Wed, 24 Oct 2001, Unidata Support wrote:
>
>> 
>> Brian,
>> 
>> I have created a program called GDOBSCNT that will find the
>> number of observations within a specified radius of each grid
>> point and store the grid as parameter ODEN@0%none for each 
>> time specified from the input surface file.
>> 
>> You can download the tarfile from:
>> http://www.unidata.ucar.edu/packages/gempak/contrib/gdobscnt.tar.Z
>> 
>> In your GEMPAK 5.6 $NAWIPS directory, unpack the tarfile with:
>> 
>> zcat gdobscnt.tar.Z | tar xvf -
>> 
>> Then build and install with:
>> 
>> cd $NAWIPS/unidata/programs/gdobscnt
>> make clean
>> make all
>> make install
>> make clean
>> 
>> 
>> To use the program, you should first create your grid file with your 
>> required grid spacing using GDCFIL. 
>> 
>> The program uses 4 parameters. SFFILE, DATTIM, GDFILE, RADIUS.
>> SFFILE is your input surface (NLDN) file. GDFILE is the
>> file for the grids to be stored. DATTIM is the times
>> (a list, range, single, or all) from the surface file
>> to process. RADIUS is the range, in meters, from the
>> each grid point that stations will be counted.
>> 
>> The result is a grid called ODEN for each time specified
>> by DATTIM.
>> 
>> For example, using today's 1630Z NLDN file (which contains
>> nldn bins at 5 minute intervals from 1630Z to 1655Z), and a grid 
>> file I have already created called test.grd specifying a 50KM
>> radius (50000m):
>> 
>> % gdobscnt
>>  SFFILE    Surface data file                 nldn|011024/1630
>>  DATTIM    Date/time                         all
>>  GDFILE    Grid file                         test.grd
>>  RADIUS    Radius (in meters) to search      50000
>>  Parameters requested: SFFILE,DATTIM,GDFILE,RADIUS.
>>  GEMPAK-GDOBSCNT>r
>>  Processing 011024/1630    
>>  Processing 011024/1635    
>>  Processing 011024/1640    
>>  Processing 011024/1645    
>>  Processing 011024/1650    
>>  Processing 011024/1655    
>>  Parameters requested: SFFILE,DATTIM,GDFILE,RADIUS.
>>  GEMPAK-GDOBSCNT>e
>> 
>> I can then plot the data, with grid point values and contous in GDPLOT2
>> with:
>>  GDFILE   = test.grd
>>  GDATTIM  = 1630-1655
>>  GLEVEL   = 0
>>  GVCORD   = none
>>  PANEL    = 0
>>  SKIP     = 0
>>  SCALE    = 0
>>  GDPFUN   = ODEN
>>  TYPE     = cm
>>  CONTUR   = 0
>>  CINT     = 0
>>  LINE     = 3
>>  FINT     = 
>>  FLINE    = 
>>  HILO     =  
>>  HLSYM    =  
>>  CLRBAR   = 1
>>  WIND     = 
>>  REFVEC   =  
>>  TITLE    = 1
>>  TEXT     = 1
>>  CLEAR    = y
>>  GAREA    = 34.0;-95.2;43.7;-79.2
>>  PROJ     = LCC/25.0;-90.0;25.0
>>  MAP      = 1
>>  LATLON   = 0
>>  DEVICE   = XW
>>  STNPLT   =  
>>  SATFIL   =  
>>  RADFIL   =  
>>  LUTFIL   =  
>>  STREAM   =  
>>  POSN     = 0
>>  COLORS   = 5
>>  MARKER   = 0
>>  GRDLBL   = 0
>>  FILTER   = 0
>>  GEMPAK-GDPLOT2>r
>> Creating process: xw for queue 12551
>>  [TG 0] 1630-1655
>>  Number of times =            6
>>             1 011024/1630
>>             2 011024/1635
>>             3 011024/1640
>>             4 011024/1645
>>             5 011024/1650
>>             6 011024/1655
>> <etc...>
>> 
>> The TYPE=cm in gdplot2 will plot both the contours of the data as well as
>> the data values at the grid point locations (marker=0).
>> 
>> Let me know if you have questions/problems/etc.
>> 
>> Steve Chiswell
>> Unidata User Support
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> >From: Unidata Support <address@hidden>
>> >Organization: UCAR/Unidata
>> 
>> >
>> >Brian,
>> >
>> >The ltgmap program was the same program as sfmap. It just allowed a 
>> >greater number of times/observations. In GEMPAK 5.6, I increased
>> >the number of times/observations in sfmap so that a separate ltgmap program
>> >wasn't needed.
>> >
>> >The lat/lon locations are the station locations (each lightning strike
>> >is treated as a "ship" report).
>> >
>> >I can create a program in the next few days that will read the surface file
>  
>> >and create the grid of "reports within a DELTA radius".
>> >
>> >Steve Chiswell
>> >Unidata User SUpport
>> >
>> >
>> >
>> >
>> >
>> >>From: Brian Colle <address@hidden>
>> >>Organization: UCAR/Unidata
>> >>Keywords: 200110222134.f9MLY8102451
>> >
>> >>
>> >>Steve,
>> >>
>> >>> 
>> >>> Brian,
>> >>> 
>> >>> At this point in time, there is nothing within GEMPAK
>> >>> to make this type of computation as you require.
>> >>> 
>> >>> I would be possible to write a program to accumulate the number
>> >>> of strikes within a given radius of a grid point.
>> >>>
>> >>
>> >>In order to write another program I need to know how to open and
>> >>read the ltg sfc file to extract the lat/longs for each lightning strike,
>> >>assuming that they are stored that way. Just to clarify, is there a gempak
>> >>fortran subroutine that will read the file and extract this information?
>> >>For example, I used to use ltgmap, which plotted the individual lightning
>> >>strikes. I was hoping that I could take advantage of the way ltgmap reads
>> >>in the data, but only use the lat/long info. I notice that the latest
>> >>version of gempak doesn't even use ltgmap anymore?
>> >> 
>> >>> The other limitation you would have is that a 3km grid is going
>> >>> to be a very large grid if you are attempting to cover the
>> >>> entire country with a single grid. At present time, the default
>> >>> maximum number of grid points in a file is 400,000.
>> >>> A 4km national grid is approximately 1,200,000 points.
>> >>> 
>> >>> If you are doing a regional (or series of regional) grids
>> >>> then that won't be a problem.
>> >>> 
>> >>
>> >>Yes, I only want the regional NE US.
>> >>
>> >>Thanks again,
>> >>
>> >>Brian
>> >>
>> >>> >
>> >>> >Hi,
>> >>> >
>> >>> >I have some gempak lightning data (surface files of sgnl strength) that
>  I
>> >>> >want to interpolate to a uniformly spaced 3-km gempak grid such that ea
> ch
>> >>> >grid point has the number of nearby strikes. With this gridded file I c
> an
>> >>> >then contour the number density up in gempak. 
>> >>> >
>> >>> >Do you have any ideas or sample code how I can do this interpolation 
>> >>> >of lightning data within gempak or interfacing gempak with f77? 
>> >>> >
>> >>> >I appologize in advance for the loaded question, but I am looking
>> >>> >for ideas at this point.
>> >>> >
>> >>> >Thanks for your time...
>> >>> >
>> >>> >Brian
>> >>> >____________________________________________________________
>> >>> >Prof. Brian Colle         INTERNET: address@hidden
>> >>> >(631)632-3174
>> >>> >Institute for Terrestrial and Planetary Atmospheres
>> >>> >Marine Sciences Research Center
>> >>> >State University of New York at Stony Brook
>> >>> >Stony Brook, NY 11794-5000
>> >>> >
>> >>> 
>> >>> ************************************************************************
> ***
>> > *
>> >>> Unidata User Support                                    UCAR Unidata Pro
> gra
>> > m
>> >>> (303)497-8644                                                  P.O. Box 
> 300
>> > 0
>> >>> address@hidden                                   Boulder, CO 8
> 030
>> > 7
>> >>> ------------------------------------------------------------------------
> ---
>> > -
>> >>> Unidata WWW Service                        http://www.unidata.ucar.edu/ 
>    
>> >  
>> >>> ************************************************************************
> ***
>> > *
>> >>> 
>> >>
>> >
>> >
>> 
>> ****************************************************************************
>> 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/     
>> ****************************************************************************
>> 
>