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@xxxxxxxxxxxxxxxx [mailto:owner-gembud@xxxxxxxxxxxxxxxx]
On Behalf Of Brent Shaw
Sent: Monday, December 11, 2006 2:30 PM
To: gembud@xxxxxxxxxxxxxxxx
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
