dcmetr... input file length limit?

Hi Folks,

We recently acquired the Surface Archives CDs from Weather Graphics Tecnhologies down here for use in a local research project. Since I'd like to create a few billion surface plots, I need to get the data into a gempak-friendly format.

So I wrote a script to read an input "laundry list" then dig into the archive CDs, pull out the desired data, unzip it, reformat it with the proper AFOS headers that the GEMPAK decoders so love, spit it out in text files for each day/hour requested, and then create a GEMPAK surface file for each day/hour using dcmetr.

However, I noticed it was only producing the GEMPAK surface files for a few scattered days and hours.

Lo and behold, there was plenty of data in the text files that weren't being decoded with dcmetr.

So I tried it manually... dcmetr fails. Log just says it did not decode any bulletins.

If I manually chomp out a huge chunk of obs from the files, they decode just fine.... so this leads me to the following conclusion: There must be a input file length-limit in dcmetr. Once it reaches this limit, it reads no further (and therefore doesn't see the "NNNN" it needs to work properly) and therefore fails.

Can anyone confirm my fears and/or suggest a solution?

If you need more info, like sample files, log file output, etc, please let me know and I'll post them on the web.

Thanks much!

-Mike Hardiman
NWS Santa Teresa, NM

  • 2005 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the gembud archives: