NMAP2 Loops of Objective Analyses

Brent Shaw brent.shaw at wni.com
Mon Dec 11 14:41:49 MST 2006


Hi David,



Thanks for the suggestion.  Actually, my restore scripts did not have
any GDATTIM setting.  Rob Dale kindly suggested that I add "GDATTIM
allF00", and that seems to have done the trick.  It seems to force nmap
to scan all available files for analysis times, and I can now create the
necessary loops!



Thanks to everyone who offered suggestions!



Brent



________________________________

From: David Gold [mailto:dr_david_gold at earthlink.net] 
Sent: Monday, December 11, 2006 3:36 PM
To: Brent Shaw; gembud at unidata.ucar.edu
Subject: RE: NMAP2 Loops of Objective Analyses



Hi, Brent!



While my method differs from yours in that I do the objective analysis
using Gempak routines (e.g., OABSFC and OABSND), I did a test on NMAP2
(I've been viewing these things in GARP for the time being) and I did
not encounter a problem looping the analyzed fields. You shouldn't need
to resort to a combined file. What does a sample restore file look like
from the appropriate $NMAP_RESTORE directory? Presumably there is no
problem with your grid alias definition itself in mod_res.tbl since the
product shows up in the NMAP2 data selector. Make sure you don't have a
GDATTIM entry in the restore files that you're accessing. FWIW, my
datatype.tbl entry for surface analysis files is:



SFCA               $MODEL           YYYYMMDDHH_sfcanal.gem     CAT_GRD
SCAT_ANL   4          720       60         OFF/0/0



Adding the time matching flag made no difference in the results.



Dave Gold



________________________________

From: owner-gembud at unidata.ucar.edu
[mailto:owner-gembud at unidata.ucar.edu] On Behalf Of Brent Shaw
Sent: Monday, December 11, 2006 2:30 PM
To: gembud at unidata.ucar.edu
Subject: NMAP2 Loops of Objective Analyses



Hey all,



I am creating some hourly, 3-D objective analysis grids in real time in
GRIB-2 format, and then I am passing these into GEMPAK for real-time
viewing on NAWIPS/NMAP2.  Because this is a rather large volume of data
each hour (the grid is 448x320x31 with numerous variables), it is
necessary to save each hours data into individual GEMPAK files.  



This mostly works fine, except that within the NMAP2 application, I
cannot view more than 1 frame in a loop.  When I select the data set, I
can select any of the time for which I have files, but once I select
that time and a subsequent parameter to view, the time selector only
presents me with the data that is contained within the file I selected.
This is different behavior than image files and surface observation
files, where NMAP2 lets you "span" multiple GEMPAK files when selecting
the times to view.  Am I missing something in my configuration?  In my
datatype.tbl, I use this entry:



LAPS_US      $MODEL/laps               YYYYMMDDHH_laps_us.gem
CAT_GRD  SCAT_ANL    6   1440     -1      OFF/0/0      4



I thought the "SCAT_ANL" entry along with the time info would solve the
problem, but it doesn't.



I could partially get around this by dumping everything into a daily
file (it would probably be too big of a file though), but I think I
would still have the same problem right after the day changes (i.e., a
forecaster could not load a 00Z analysis from the latest daily file in
conjunction with some data from the previous days files as individual
frames in a loop).



I figure I could write some scripts that use gccfil/gdmod/gddelt to set
up a "circular" gempak file that always contains the last "n" hours of
grids, but that seems cumbersome if there is a way to configure NMAP to
span the grid files for times.  Any ideas?



 Best regards,

Brent



More information about the gembud mailing list