>From: "Jeff Wilson" <address@hidden> >Organization: UCAR/Unidata >Keywords: 200012010615.eB16FFo11857 Jeff, Sorry I havn't been able to get after your emails, but I have been consumed with trying to get my 7.7 distribution out of the door (major change to some radar products that are soon to be freely available to US universities). >I have had little time for any java work and none for mcidas apart from >building mcidas 7.7 on the linux box. Well, let me tell you that if you upgrade to RedHat 7.0, and you want to be able to run the ADDE remote server from your PC, you will run into new problems. The FSF guys, in their infinite wisdom, have replaced inetd and /etc/inetd.conf with xinetd, /etc/xinetd.conf, and /etc/xinetd.d/. The ADDE remote server installation routine mcinst7.7.sh knows nothing about this. I will have to jump on it as time allows in the next couple of weeks. >Todd Smith from CIRA has sent me a >copy of RAMSDIS for NT which I plan to install soon and try out. I have been >doing some work with Tony Mostek (& Tom Whittaker) who is just across the >corridor from you I believe. Tony is across the street, but very close. It seems to me that you should angle for a trip out to do some collaborative work with COMET. That way, you would be in Boulder where we could repay your hospitality while we were in Melbourne. >Apart from your message via James for me to drop you a line I am writing to >you about a McIDAS 7.7 on linux question. We think we have hit a big endian >/ little endian problem with navigation of GMS5 images accessed as local >data rather than remote data. If we do an IMGDISP /ALT D / ALT E / MAP from >a local GMS5 dataset of the whole disc, ie not remapped then the earth >navigation doesn't seem to be there, symptoms: can't overlay a MAP over the >whole disc image, ALT E will give line and ele info but not lat / lon, >IMGLIST will not give centre lat lon but same image okay on other OS >systems, can't do imgdisp with STA= or LATLON=, when you do an IMGREMAP the >dest image is navigated but there is no data. As noted if the same image is >available as a remote image then everything seems okay. So my question has >several parts > >1) have you struck anything like this with GOES whole disk images? I have run into some apparent big-endian/little-endian problems when trying to serve certain files locally off of a little-endian machine, but they were not whole earth images. I am stuck with the impression tht the problem was related to multibanded images. I have run into this problem twice during training workshops, and have never taken the time to find and fix the problem. >2) can you suggest who I should talk to at Madison about this? Given it is a >linux issue I am not sure how the MUG might respond. I guess it is a Dave >Santek / John Bedson sort of question but thought you may know of one of the >mcidas programmers interested in linux who is also across the sat nav stuff. I would send it into the MUG as I don't think it has anything to do with Linux per se. The first time I ran into my problem I was running from a Solaris x86 box. >3) do you have any idea of the differences between loading an image held >locally and one remotely as far as providing the navigation to the frame >directory etc. An ALT-E is done locally from information out of the frame directory. An ALT-D sends a request back to the server for information about data values from the image itself. I don't think that an ALT-D uses the navigation information coming back from the server, but I could be wrong. >I guess in the remote case the remote server reads the nav >data out of the area header and passes it down to the client in ADDE stream Basically, all server requests come back with the various image blocks: header, nav, calibration if exists/asked for, auxiliary, comment cards. >whilst in the local case the linux box is reading the nav header and then >passing it to the client in ADDE speak (in this case the problem is in the >reading of the nav block in the area header). From the frame directory, FrameN.M. >We will try TRACE=1 to see >what the ADDE server is passing. Do you have any suggestions of where we >would start to look for what might be causing the problem. I would first find out if ALT-D is actually using the nav coming back from the server. If it is, then it must be calling a routine that is doing two sets of swbyt4s instead of one. >The sleuth at >this end will probably be Andrew Donaldson who has recently started to work >in James group after a brief fling in the commercial IT world, he worked in >the Sat Sect with Gerald before that. > >Any comments thoughts gratefully received I will have to recreate the problem that I have seen in the past and try and trace its origins down. After that, I may have some comments, but, then again, I may not. I will get to your other two emails as soon as I crack a problem that I have been chewing on for a couple of days. Cheers. Tom >From address@hidden Mon Dec 18 16:14:52 2000 >Subject: FW: A question re big endian / little endian Hi Tom, I meant to include you on this matter (for info really). So here it is cheers Jeff W 19 Dec 2000 -----Original Message----- From: Jeff Wilson [mailto:address@hidden Sent: Monday, 18 December 2000 15:45 To: McIDAS Help Desk Cc: address@hidden Subject: RE: A question re big endian / little endian Info Andrew Donaldson Hi MUG folks here are some more details on what we are seeing with IMGserving AREAs locally from our linux boxes. The output below is for the same mcidas area moved to the linux box from our main data server in two ways. 1) Using IMGCOPY - everything okay 2) Using ftp - apparent problems with the navigation components. For some applications we will need to move data to the linux boxes using ftp or rcp so IMGCOPY is not an option to over come the problems. Here is the output. We are interested in hearing your comments and happy to provide further info if required. cheers Jeff Wilson 18 Dec 2000 TFILE did OPEN on window 0 McIDAS area copied to linux box using IMGCOPY from McIDAS ADDE AIX server IMGLIST A/A.1 FORM=EXP Image file directory listing for:A/A Pos Satellite/ Date Time Center Res (km) Image_Size sensor Lat Lon Lat Lon --- ------------- ------------ -------- ---- ---- ----- ----- --------- --- 1 GMS-5 18 DEC 00353 03:32:00 2 -139 Band: 2 11.0 um Nighttime cloud detection 5.0 5.0 2180 x 2292 proj: 0 created: 2000353 155931 memo: GMSA svissringed MEL type:GMS cal type:RAW offsets: data= 9984 navigation= 256 calibration= 2816 auxillary= 0 doc length: 40 cal length: 0 lev length: 4 PREFIX= 48 valcod: 353033152 zcor: 0 avg-smp: S start yyddd: 2000353 start time: 33226 start scan: 255 lcor: 1020 ecor: 0 bytes per pixel: 1 ss: 83 Image Center Point Res (derived) Lat: 5.05 (km) Lon: 5.01 (km) IMGLIST: done Same McIDAS area copied to linux box via ftp from AIX server (ftp'd using bin) IMGLIST A/A.2 FORM=EXP Image file directory listing for:A/A Pos Satellite/ Date Time Center Res (km) Image_Size sensor Lat Lon Lat Lon --- ------------- ------------ -------- ---- ---- ----- ----- --------- --- 2 GMS-5 18 DEC 00353 03:32:00 Band: 2 11.0 um Nighttime cloud detection 5.0 5.0 2180 x 2292 proj: 20 created: 2000353 33152 memo: GMSA svissringed MEL type:GMS cal type:RAW offsets: data= 9984 navigation= 256 calibration= 2816 auxillary= 0 doc length: 40 cal length: 0 lev length: 4 PREFIX= 48 valcod: 353033152 zcor: 0 avg-smp: S start yyddd: 2000353 start time: 33226 start scan: 255 lcor: 1020 ecor: 0 bytes per pixel: 1 ss: 83 IMGLIST: done IMGDISP of IMGCOPied area IMGDISP A/A.1 1 STA=YMML MAG=-2; MAP SAT 2 Beginning Image Data transfer, bytes= 258384 IMGDISP: loaded frame 1 IMGDISP: done MAP: Completed frame 1 IMGDISP of ftp'd area IMGDISP A/A.2 2 STA=YMML MAG=-2; SF 2;MAP SAT 2 IMGDISP: The requested Earth location is not contained in the image IMGDISP: done IMGDISP failed, rc=2 TFILE CLOSE -----Original Message----- From: address@hidden [mailto:address@hidden Behalf Of McIDAS Help Desk Sent: Saturday, 9 December 2000 10:14 To: address@hidden Subject: Re: A question re big endian / little endian Jeff Wilson wrote: > > Hi Mug folks, > > I have been tied up with non McIDAS work for a while which is why I have > been quiet (until recently). Here is another question. Initially I contacted > Tom Yoksas at UNIDATA about this as I thought he may have run across it with > Linux. He has advised me that he has found similar issues with Solaris86 > with multiband images and that it may point to a larger problem. > > We think we have hit a big endian / little endian problem with navigation > of GMS5 images accessed as local data on a linux box running mcidas 7.7 . If > we do an IMGDISP /ALT D / ALT E / MAP from a local GMS5 dataset of the whole > disc, ie not remapped then the earth navigation doesn't seem to be there, > symptoms: can't overlay a MAP over the whole disc image, ALT E will give > line and ele info but not lat / lon, ALT D gives a creditable value but no > lat / long info. IMGLIST will not give centre lat lon but same image okay on > other OS systems, can't do imgdisp with STA= or LATLON= under the linux box > as it says not on image, when you do an IMGREMAP the dest image is navigated > but there is no data. As noted if the same image is available as a remote > image then everything seems okay. So my question has several parts > > 1) have you struck anything like this with GOES whole disk images? Nothing of the sort. > > 2) can you suggest who I should talk to at Madison about this? I'll check with Dave Santek. > > 3) do you have any idea of the differences between loading an image held > locally and one remotely as far as providing the navigation to the frame > directory etc. I guess in the remote case the remote server reads the nav > data out of the area header and passes it down to the client in ADDE stream > whilst in the local case the linux box is reading the nav header and then > passing it to the client in ADDE speak (in this case the problem is in the > reading of the nav block in the area header). We will try TRACE=1 to see > what the ADDE server is passing. Do you have any suggestions of where we > would start to look for what might be causing the problem. The sleuth at > this end will probably be Andrew Donaldson who has recently started to work > in James Kelly's group after a brief fling in the commercial IT world, he > worked in the Sat Sect with Gerald McNamara before that. I was able to load a GMS image from our server and use MAP. I was also able to copy an entire vis image (GMS) then display and add a map to the display. > > Any comments thoughts gratefully received > We have noted that if you bring an image down from a server and then do a local copy, the calibration can get flipped incorrectly. ps, I thought you might like a nice image of typhoon sam, see attachment. Rick Kohrs > Jeff Wilson > 8 Dec 2000 > > > ******************************************** > > Jeff Wilson > > Bureau of Meteorology Training Centre Australia > > Email address@hidden > > Tel (03) 96694104 > > Fax (03) 96694366 > > Mail > > GPO BOX 1289K > > MELBOURNE > > VIC 3001 > > AUSTRALIA > > ******************************************** > > >From address@hidden Tue Dec 19 15:24:01 2000 >To: "McIDAS Help Desk" <address@hidden>, > "Dave Santek" <address@hidden>, > "Dee Wade" <address@hidden> >Cc: <address@hidden>, <address@hidden> >Subject: RE: A question re big endian / little endian Info Andrew Donaldson and Tom Yoksas Hi Rick, Dave et al, Thanks for your response on this. I think I may have muddied the waters inadvertently by bringing in ftp. In fact we are seeing this problem when we move full disc images to the linux box via ftp, rcp or by writing an image to CD and then displaying it on the linux box as LOCAL-DATA. If we move renavigated images then there doesn't seem to be a problem (I will check this again to be 101% sure and let you know. I believe that Tom Yoksas has also experienced similar problems with multibanded images on the solaris boxes. Andrew reminded me that when you do a "bin" ftp there should not be any byte swapping going on, that only occurs with ascii characters when you are in ascii mode. Is there anything we can do at this end to confirm that the problem is a byte swapping problem, or alternatively obtain a print out of the two nav headers for the same area on the linux systems and AIX system for comparison. I suppose that would then lead to the possibility of then doing something like an LWU POKE to change a value in the linux header to see if things then worked, but only as a means of trying to narrow the search area for where the problem is occuring. We are interested in McIDAS running under linux as a possible upgrade path for the Paul Bekker (ABoM) ingestor cards. I understand that it is getting increasingly difficult to get HP machines that are compatible with his card but he has a ready made upgrade path on the PC platform. As I understand it they have a functioning ingestor and this problem appeared when they were using the linux McIDAS to view the ingested images. We are interested in hearing what Dave has to say on this. cheers Jeff Wilson 20 Dec 2000 PS I have cut the older email exchanges from this email for brevity but am happy to forward copies to anyone that hasn't seen them and is interested in following the track history -----Original Message----- From: address@hidden [mailto:address@hidden Behalf Of McIDAS Help Desk Sent: Wednesday, 20 December 2000 5:01 To: address@hidden; Dave Santek; Dee Wade Cc: address@hidden Subject: Re: A question re big endian / little endian Jeff etal, The problem occurrs when some of the words in the navigation block can be converted to an ascii character. ftp flips everything, where as the client and server of McIDAS only flip non-ascii character words. We see similar problems with 2-byte calibration from GVAR. Unfortunately the problem is not easily fixed and is just the tip of a much bigger issue. Please contact Dave and Dee and let them know how significantly this effects your operations. An inquiry will be made and your feedback will help us assign appropriate priority. Rick Kohrs McIDAS Help Desk address@hidden
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.