[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20020405: Surface decoder DMSFC is not working
- Subject: 20020405: Surface decoder DMSFC is not working
- Date: Sat, 06 Apr 2002 10:23:58 -0700
>From: Eirh-Yu Hsie <address@hidden>
>Organization: Aeronomy Laboratory/NOAA/DOC
>Keywords: 200204052006.g35K6ca26173 McIDAS-XCD DMSFC
Hsie,
>The surfece decoder DMSFC in my new server (rainbow.al.noaa.gov, RedHat
>Linux 7.2 system) is not working properly. It fires up and dies
>immediately. I need your help to take a look at it.
I logged onto rainbow yesterday afternoon and examined where dmsfc.k
was failing. As a side comment, and mainly for the email archives,
you do this by:
<login as 'mcidas'>
cd workdata <- linux/workdata in your case
mcenv <- start a mini-McIDAS session
ucu.k POKE 142 0 <- allows McIDAS routines to produce core files
dmsfc.k <- failed and dumped core
exit <- exit the mini-McIDAS session
cd ~/mcidas7.8/src
gdb dmsfc.k ~/workdata/core <- ~/linux/workdata/core in your case
This won't tell one much unless dmsfc.k was compiled with the debug
flag, -g, set (DEBUG=-g in makefile) and stripping turned off
(STRIP= in makefile). Once I did this, I found that the routine
was getting a floating point exception in a 'mod' call:
"m0dcdsfc.for" line 4259:
speed = float(mod(value,spdmod))
dir = value / spdmod
It seems that spdmod was zero, and mod was failing. Since this doesn't
seem to happen with code built with gcc/f2c, I have to wonder about
the code generated with g77. Even if the mod routine didn't dump core, the
next line would cause a floating point exception (divide by zero).
I modified the code to:
if ( spdmod .ne. 0 ) then ! <<<<< UPC mod 20030405 >>>>>
speed = float(mod(value,spdmod))
dir = value / spdmod
else
goto 100
endif
and rebuilt and reinstalled dmsfc.k. Since it started running correctly
immediately after doing this, I am satisfied that the fix was the right
approach.
(Again, most of these comments are designed for the inquiry tracking system.)
Tom