20031111: GOES-12 WV images

Patrick,

Yes, you were using an old template before GOES12 images were available.

Both 5.6.K and 5.6.L do have the 6.. pattern. When GOES12 images started,
I did put out an announcement for the change:
http://www.unidata.ucar.edu/cgi-bin/msgout?/glimpse/gembud-list/1775
And even though the message was dated April 1, you really did have to have that 
change.
Glad to hear you found your problem.

Steve Chiswell




>From: "Patrick O'Reilly" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200311111644.hABGieOb026796

>Hi again,
>
>Just a note to let you know I wasn't decoding GOES-12 WV files and figured
>out why.  I used the $NAWIPS/ldm/etc/gen_pqact.csh (ver. 5.6j) to generate
>an example pqact file and the file it makes specifically refers to all WV
>imagery as 6.8um when GOES-12 comes into the system as 6.5um.  I checked an
>old pqact.conf and sure enough, in the line it refers to WV imagery, it says
>(6..)um instead of (6.8)um.  The GOES-10 WV was getting filed fine, as
>GOES-10 comes in as (6.8)um.  Not sure if this is fixed in the 5.6l
>distribution. This is also in your example ldm-mcidas-pqact.conf:
>
>http://www.unidata.ucar.edu/packages/mcidas/mcidd/ldm-mcidas-pqact.conf
>
>Looking at the files coming in:
>
>.... pnga2area Q1 UW 210 GOES-12_IMG 6.5um 8km 20031111 1615
>
>so a pqact.conf line calling all WV imagery by  (6.8)um won't cut it.
>That's what I am finding in the above files you're sending out.  Got it
>fixed though and G-12 WV is getting filed.
>
>Patrick
>
>----- Original Message ----- 
>From: "Unidata Support" <address@hidden>
>To: "Patrick O'Reilly" <address@hidden>
>Cc: <address@hidden>
>Sent: Monday, November 10, 2003 11:24 AM
>Subject: 20031110: New System at UNI (cont.)
>
>
>> >From: "Patrick O'Reilly" <address@hidden>
>> >Organization: UNI
>> >Keywords: 200310241337.h9ODbAOb017830 IDD node
>>
>> Hi Patrick,
>>
>> >Got the new machine set up.  It has been feeding from our current LDM
>> >machine and all is well.
>>
>> Oh how I love to read emails that say "all is well" :-)
>>
>> >The current machine only gets a subset of the IDD
>> >feed, though.  Since I want to test this machine's connectivity for relay
>> >node status, I should get the whole set of IDD products.  I was wondering
>if
>> >my request lines now are enough:
>> >
>> >request IDS|DDPLUS ".*"
>> >request HDS ".*"
>> >request NNEXRAD ".*"
>> >request NMC3 ".*"
>> >request MCIDAS ".*"
>>
>> A few comments here:
>>
>> - the "primary" name for the NMC3 feed is FNEXRAD.  NMC3 works fine, but
>>   FNEXRAD is more descriptive
>>
>> - the "primary" name for the MCIDAS feed is now UNIWISC.  MCIDAS works
>fine,
>>   but UNIWISC better represents that the datastream is the
>Unidata-Wisconsin
>>   stream
>>
>> - the feed that has the largest volume of data _by far_ is CONDUIT.  If
>>   your intention is to stress your setup to see if things keep working
>>   AND at the same time measure how much usable bandwidth you have, I
>>   would recommend attempting to ingest all of the CONDUIT data.  The
>>   best way to do this in a test mode is to do a five-way request split
>>   of the data from a machine here at the UPC:
>>
>> request CONDUIT   "[05]$" emo.unidata.ucar.edu
>> request CONDUIT   "[16]$" emo.unidata.ucar.edu
>> request CONDUIT   "[27]$" emo.unidata.ucar.edu
>> request CONDUIT   "[38]$" emo.unidata.ucar.edu
>> request CONDUIT   "[49]$" emo.unidata.ucar.edu
>>
>>   Please note that this is _not _ an operational machine, so you will
>>   not be able to feed from it for any extended length of time.
>>
>> >or are there other feed types I would need to request?
>>
>> CONDUIT and CRAFT will stress your system.
>>
>> >Also, I have used
>> >the example pqact.conf entries given on Unidata's config pages for
>GEMPAK,
>> >NWX and MCIDAS....would these be sufficient to decode the entire set of
>data
>> >on the IDD?
>>
>> If you included all of the patterns used by GEMPAK and McIDAS, including
>> actions to run the ldm-mcidas decoders, then yes, this should be
>sufficient.
>>
>> >I am not requesting any NLDN, CONDUIT, profiler, ACARS or other
>> >data at this time.
>>
>> The NLDN data is very low volume, so it won't help stress test your
>network
>> connection of IDD node.
>>
>> >Thanks for the tips!
>>
>> No worries.
>>
>> Cheers,
>>
>> Tom
>>
>****************************************************************************
><
>> Unidata User Support                                    UCAR Unidata
>> (303)497-8643                                                  P.O. Box
>> address@hidden                                   Boulder, CO
>> --------------------------------------------------------------------------
>> Unidata WWW Service
>>
>****************************************************************************
><
>