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

20011105: IMGDISP problems (cont.)



>From: Giovanni Leoncini <address@hidden>
>Organization: SJSU
>Keywords: 200110181917.f9IJHA119842 McIDAS IMGDISP ADDE

Giovanni,

re: what version are you running
>7.701 Unidata 010104            

OK.  The problem turns out to not be version related, but this was still
valuable to know.

re: sorry for the peoblems
>the more I talk to you the less problems I have, dude!
>
>I'll let you know later today about the procedure you figured.

OK.

>>From address@hidden Mon Nov  5 13:06:15 2001
>>Subject: Re: 20011102: IMGDISP problems (cont.) 

>the procedure you set up for me works fine, and if I understood what
>happens it basically loads as a non-ADDE image.

Yes.

>I can see the NCAL images
>(great!) and loop through them (very great!), but I didn't see any routine
>able to convert non-ADDE images into netcdf, which is my final aim.

The netCDF output is an ADDE application.

>IMGCOPY does'n seem willing to do it, when I give the command:
>
>IMGCOPY MYDATA/IMAGES.2005 IMG/NETCDF.1 
>
>it just sits there and does nothing, and I see agetserv among the
>running processes. does this happens because it is NOT an ADDE image?

No, it happens for the exact reason that the image won't load.

>anyways, thank you one more time

I figured what is going on (finally).  Word 64 (1-based) in the image
file header for the NCAL image is incorrect; it is byte flipped from
what it should be.  This word is the count for the number of comment
cards (80 character recoeds) that the image is supposed to have.  In
your NCAL images, this number is coming out to something like 50331648,
when it should be 3 (if you store '3' in a 4-byte word, and then byte
flip the bytes, the number becomes 50331648).

Whatever routine is producing these images has a problem.  Also, the
McIDAS code that reads in the comment cards is not checking to make
sure that it does not try to read more than the maximum number of
comment cards (so it is in a loop that will last until 50331648 file
reads are made).  This is an error that never shows up for correctly
written images.

So, what should you do?  Here is a blow-blow for the person that built
McIDAS on your machine:

1) login as 'mcidas'

2) grab a fixed version of agetserv.fp from our anonymous FTP server:

   cd mcidas7.7/update
   ftp ftp.unidata.ucar.edu
     <user> anonymous
     <pass> full_email_address
     cd pub/mcidas/src
     binary
     get agetserv.fp
     quit
  
   cd mcidas7.7/src
   mv agetserv.fp agetserv.fp.bak
   cp ../update/agetserv.fp .
   make agetserv

   <assuming that agetserv build worked then do>

   rm ~/bin/agetserv
   ln agetserv ~/bin

After doing this, IMGDISPs should work with no error, AND you should
then be able to do IMGCOPYs to an output netCDF ADDE dataset.

A couple of closing comments:

o whoever is making the images you are getting should be made aware that
  there is a problem in their code.  I can provide them details if they
  are interested.

o you (SJSU) are many revisions out of date with regards to McIDAS.
  you are not only running 7.7 when 7.8x is the currently distributed
  version, but you don't even have all bug fixes for 7.7x.  If
  you (or whoever) decides to upgrade 7.7 on your machine, then
  you/he will need to redo the agetserv.fp fix that I outlined above
  since that fix is not in 7.7x.

o the reason that GEMPAK had no problems with the image id that GEMPAK
  does not pay any attention to the comment cards in McIDAS AREA files.

I will be rolling the fix that I made ro agetserv.fp into my 7.8x
distribution and releasing it in my next addendum.  This will not happen
until I can get some other modifications done.

Anyway, the agetserv.fp fix should get you going!

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.