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

20020618: GOES-8 Albedo (cont.)

>From: Frederic Chagnon <address@hidden>
>Organization: MIT
>Keywords: 200206142154.g5ELsOJ16211 McIDAS GOES albedo

Hi Fred,

>Thanks for the info. I've actually started to
>program my own version,

Sounds good.

>but I run into problems
>with the nvxgoes.dlm module (specifically the
>nv1opt.f subroutine).

For GOES-8 you should be using nvxgvar.dlm, not nvxgoes.dlm.
nvxgoes.dlm was for the older, spin stabilized series of GOES.

>It returns a floating point
>error on some calls (very rarely in terms of
>pixels, but it still interrupts my conversion
>process for many images).  I've tried recompiling
>the whole mcidas package with the -fpe3 switch,
>but it still interrupts my pgm on the nv1opt call.
>Any clues on how to compile the mcidas libraries
>so that they are floating-point-error robust?

I am assuming that this is on a OSF/1 machine (the -fpe3 switch
is supported there).  The -fpe3 (or -fpe4) option is the one that
I would have tried.  Perhaps the problem is coming from use of the
wrong navigation module, nvxgoes.dlm and not nvxgvar.dlm?



From: Russ Dengel <address@hidden>
Date: Wed, 19 Jun 2002 11:56:43 -0500
Organization: SSEC
To: Frederic Chagnon <address@hidden>
CC: address@hidden
Subject: Re: [mdf] fp error on nv1opt call

Frederic Chagnon wrote:

> Hello,
> I have a very simple program that makes a call to
> the nv1opt ('ANG' option) subroutine for some
> navigation info on some GOES-8 images. The problem
> is that the nv1opt subroutine returns a floating
> point error sometimes. How can I recompile the
> McIDAS libraries so that the floating point error
> just returns a 0 instead (similar to fpe2 flag on
> fortran compile) ?
> Thanks
> Frederic


It appears that the McIDAS subroutine SOLARP (called by NV1GOES)
is terminating due to a boundary condition caused by the specified Earth
location (Lat/Lon). Could you specifying a coordinate which is near the
lim on the image?

Currently, the only fix is to retro fit SOLARP with some sort of
boundary checks which would eliminate these floating point exceptions.

Russell Dengel

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.