20050601: could not get the McIDAS shell programs (cont.)

>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200504201601.j3KG1gv2005753 McIDAS access

Hi Mekonnen,

I rebuilt McIDAS on sangres on Sunday after defining some needed
environment variables in ~mcidas/.cshrc.  The list of additional
environment variables I defined is:

setenv VENDOR -g77
setenv CC gcc
setenv CPPFLAGS "-DNDEBUG -Df2cFortran"
setenv CFLAGS -O
setenv FC g77
setenv FFLAGS "-O -Wuninitialized -fno-automatic"
setenv CXX " "
setenv F90 " "

setenv LIBS -lm

The first set minus VENDOR are ones that are listed in the Unidata
McIDAS User's Guide section on configuring the 'mcidas' account before
attempting a build:

http://my.unidata.ucar.edu/content/software/mcidas/2004/users_guide/PreparingthemcidasAccount.html

VENDOR is a new environment variable I am moving to use actively in the
v2005 distribution which will be released in July.

The last define, LIBS, was _unexpectedly_ needed in the HDF portion of
the build.  I need to ponder that one more carefully before the next
release.

After doing the rebuild on Sunday, I am able to load the GOESIR
composite image that you sent me (i.e., I do not get the message about
the stretch table not being found on the server).  The image displayed
is, however, black.  Further investigation shows that the image has
some header words incorrectly set:

lwu.k LIST globir.02182.0015 50 58

sagres% lwu.k LIST globir.02182.0015 50 58
      50.          0  1447646034 HEX:        0 56495352 ASCII:      VISR
      52. 1112688980           2 HEX: 42524954        2 ASCII: BRIT
      54.          3           0 HEX:        3        0 ASCII:
      56. 1347568672   538976288 HEX: 50524420 20202020 ASCII: PRD
      58.          1           0 HEX:        1        0 ASCII:
 --END OF LISTING

(LWU is a McIDAS utility that is used for a variety of purposes one of
which is to LIST out the contents of a file in decimal, hexidecimal,
and ASCII.)

The problem turns out to be the definition of words 56 ("PRD ") and 57
("    ").  "PRD " in word 56 is supposed to mean that the image will
contain a PRoduct Definition block later on in the header, and that
PRoduct Definition block will define the "calibration" (mapping of
brightnesses to a calibrated unit like Temperature for IR images) of
the image.  The problem is that there is no PRoduct Definition block in
the image!  The result of this is that loading the image with IMGDISP
results in a blace display _unless_ "PRD " and " " are changed.  I
illustrated this by creating a GIF image of the load of globir.02182.0015:

<while logged on as you>

cd ~/mcidas/data
mcenv -f 1@600x800         <- create a 1 frame session of 600 lines by 800 
elements

imglist.k GLOBIR/AREA.1    <- list out information on the image
Image file directory listing for:GLOBIR/AREA
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   1  G-8 IMG        1 JUL 02182  00:15:00     5  110 4
imglist.k: done

imgdisp.k GLOBIR/AREA.1 MAG=-4   <- load the image into the single frame
Beginning Image Data transfer, bytes= 235140
IMGDISP: loaded frame  1
imgdisp.k: done

map.k                            <- draw a map on the image
MAP: Completed frame 1

frmsave.k 1 globir0015.gif       <- save the display as a GIF raster

If you look at globir0015.gif, you will see that it is totally black
except for the map drawn using MAP (map.k).

I found out that ~mek11/GOESdata contains a number of composites
images, so I took the liberty of uncompressing the one for 00:45 on the
same day as the first image and then copying it to ~mek11/GOESdatanew.
The ADDE definition for GLOBIR allows both of these images to be viewed
as part of the same dataset.

I next verified that an IMGDISP of the 00:45 image was also black
(following the same steps above, but specifying the load of
GOESIR/AREA.2).

Next, I used the LWU (lwu.k) utility to change the "PRD " and "    "
words in the header of the image in globir.02182.0045:

redirect.k ADD globir.\* \"/disk/space/mek11/GOESdatanew

dmap.k globir.
PERM      SIZE LAST CHANGED FILENAME          DIRECTORY
---- --------- ------------ ----------------- ---------
-rw-   3737128 May 18 16:53 globir.02182.0015 /disk/space/mek11/GOESdatanew
-rw-   3737128 Jun 01 02:58 globir.02182.0045 /disk/space/mek11/GOESdatanew
7474256 bytes in 2 files

lwu.k POKE globir.02182.0045 0 56
lwu.k POKE globir.02182.0045 0 57

After making these mods, I loaded the image, drew a map, and saved the
raster as a GIF image:

erase.k
imgdisp.k GLOBIR/AREA.1 MAG=-4
map.k
frmsave.k 1 globir0045.gif

If you look at globir0045.gif, you will find that you can see the image
data now, and that the image really is a composite from multiple satellites.

So, it looks like you will need to modify the composite image's headers
using LWU in the manner I outlined above in order to be able to use
them.

Please try unpacking another image and going through the steps I
outlined above to convince yourself that things will work.  After you
have done this, we can revisit your ultimate goal of dumping out data
values.

By the way, if you follow the steps as I show then above, you will
still be in the single frame McIDAS session.  You exit that session by
running:

exit

when you are done.

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.