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

20020625: 20020625: dcmetr: decode SPECIs in separate GEMPAK files?

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20020625: 20020625: dcmetr: decode SPECIs in separate GEMPAK files?
  • Date: Tue, 25 Jun 2002 12:52:20 -0600
>From: =?ISO-8859-1?Q?Christian_Pag=E9?= <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200206251842.g5PIgOa23982

>
>
>>
>> Christian,
>>
>> It is possible to run multiple copies of dcmetr as long as they do not
>> try to write to the same file.
>>
>> Dcmetr does not currently have the capability to not bin the data.
>> The -m 72 flag for daily file (20 minute bins) is one hardcoded
>> option, otherwise the decoder always places obs in hourly bins.
>> I can see that it would be nice to create files where the
>> SPECIs are not binned. At present, up to 3 SPECIs per bin are stored
>> (with a set max size limit).
>
>Will dcmetr be able to cope if I compile a special version of dcmetr, 
>modifying it so that the -m 72 flag correspond to a 1-minute bin?
>
>Thanks again for your great help,
>
>Christian Pagé
>UQÀM
>

The current default number of times in a GEMPAK file is 300, so you could
not put 1440 times in a daily file. Rather, you would likely want to
put 60 minutes in an hourly file. So, I would probably have the code
recognize -m 60 with hourly files meaning not to bin the obs.

Steve Chiswell
Unidata User Support