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

20030612: TASC remap2 bugs (cont.)

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

Hi Mary Ellen,

>       You're correct readd.for does not check to see if the bytes need to
>be swapped.

I don't believe I said that, and if I did, I was mistaken.  readd.for
does check to see if the header bytes need to be flipped by calling
ISAFMT:

C Copyright(c) 1997, Space Science and Engineering Center, UW-Madison
C Refer to "McIDAS Software Acquisition and Distribution Policies"
C in the file  mcidas/data/license.txt

      SUBROUTINE READD(ANUM,ENTRY)
C *** $Id: readd.f,v 1.11 2000/08/25 20:06:16 russd Rel $ ***
C $ SUBROUTINE READD(ANUM, ENTRY)  (RCD)
C $ READS DIRECTORY ENTRY FROM AREA/SOUNDING DIRECTORY 'DATDIR'
C $ ANUM = (I) INPUT  AREA NUMBER
C $ ENTRY = (I) OUTPUT  64 WORD DIRECTORY ENTRY (INTEGER ARRAY)
C $$ READD = AREA
      IMPLICIT INTEGER(A-Z)
      CHARACTER*512 CFILE
      INTEGER ENTRY(64)
      DATA ENTSIZ/64/
      DATA MAXNUM/9999/
      IF(ANUM.LT.0.OR.ANUM.GT.MAXNUM) THEN
         CALL EDEST(' Invalid AREA number=',ANUM)
         CALL mcABORT(0)
      ENDIF
      I=ARANAM(ANUM,CFILE)
      I=LWI(CFILE,0,ENTSIZ,ENTRY)

C
C--- Check for byte flipping
C
      FLIP = ISAFMT(ANUM)
      IF( FLIP .NE. 0) CALL FAHED(ENTRY)

      RETURN
      END

C Copyright(c) 1997, Space Science and Engineering Center, UW-Madison
C Refer to "McIDAS Software Acquisition and Distribution Policies"
C in the file  mcidas/data/license.txt

      FUNCTION ISAFMT( ANUM )
C *** $Id: isafmt.f,v 1.7 1999/10/11 19:03:48 billl Rel $ ***
C $ FUNCTION ISAFMT(GFNO) (DAS)
C $ IS the Area ForMaT?  Is the area byte flipped?
C $ INPUT:
C $     ANUM = (I) Area number
C $ OUTPUT:
C $     ISAFMT = (I)  =  0 native format
C $                   = -1 byte flipped format
C $$ ISAFMT = AREA, CONVERSION
      IMPLICIT INTEGER (A-Z)
      PARAMETER (FLGWRD = 1, VAL = 4)
      CHARACTER*512 CFILE

      INCLUDE 'hex80.inc'

      DATA MISS/HEX80/

      ISAFMT = 0

      I =  ARANAM(ANUM, CFILE)
      I = LWI(CFILE, FLGWRD, 1, FLAG)

      IF(FLAG .EQ. VAL) RETURN
C
C--- If file not exist, just return
C
      IF (FLAG .EQ. MISS) RETURN

      ISAFMT = -1
      RETURN
      END


ISAFMT looks at word 2 of the AREA header and checks to see if it
is a '4' or a MISS (-2139062144) value.  If it is either of these,
it returns a '0' (zero), otherwise it returns a -1.

When READD gets a -1 (actually, any non-zero) return from ISAFMT it
calls FAHED to flip bytes in the header.  FAHED then flips the
bytes in words 1-20; checks word 21 to see if it contains character
values and flips it if it doesn't; flips bytes in words 22-24;
flips bytes in words 54-56; checks word 57 to see if it contains
characters and flips it if it doesn't; and then flips bytes in
words 58-64.

>I did find a program axform.pgm that does call a subroutine FLIP
>which seems to be what we could use to accomplish the byte swap. I suppose
>we could either modify readd.for to call FLIP if necessary or modify
>remap2.pgm to use FLIP as a keyword.

readd.for already does the work needed.  Is it possible that the copy
of readd.for that you are using does not look _exactly_ like the one
I listed above?  This would be very strange indeed.

>       I did try DF which works. df.pgm does call readd() so the byte swap
>must be done before this subroutine call....

Right, after reading readd.for, isafmt.for, and fahed.for this morning
was reacquainted with the fact that the READD call does all of the 
byte flipping work that is needed.

>however, I can't find it.  Both
>IMGDISP and DF work correctly on the Linux box.

This tells me that your copy of readd.for must be identical to the one
I listed above.

>I completely understand how
>busy you are. I appreciate any time you can spare to help me out. I will do
>some reading on FLIP to see how I might incorporate its use.

What would be useful to me would be to have one of the images that you
are having problems with.  You can FTP it to our machine here at
Unidata as follows:

ftp ftp.unidata.ucar.edu
  <user> umcidas
  <pass> XXXXXX
  cd incoming/data
  binary
  put AREAnnnn            <- one of the AREA files you are having problems with
  quit

and then let me know that you have successfully transferred it.

I can then run the copy of remap2.k that I built on our RedHat 7.3 Linux
system and see if I get the same results as you.

I can tell you, however, that the test I ran with your remap2.k did use
an input AREA file that was created on a platform with a different byte
order than the one I ran remap2.k on.  The program ran with no errors
or warnings, but the resulting data in the various bands was odd:

"- display of BAND=1 data is black
 - display of BAND=2 looks sorta reasonable
 - display of BAND=3 is shows one value only
 - display of BAND=4 looks washed out
 - display of BAND=6 has a weird strip diagonally across it

 I can't explain this."

As soon as I get an image that I can get to fail, I can find out where
the failure is.

Tom