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

20040315: IMGREMAP fails with handle=3 error

>From: Unidata User Support <address@hidden>
>Organization: Unidata Program Center/UCAR
>Keywords: 200403150130.i2F1U8rV014748 McIDAS IMGREMAP

Hi,

A Unidata McIDAS user reported a problem using IMGREMAP with the MERGE=YES
option as follows:

>I am making a global composite (G-10, G-12, MET, IND, GMS) of the southern
>hemisphere in RECT proj:
>
># Create basemap from Topo files
>imgremap.k TOPO/GLOB MYDATA/IMAGES.1 PRO=RECT SIZE=ALL RES=5
>imgcopy.k MYDATA/IMAGES.1 MYDATA/IMAGES.2 LINELE=1500 0 SIZE=2100 8000
>imgcopy.k MYDATA/IMAGES.2 MYDATA/IMAGES.3 LINELE=0 1685 SIZE=2100 1805
 ...
># Remap Imagery onto basemaps
>imgremap.k GWR/GWFDSK04I4 MYDATA/IMAGES.2 DAY=${datej} TIME=02 04
>imgremap.k GER/GEFDSK04I4 MYDATA/IMAGES.3 DAY=${datej} TIME=02 04
 ...
># Remap imagery into first basemap
>imgremap.k MYDATA/IMAGES.3 MYDATA/IMAGES.2 MERGE=YES SSIZE=ALL
 ...
># Give it correct date
>imgcha.k MYDATA/IMAGES.2 CTYPE=BRIT SS=70 BAND=4 TIME=03:00:00 DAY=${datej} 
>MEMO
>
>IMGREMAP bombs when I try to do the first merge..G-12 onto the G10 basemap.
>MYDATA/IMAGES.3 merged into MYDATA/IMAGES.2.   The error message that
>can be seen when DEV=CCC is specified on the IMGREMAP command line is:
>
>IMGREMAP* Opened connection to write destination
>IMGREMAP* Pre fail check code
>IMGREMAP* Merge Data
>IMGREMAP* invalid parm - can't get pointer for handle=3
>IMGREMAP* (handle.c): parameter ERROR at line 293
>IMGREMAP: Failed to remap the image
>IMGREMAP* ERROR --- domap= -1
>IMGREMAP failed, RC=1
>
>The script is running
>fine right now with the 7.8 version of IMGREMAP.

I have verified that the IMGREMAP MERGE=YES invocation fails on Sun Solaris
SPARC 5.9, and my user verified that the command fails on RedHat 9 Linux
and Sun Solaris x86.

I searched the McIDAS Inquiry tracking system and found that INQ 12313:

IMGREMAP gives "invalid parm - can't get pointer for handle=2" error
when the destination image is a MODIS area.

One conjecture in the inquiry entry was that the problem was related
to the LAT,LON navigation of the MODIS data:

"*** This is no longer being fixed in #12132.  I'm re-opening this
inquiry.  Dave says that he thinks part of the bug is in the LALO
navigation routine, which will probably be very difficult to fix....it
can't handle the 2 lat/lon navs that IMGREMAP is trying to setup. ***"

The data that my user is merging is remapped GOES East and West data,
so the problem is not limited to LAT,LON navigations like those in MODIS.

A second comment in the MUG inquiry was:

"See inquiry 12132. The bug in this inquiry is being addressed there."

I reviewed INQ 12132 and noted that imgremap.f had updates to v 1.86;
the version in McIDAS v2003x is v 1.80.  I grabbed the most recent
imgremap.f source and tried using it to see if my user's problem was
fixed by the various changes -- it is not.  Since INQ 12132 does not
seem to quite hit the mark for the problems we are seeing, I am asking
that this problem report be added to INQ 12313.

By the way, I have been looking through the code and see how the
program is failing:  there is a call to mcafree( destination ) so
that the destination handle is freed, even though it is attempted
to be used in a call to domap further along in the code.

Thanks in advance for any insight you can give us on this remapping
problem.

Cheers,

Tom