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

20051114: Gempak data scouring



Dave,

The ldm distribution has a scour utility, which you can invoke
by "ldmadmin scour".

The program uses the ~ldm/etc/scour.conf file to define what directories to
delete data from, based on time (number of days). The program uses the "find"
utility to locate data older then the specified number of days for each 
directory/pattern
you specify.

See the LDM documentation for more information.

Steve Chiswell
Unidata User SUpport



>From: "David S. Nolan" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200511141658.jAEGwG7s017532

>
>Steve,
>
>By the way, since I have your attention for the moment,
>I'd like to ask another question:
>
>Is there a systematic way to delete all the ldm data from
>a particular time period? Our disks are filling up and
>we want to delete all the data from August. But all the
>data is divided up into numerous directories. Is there
>a way to handle this without going through every single
>directory and deleting files?
>
>Thanks for any suggestions.
>
>Best regards,
>
>Dave Nolan
>
>
>
>>
>> Dave,
>>
>> Attached is the source code for $GARPHOME/object/displayvprof.c
>>
>> Replace the existing copy, and then:
>> cd $GARPHOME
>> make clean
>> make all
>> make install
>> make clean
>>
>> Steve Chiswell
>>
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata
>> Program
>> 303 497 8643                                                  P.O. Box
>> 3000
>> address@hidden                                   Boulder, CO
>> 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service
>> http://my.unidata.ucar.edu/content/support
>> ****************************************************************************
>>
>> On Wed, 9 Nov 2005, David S. Nolan wrote:
>>
>>>
>>> Dear Steve,
>>>
>>> Thank you for your very fast reply. I believe we compiled
>>> the code, so please send me the link to the fix. Some brief
>>> instructions on how to install it would help, because the
>>> person who installs these things is out of town right now.
>>>
>>> Best regards,
>>>
>>> Dave Nolan
>>>
>>>
>>>
>>> >
>>> > David,
>>> >
>>> > This "new" bug in model soundings is caused by gcc's handling of
>>> string
>>> > constants
>>> > when passed to a Fortran routine. The code hasn't changed in many
>>> years,
>>> > but now
>>> > gcc is having trouble. I have patched this routine for the upcoming
>>> 5.8.4
>>> > release
>>> > but you can update your current version as needed. It you want to
>>> patch
>>> > the source code,
>>> > I can send you the reference to our site where I posted the fix. If
>>> you
>>> > are running
>>> > a binary release, I can send you the new executable.
>>> >
>>> > Steve Chiswell
>>> > Unidata User Support
>>> >
>>> >
>>> >
>>> >>From: "David Nolan" <address@hidden>
>>> >>Organization: UCAR/Unidata
>>> >>Keywords: 200511081743.jA8HhDCs014535
>>> >
>>> >>Institution: University of Miami
>>> >>Package Version: 2.1
>>> >>Operating System: Linux
>>> >>Hardware Information: x86
>>> >>Inquiry: Greetings from Miami.
>>> >>
>>> >>I'm using GARP to teach a course on Weather Analysis here at the
>>> >> University of
>>> >>  Miami. The program works quite well, but I just discovered that it
>>> >> crashes e
>>> >> very time I try to plot a model forecast sounding - either Skew-T or
>>> >> Stuve. I
>>> >> t works if I choose Linear or Logarithmic vertical coordinates - but
>>> >> those ar
>>> >> e hard to infer stability from.
>>> >>
>>> >>When it crashes, it gives the "Segmentaion Error" message.
>>> >>
>>> >>Do you have any suggestions?
>>> >>
>>> >>Thanks!
>>> >>
>>> >>Dave Nolan
>>> >>
>>> >>
>>> >>
>>> > --
>>> > *************************************************************************
> ***
>>> > Unidata User Support                                    UCAR Unidata
>>> > (303)497-8643                                                  P.O.
>>> Box
>>> > address@hidden                                   Boulder, CO
>>> > -------------------------------------------------------------------------
> ---
>>> > Unidata WWW Service
>>> > -------------------------------------------------------------------------
> ---
>>> > NOTE: All email exchanges with Unidata User Support are recorded in
>>> the
>>> > Unidata inquiry tracking system and then made publicly available
>>> > through the web.  If you do not want to have your interactions made
>>> > available in this way, you must let us know in each email you send to
>>> us.
>>> >
>>>
>>>
>>> --
>>> David S. Nolan
>>> Assistant Professor
>>> Division of Meteorology and Physical Oceanography
>>> Rosenstiel School of Marine and Atmospheric Science
>>> University of Miami
>>> 4600 Rickenbacker Causeway
>>> Miami, FL 33149
>>> 305-421-4930
>>> address@hidden
>>> http://www.rsmas.miami.edu/personal/dnolan
>>>
>>> "Comprehensive complexity is no virtue in modeling,
>>> but rather, an admission of failure." - Ian James.
>>>
>>>
>
>
>-- 
>David S. Nolan
>Assistant Professor
>Division of Meteorology and Physical Oceanography
>Rosenstiel School of Marine and Atmospheric Science
>University of Miami
>4600 Rickenbacker Causeway
>Miami, FL 33149
>305-421-4930
>address@hidden
>http://www.rsmas.miami.edu/personal/dnolan
>
>"Comprehensive complexity is no virtue in modeling,
>but rather, an admission of failure." - Ian James.
>
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.