You have a file naming problem here. You should use the
file template capability provide by the dc decoders rather
than using the WMO message time, since the decoder is
able to do time QC checks to determine the appropriate file time-
in particular when more than one upper air report is in a single
bulletin. Eg, use the string data/gempak/upparair/YYYYMMDD_upa.gem
The dcuair decoder will use 3 hour time bins.
The distribution is configured to use daily files in the
$GEMTBL/config/datatype.tbl (also 4 digit years), so that is what NSHARP
will be trying to open when you select "UAIR" unless you have
changed the datatype.tbl entry. Your entry will create hourly files,
but the 3 hour time bins will mean that your yymmdd11_upa.gem file will
have the 12Z time bin in it for example.
I provide the $NAWIPS/ldm/etc/templates/* files for pqact pattern
actions, which match the datatype.tbl file names, so if
possible, I'd suggest using the gen_pqact.csh script to create your
pattern action entries if posible so that upgrading distributions will
be easier in the future! It also allows you to use the UAIR template
capabillity in your SN programs as SNFILE=UAIR[|dattim] which makes
time and file aquisition much easier in scripts.
Unidata User Support
On Thu, 6 Apr 2006, Neil R. Smith wrote:
I've got only one or none diamonds representing soundings to plot
in nsharp when looking at observered $GEMDATA/upperair .gem files.
The ldm 6.4.5 pqact.conf entry is:
DDS|IDS ^U[ABDEFGHIJKLMPQRSTXZ].... .... ([0-3][0-9])([0-2][0-9])
PIPE /unidata/nawips/bin/freebsd/dcuair -b 24 -n -m 16
Is there a binning issue here and/or only one sounding getting written
to the .gem file?
The just has to be a Doh! on my part somewhere, but I don't know where.
Neil R. Smith, Comp. Sys. Mngr. neils@xxxxxxxx
Dept. Atmospheric Sci., Texas A&M Univ. 979/845-6272 FAX:979/862-4466