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

20030617: McIDAS - IRIX64 - STNDB.USER and sfcmg

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: 20030617: McIDAS - IRIX64 - STNDB.USER and sfcmg
  • Date: Wed, 18 Jun 2003 08:21:16 -0600
>From: "Christian =?ISO-8859-1?Q?Pag=E9?=" <address@hidden>
>Organization: Universite du Quebec a Montreal / Atmospheric Science Group
>Keywords: 200306171349.h5HDnktD014043 McIDAS-X STNDB.USER

Christian,

>Package Version: 2002
>Operating System: IRIX64
>Hardware Information: SGI
>Inquiry: Hi,
>
>I added a custom station in STNDB.USER:
>IDN=99999 ID=CUQM   LATLON=  45:30:00  73:35:00 ULATLON=  45:30:00  73:35:00 E
> LE=   35 UELE=  36 ST= CO=CA NAME='Montreal / UQAM, Que' DATATYPE= METAR
>
>and it works well with stnlist and sfclist, but it produces a segmentation
>fault with sfcmg. Data for this station is available each 10 minutes in METAR
>form. What can I do to investigate the problem?

I pointed my McIDAS session at your ADDE server, io.sca.uqam.ca, and
verified that STNLIST for CUQM works with no problems, but that SFCMG
dies with a segmentation violation.  I rebuilt sfcmg.k with debugging
turned on; reran SFCMG in a mcenv session where I changed User Common
word 142 to 0 (to allow core dumps); and then examined the core file
produced by the invocation:

program terminated by signal SEGV (no mapping at the fault address)
Current function is BuildTitles
 3162     c_state       = strdup (stn->state);
(/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where
=>[1] BuildTitles(station = 0x10ca70 "CUQM", beg_day = 2003168, beg_time = 
140000, end_day = 2003169, end_time = 140000, dform = 0x10d510 "(dd) (smon) 
(yyyy)", major = 0xffbff6b8, minor = 0xffbff6b4), line 3162 in "sfcmg.c"
  [2] main(argc = 2, argv = 0xffbff884), line 692 in "sfcmg.c"

So, the problem is related to the setting of the STate in STNDB.USER,
or, this is what I surmise from the failure happening durning a strdup
of stn->state.

In looking through examples of additions that are known to work in
STNDB.USER, I see that the proper way to specify ST= with no value is:

ST='  '

I, therefore, recommend that you change your STNDB.USER entry to:

IDN=99999 ID=CUQM   LATLON=  45:30:00  73:35:00 ULATLON=  45:30:00  73:35:00 
ELE=   35 UELE=  36 ST='  ' CO=CA NAME='Montreal / UQAM, Que' DATATYPE= METAR

Since this setting is used by decoders, and since output POINT (MDXX)
files are created at the beginning of the day (or beginning of data
reception), you will have to wait until tomorrow's surface MD file is
created before seeing this change take effect.  SFCMG plots should
start working as soon as there are enough hours decoded with the new
setting of ST= for CUQM in the MD file.  You should be able to test
this before 24 hours have been decoded by telling SFCMG that you only
want fewer 'nhours':

SFCMG - Displays a surface meteorogram
   SFCMG id nhours <keywords>
Parameters:
   id | station ID to plot
   nhours | number of hours to include in meteorogram; the ending time
            is specified in the TIME keyword (def=24)

So, if you make the change this morning, you should be able to see the
results in SFCMG tomorrow.

>Thanks,

Cheers,

Tom

>From address@hidden Wed Jun 18 09:08:16 2003

Hi Tom,

Thanks for the info, I just updated my STNDB.USER and as soon as I  
restarted ldm, I can even display all available data with no problem  
with sfcmg, no need to wait!

Christian Pagé
UQAM