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

20020324: GEMPAK MOS decoders produce incomplete output

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: 20020324: GEMPAK MOS decoders produce incomplete output
  • Date: Wed, 27 Mar 2002 13:54:40 -0700
Robert,

The decoder is filing the products in there entirety.
The sflist routine is truncating the output at 256 characters in:
$GEMPAK/source/programs/sf/sflist/sflprt.f.

I commented out the truncation in line 76:

C                       IF ( lenstr .gt. 256 ) lenstr = 256


And get the complete report printed out.

As new fields have been added to the mos reports, the truncation 
becomes more apparent.

Steve Chiswell
Unidata User Support.


>From: "Robert Mullenax" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200203250533.g2P5XJa10915

>The GEMPAK MOS decoders are not filing the text correctly (sfparm=text
>in sflist).  I only get partial results for the NEW AVN, NEW MRF and
>NGM MOS:
>
>BRO  S    NGM MOS GUIDANCE   3/25/02  0000 UTC 
>DAY /MAR  25             /MAR  26                /MAR  27 
>HOUR   06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
>MX/MN                    84          61          73          58 
>TEMP   68 68 67 73 
>MFE  S    NGM MOS GUIDANCE   3/25/02  0000 UTC 
>DAY /MAR  25             /MAR  26                /MAR  27 
>HOUR   06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
>MX/MN                    89          59          71          57 
>TEMP   69 68 67 72 
>NQI  S    NGM MOS GUIDANCE   3/25/02  0000 UTC 
>DAY /MAR  25             /MAR  26                /MAR  27 
>HOUR   06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
>MX/MN                    85          52          70          54 
>TEMP   68 67 66 70 
>LRD  S    NGM MOS GUIDANCE   3/25/02  0000 UTC 
>DAY /MAR  25             /MAR  26                /MAR  27 
>HOUR   06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
>MX/MN                    87          56          71          58 
>TEMP   74 70 67 70 
>NGP  S    NGM MOS GUIDANCE   3/25/02  0000 UTC 
>DAY /MAR  25             /MAR  26                /MAR  27 
>HOUR   06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
>MX/MN                    79          59          67          59 
>TEMP   69 68 67 70 
>ALI  S    NGM MOS GUIDANCE   3/25/02  0000 UTC 
>DAY /MAR  25             /MAR  26                /MAR  27 
>HOUR   06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
>MX/MN                    85          51          71          51 
>TEMP  999999 66 69 
>CRP  S    NGM MOS GUIDANCE   3/25/02  0000 UTC 
>DAY /MAR  25             /MAR  26                /MAR  27 
>HOUR   06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
>MX/MN                    84          52          67          54 
>TEMP   69 68 67 71 
>NIR  S    NGM MOS GUIDANCE   3/25/02  0000 UTC 
>DAY /MAR  25             /MAR  26                /MAR  27 
>HOUR   06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
>MX/MN                    82          50          74          52 
>TEMP   67 66 67 71 
>COT  S    NGM MOS GUIDANCE   3/25/02  0000 UTC 
>DAY /MAR  25             /MAR  26                /MAR  27 
>HOUR   06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 
>MX/MN                    86          55          72          53 
>
>Below is a snippet from the dcnmos.log
>
>[6522] 020325/0231 [DC 3]
>[6522] 020325/0247 [DC -6]
>[6522] 020325/0247 [DC 5]
>[6522] 020325/0247 [DC 2] Number of bulletins read and processed: 306
>[6522] 020325/0247 [DC 6]
>
>The raw bulletins are coming in fine.  The last time I looked
>at this data was about 3 months ago and it was fine then.  This happens
>with the 5.6d and e decoders on both Solaris SPARC and Intel.
>
>Thanks,
>Robert Mullenax
>