This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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