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

Re: dcmetr modification (was 20020615: GEMPAK Laundry List)



Daryl,

Dcmetr is an NCEP decoder, (based on the core bridge.a library) so
changing behavior is more problematic than one of mine, say dcnldn, dcacars, 
etc.

Yes, you can increase the LLMXTIM to 1440. You could also use hourly files.
The the first point of departure should probably be, "Is METAR the appropriate
route for your data in the first place". Given the overall limitations
of the METAR code standard which possibly isn't designed to handle
some of the mesonet parameters, would it be better to design a decoder
specifically for your data so that you didn't have to go through the
extra step of creating METAR bulletins?

I'd be happy to do the latter with you for your data if that is the
prefered route. Otherwise, I can adapt dcmetr to handle more suitable
binning (the current structure is based on the data that is currently
broadcast- and not necessarily the most generic solution).

Steve Chiswell
Unidata User Support


On Sun, 16 Jun 2002, Daryl Herzmann wrote:

> Hi Steve,
>
> Thanks for the response.  First on my needs list, is to flag dcmetr to not
> shift times (1min data).  I see three routes to achieve this goal.
>
> 1.  Add another hack (ex set maxtim to 60 ) to force dcgtim.f to set
>     iomin = irmin and then not adjust date for minit over 45.
>     This is problematic, since it would be nice to also have 1440 work
>     as well, but that would require a change to LLMXTM, as you noted
>     yesterday.  It would also be nice to not have this hack at all and
>     handle it cleanly.  [Please don't take 'hack' the wrong way, :) ]
>
> 2.  Modify dc_gopt and add another flag (ex -f) to not allow time
>     shifting.  This change would touch many files, I assume.
>
> 3.  Remove maxtim 72 hack, and add a dc flag with a bin'ing value.
>     For example, a value of 0 or 20.  I could maybe add 5 as a supported
>     flag argument as well.  For legacy support, I could keep the 72 flag
>     and output a warning to the logs about it.
>
> Would any of these options work?  Would you merge patches from any of
> these options?  Which is your preference?  Maybe there is a different
> change you would like to see?  Let me know, I will do it.
>
> I am willing to code any of the three.  Just let me know.  If you don't
> want any of these changes, I will just do #1 locally and be happy too!
>
> Thanks,
>   Daryl
>
> On Sat, 15 Jun 2002, Steve Chiswell wrote:
>
> >
> >Daryl,
> >
> >As you know, Unidata obtains the GEMPAK distribution from developers at NCEP.
> >DCSHEF was written by Peggy Bruehl (than at COMET) and is included in the
> >Unidata distribution - but is not an official part of GEMPAK.
> >
> >The LLMXTM defined in the $GEMPAK/include files for the number of
> >times in a GEMPAK file is 300 in the Unidata distribution. you can increase
> >this as a compile time configuration.
> >
> >See the previous email message I wrote regarding changing the core
> >library storage of slat and slon as integer hundredths of degrees.
> >
> >Other contributions for device drivers would be welcomed.
> >
> >Steve Chiswell
> >Unidata User Support
>
>