20030128: Profiler data in GEMPAK

Patrick,

In reading your response to Tom below, it sounds like you are getting
profiler data decoded into GEMPAK files, but are having trouble displaying
the data in GARP.

Can you verify that the data are correctly decoded and filed, by
using snlist, like:
 SNFILE   = pro6
 AREA     = @hklo2
 DATTIM   = all
 SNPARM   = sped;drct;hght
 STNDEX   =  
 LEVELS   = sfc
 VCOORD   = hght
 OUTPUT   = t
 MRGDAT   = yes

That should list out the Haskell Oklahoma surface data for the
latest profiler file. If that is OK, then we need to
look at the Garp configuration, otherwise probably the decoder
invocation.

Steve Chiswell




>From: "Patrick S. Market" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200301221349.h0MDnQx01334

>Hi Tom.
>
>Well, the satellite issue resolved itself.  The machine at OU went down 
>last week, and did not come back up cleanly.  We are now set that way.
>
>However, we still are unable to access profiler data.  Each time
>I try to do so, I get a message from GARP that no profiler files were
>found.  Yet, I have changed nothing regarding where the data are written or
>the Garp_defaults file, and we continue to have new hourly and 6min
>files created everyday.
>
>I have called your number below and left the password for ldm.
>
>Thanks,
>
>Pat
>
>> 
>> >From: "Patrick S. Market" <address@hidden>
>> >Organization: U Missouri
>> >Keywords: 200301171825.h0HIPgx27808 ldm-mcidas
>> 
>> Patrick,
>> 
>> >Hello.  I am writing to you regarding an apparent problem with our LDM
>> >and satellite images.  I mistakenly wrote to Jeff Weber, intending to
>> >write to you, although I'll be happy to have help from anyone.
>> >
>> >In a nutshell, we are no longer receiving satellite images into GARP.
>> 
>> Are you receiving the imagery by the IDD?  If yes, are they being decoded
>> by pqact.conf actions?
>> 
>> >Everything else seems to function well, except for that.  I have looked
>> >around, and it seems that we may have lost SATANNOT and SATBAND 
>> >from the /etc  in /usr/local/ldm.  However, I have put new copies
>> >there, and that does not seem to have worked.
>> 
>> Have you made any other modifications to the LDM ingestion/decoding
>> of Unidata-Wisconsin imagery (IDD feed type MCIDAS or UNIWISC)?
>> 
>> >I had some other work
>> >done on the system on Monday (which should not have impacted the
>> >LDM at all), and then rebooted the system on Tuesday.
>> 
>> Those things that "should have not impacted the LDM" typically turn
>> out to be gotchas :-(
>> 
>> >I failed to
>> >restart the LDM after the system reboot until Wednesday.
>> 
>> OK.
>> 
>> >Do you have time to take a quick look at our system?
>> 
>> If you give us a login to your machine as the user 'ldm', I will take
>> a quick look at your setup for ingesting and decoding the Unidata-Wisconsin
>> images.  If this is OK, then the problem is something in your GARP
>> setup, and Chiz will have to help you.
>> 
>> Tom
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8643                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>
>
>-- 
>========================================================================
>Dr. Patrick S. Market              
>Dept. of Atmospheric Science 
>University of Missouri-Columbia                 Phone:  (573) 882 - 1496  
>387 McReynolds Hall                             Fax:    (573) 884 - 5133 
>Columbia, MO 65211 USA          E-mail: address@hidden
>========================================================================
>