20030612: TASC remap2.pgm -- a new bug!

>From: "Craddock, Mary Ellen" <address@hidden>
>Organization: Northrop Grumman Information Technology, TASC
>Keywords: 200306121159.h5CBxXLd023117 TASC remap2

Hi Mary Ellen,

>       Thanks for the code. The modifications you made, notably the bug you
>found where mccmddll as an INTEGER as opposed to DOUBLE PRECISION was the
>problem. Interestingly though this bug does not impact us on our IBM AIX
>machine.  Regardless, we found another bug!

Don't be fooled by bad code running on one machine and not another.
The build on Linux was _correctly_ casting the return of mccmddll to
a double precision number because it was told to by the DOUBLE PRECISION
declaration.  I am a little suprised that AIX didn't do the same, or
at least emit a warning about the type discrepency in the makelog file.

>       We made the mods you suggested in your email, recompiled, ran and
>received an error message:" HOWBIG: This is not an area, type is 6746361"
>(not the exact number returned). COAREA: This is not an area, type is
>6746361". I tracked this down to the fortran program howbig.for in
>/home/mcidas/mcidas2002/src which calls the READD function which reads the
>area directory of the source AREA file. Because the directory(2) value was
>not equal to 4 but rather our large number 6746361 the function returned
>with the error message. That's when it dawned on me that because we ingest
>the raw imagery on our AIX machine we are having a big endian/little endian
>problem! Indeed when typing an LWU list on the AREA file on the LINUX box
>the values in the header were all byte swapped! In order for the remap code
>to successfully run on the LINUX box, we had to first IMGCOPY the AREA file
>from the AIX machine to the LINUX machine!

I am suprised about this.  McIDAS handles imagery from big and little
endian machines as a matter of course.  While I havn't looked at readd.for
in quite some time, I can tell you that other routines will check 
header word 2 to see if it is a 4, and if it is not, then check to see
if it is a byte-flipped 4.  If it is, a flag gets set to flip all
words in the header before using them.  What suprises me is that McIDAS
has been doing this for _years_ going back to the early 1990s when
ADDE did not exist.  It may be the case that your routine is skipping
an important step where the endianness of the AREA is checked.  This
requires some investigation.

>       Needless to say, we don't want to have to IMGCOPY every image in
>order to remap. I recall that when you were working with making SSEC McIDAS
>(v7.6) run on the the Dec Alphas you modified the install makefile to
>support the big/little endian problem. Is this true?

Support of the basic data files (AREA, MDXX, and GRID) in both big and
little endian formats dates back to the OS/2 days.  The work I did
on DEC alpha was to pay more attention to the size of pointers (which
are typically 8 bytes in length on OSF/1 as opposed to 4 bytes on
non-64 bit platforms) and the correct declaration of variable types
(e.g., size_t, off_t, etc. instead of int) in C routines.

>Can you suggest a
>wrapper to the McIDAS build on our LINUX machine so that when we access an
>image, we successfully reorder the bytes?

A wrapper is not what is needed.  I can convince you of this by asking
you to use the DF command to load an image (you are running Unidata
McIDAS, right?).  DF accesses the images in the same way that remap2
does, through READD, etc.  What I am betting on is that there is one
step being missed in your remap2 that is done in routines like DF.

>The other option would be to
>identify all the modules (readd.for, readara.for etc) that would read the
>imagery and put a wrapper on those.

This would be the hard way.

>       I think this is an interesting find. If anyone else in the community
>is ingesting imagery on one platform and processing on another they may run
>into this.

All SSEC SDI boxes are little endian, and the imagery from them is
used on both big and little endian machines.

>However, it looks like the ADDE standard commands account for
>this, since IMGREMAP works successfully on the LINUX box accessing an image
>from the IBM AIX box. So, this may only crop up for XRD commands.

Try DF and see if it doesn't work.

>I appreciate your time and inputs on this!

I will try to take a look at your remap2 routine again and see if I
can find a missing step.  I have to fit this in, however, with the
major effort of trying to get my v2003 distribution put together
and several other development tasks.

>Mary Ellen

Tom