RE: NMAP2 Loops of Objective Analyses

• To: "David Gold" <dr_david_gold@xxxxxxxxxxxxx>, <gembud@xxxxxxxxxxxxxxxx>
• Subject: RE: NMAP2 Loops of Objective Analyses
• From: "Brent Shaw" <brent.shaw@xxxxxxx>
• Date: Mon, 11 Dec 2006 15:41:49 -0600

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@xxxxxxxxxxxxx]
Sent: Monday, December 11, 2006 3:36 PM
To: Brent Shaw; gembud@xxxxxxxxxxxxxxxx
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