[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


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.