[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030203: 20030128: Profiler data in GEMPAK



Patrick,

I believe that the problem is that Lathrop seems to be missing
at the top of the hour (hh00) for most hours. Garp looks to
be processing times based on "exect" hour matches which
doesn't work very well for this data set. I have changed this.

Steve Chiswell
Unidata User Support





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

>Steve:
>
>The beat goes on.  since I mailed you this morning, I have had some time
>to explore precisely what GARP does and does not do with profiler data.  
>
>Today, generally, I am not getting the "no profiler files were found" message
>but I have large chunks of time wherein no data is saved.  Data does plot,
>but for Lathrop, MO, requesting 24 hours of hourly data starting at 
>20030203/1800 gets me data plotted at 01, 02, 03, 08, and 10Z.  Hillsboro, KS,
>plots for the same request at the same times.
>
>6 minute data seems to be available for today from 00Z-11Z.
>
>Might this still be an upstream feed problem?
>
>Pat
>
>> 
>> 
>> Patrick,
>> 
>> The sample dcncprof actions I provided create 2 files per day named
>> YYYYMMDD00_6min.gem and YYYYMMDD12_6min.gem for historical reasons
>> (eg the NCEP distribution is limited to 200 times in a file).
>> The $GARPHOME/config/Garp_defaults file has the profiler template
>> (at the bottom of the file set to match YYYYMMDDHH_6min.gem.
>> 
>> Since the UPC distribution has 300 times allowed in a file, you can
>> put all 24 hours * 10 times per hour in a single file...so
>> I set up a test naming files YYYYMMDD_6min.gem and modified the
>> $GARPHOME/config/Garp_defaults with YYYYMMDD_6min.gem. 
>> 
>> Both of the above work for me in finding the files.
>> I did find that some operating systems have diffent defaults for the time
>> zone locale,  so that the last UTC - Local hours are omitted from the plot,
>> and have fixed that for the next distribution.
>> 
>> I probably need to see your dcncprof and Garp_defaults configurations
>> if you have made any changes from the defaults that I provide.
>> When something used to work, and then it no longer does, I'd first check
>> to make sure either the pqact.conf invocation wasn't changed, of the
>> Garp_defaults wasn't. Also, for sanity, make sure you aren't looking
>> at a different Garp_defaults file (eg, in a local directory
>> or one configured for case studies, etc).
>> 
>> Steve Chiswell
>> 
>> 
>> 
>> >From: "Patrick S. Market" <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200302031441.h13EfC612724
>> 
>> >Steve:
>> >
>> >The SNLIST approach worked fine.  I would have to think that there
>> >is something amiss in GARP, although this has worked in the past.
>> >
>> >Pat
>> >
>> >> 
>> >> 
>> >> Patrick,
>> >> 
>> >> In reading your response to Tom below, it sounds like you are getting
>> >> profiler data decoded into GEMPAK files, but are having trouble displayin
> g
>> >> 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 LD
> M
>> >> >> >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 deco
> ded
>> >> >> by pqact.conf actions?
>> >> >> 
>> >> >> >Everything else seems to function well, except for that.  I have look
> ed
>> >> >> >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-Wisc
> ons
>> > in
>> >> >> 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 P
> rog
>> > ram
>> >> >> (303)497-8643                                                  P.O. Bo
> x 3
>> > 000
>> >> >> address@hidden                                   Boulder, CO
>  80
>> > 307
>> >> >> ----------------------------------------------------------------------
> ---
>> > ---
>> >> >> 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
>> >> >========================================================================
>> >> >
>> >> 
>> >> *************************************************************************
> ***
>> >> Unidata User Support                                    UCAR Unidata Prog
> ram
>> >> (303)497-8643                                                  P.O. Box 3
> 000
>> >> address@hidden                                   Boulder, CO 80
> 307
>> >> -------------------------------------------------------------------------
> ---
>> >> 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
>> >========================================================================
>> >
>> 
>> ****************************************************************************
>> 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
>========================================================================
>