[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20001201: A question and other bits
- Subject: 20001201: A question and other bits
- Date: Thu, 07 Dec 2000 15:41:46 -0700
>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]On
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]On
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