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

20010109: NGM MOS and sflist issue

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: 20010109: NGM MOS and sflist issue
  • Date: Tue, 09 Jan 2001 11:16:03 -0700
>From: address@hidden (Chris Hennon)
>Organization: UCAR/Unidata
>Keywords: 200101091704.f09H4Vo16466

>Since the 12Z run on January 1, my runs of sflist have failed to detect
>any stations in my NGM MOS data file:
>
>twister:[/usr/local/gempak/scripts/nmos]% sflist
> SFFILE    Surface data file
>/usr/local/ldm/data/mos/2001010900_nmos.gem
> AREA      Data area                         @zzv
> DATTIM    Date/time                         all
> SFPARM    Surface parameter list            text
> OUTPUT    Output device/filename
>f//usr/local/apache/htdocs/text/ngmmos/zzv.nmos
> IDNTYP    STNM or STID                      STID
> Parameters requested: SFFILE,AREA,DATTIM,SFPARM,OUTPUT,IDNTYP.
> GEMPAK-SFLIST>r
> [SFLIST -3]  No stations reporting data.
> Parameters requested: SFFILE,AREA,DATTIM,SFPARM,OUTPUT,IDNTYP.
> GEMPAK-SFLIST>
>
>This occurs for any station in the country that normally has MOS data.  It
>ran normally before Jan 1 12Z. Any ideas? This is 5.4. Thanks.
>
>Chris
>
>================================================
>| Chris Hennon        Ohio State University   |
>| Tropical Meteorology      address@hidden   |
>|                                              |
>| Dept of Geography   Office: 1155 Derby Hall  |
>| 1036 Derby Hall     Phone : (614) 292-2704   |
>| Columbus, OH 43210  Fax   : (614) 292-6213   |
>================================================
>

Chris, 

Looking at the 5.4 code, I wonder why it ever worked (unless there is a slight
change in the bulletin format since Jan 1).

This goes back to whether the text should be stored at
the first forecast time of the data or the bulletin time.

You can make a quick fix in the routine:
$GEMPAKHOME/source/programs/dc/dcnmos/dcnmdc.f 

Starting on line 345 You will find the code:
C
C*                              If the data has already been
C*                              written and this is not a
C*                              correction, do not write again.
C
                            ELSE IF ( datflg ) THEN
                                good = .false.
                            END IF
C
C*                          Write the text data to the output file.
C
                            IF ( good ) THEN


All you have to do is comment out the 2 lines of the ELSE IF statement, eg:
C                           ELSE IF ( datflg ) THEN
C                               good = .false.


Then recompile the dcnmos routine:
cd $GEMPAKHOME/source/programs/dc/dcnmos
make clean
make all
make install
make clean


The 5.6 code does not have this problem.

Steve Chiswell