| Unformatted data portability: Digital UNIX-->Windows 95 [message #11239] |
Thu, 19 March 1998 00:00  |
r.s.eckman
Messages: 1
Registered: March 1998
|
Junior Member |
|
|
I'm trying to do some post-processing of model results on a Windows95
Intel-based platform using IDL. The model is running on a DEC Alpha
machine running Digital UNIX. In IDL on the DEC platform, we can open
the output files using the "/f77_unformatted" qualifier. While the IDL
manual has a nice discussion of the way Fortran programs write files
on UNIX machines, I don't see any discussion relating to portability of
these files to, say, a Windows95 platform. When I try to open the same
file on the Windows platform using IDL, I need to insert a "junk" variable
at the start and end of the logical record to get it to read properly.
For example, the file could be read on the DEC Alpha/UNIX platform using:
openr,1,'file.dat',/f77
readu,1,a,b,c
On the Windows95 platform, I seem to need to do the following:
openr,1,'file.dat'
readu,1,junk,a,b,c,junk
Is there any way around modifying all of our IDL codes on the Windows platform?
Of course, the "/f77" keyword in the open statement won't work under Windows
95. In a more general sense, is this "almost" binary portability unique to the
Digital UNIX/Windows95(or NT) combination or could I have written the file from
a SUN or SGI and read it on a Windows95 Intel-based machine in the same way?
Thanks for any information.
Richard Eckman
NASA Langley Research Center
Hampton, VA
r.s.eckman@larc.nasa.gov
|
|
|
|
| Re: Unformatted data portability: Digital UNIX-->Windows 95 [message #11333 is a reply to message #11239] |
Mon, 23 March 1998 00:00  |
dors
Messages: 8
Registered: June 1994
|
Junior Member |
|
|
Hi,
You are correct, FORTRAN outputs some weird marker bytes to files. On
other platforms where "/F77" isn't available you will have to keep
track of this. Using od (octal dump) on a test data file from your
shell, will help you find these marker bytes if you don't have a
manual which provides that information.
To make your code architeture independent, your best bet is to create
a case statement on "!version.os". In the various cases ("OSF",
"sunos", ...) have the architecture specific code to transform the
input data such that your output data is the same no matter what
architecture you are using. You will always have to be aware of the
architecture of the machine where the data file was written.
Prepending an ASCII header to your data files containing architecture
of the file creator will facilitate this. Then you can perform the
appropriate BYTEORDER or SWAP_ENDIAN commands to switch byte ordering
differences and appropriately remove FORTRAN codes from the data file,
if present. When writing ASCII headers to binary data files, I find
it useful to include the length in bytes or the number of lines of the
header as the first line of the header for easy decoding later.
Although I have not done this myself, I believe the use of CDF files
will provide a seemless mechanism to pass data between architectures.
So if you have FORTRAN libraries available to write CDF, you might
look into this solution.
Hope this helps,
Eric
--
============================================================ ================
| Eric E. Dors | Internet:dors@gamma.physics.uiowa.edu |
| University of Iowa | Web: http://delta.physics.uiowa.edu/~dors |
| 203 Van Allen Hall | Office: (319) 335-3828 |
| Iowa City, IA 52242 | Home: (319) 351-0887 |
============================================================ ================
|
|
|
|
| Re: Unformatted data portability: Digital UNIX- [message #11346 is a reply to message #11239] |
Mon, 23 March 1998 00:00 |
wmc
Messages: 117
Registered: February 1995
|
Senior Member |
|
|
In article eckman@eos1.larc.nasa.gov, r.s.eckman@larc.nasa.gov (Richard Eckman) writes:
> I'm trying to do some post-processing of model results on a Windows95
> Intel-based platform using IDL. The model is running on a DEC Alpha
> machine running Digital UNIX. In IDL on the DEC platform, we can open
> the output files using the "/f77_unformatted" qualifier. When I try to open the same
> file on the Windows platform using IDL, I need to insert a "junk" variable
> at the start and end of the logical record to get it to read properly.
>
> For example, the file could be read on the DEC Alpha/UNIX platform using:
> openr,1,'file.dat',/f77
> readu,1,a,b,c
>
> On the Windows95 platform, I seem to need to do the following:
> openr,1,'file.dat'
> readu,1,junk,a,b,c,junk
>
> Is there any way around modifying all of our IDL codes on the Windows platform?
The "junk" 4-bytes is the length of the record (for some reason, repeated
at the end of the record too).
You could try your fortran manual for the code that writes the files - perhaps
it is prepared to write a byte-stream rather than fortran-unformatted.
Alternatively, if your file only has one record it it, you can use "head" and "tail"
to cut off the first and last 4 bytes.
> Of course, the "/f77" keyword in the open statement won't work under Windows
> 95. In a more general sense, is this "almost" binary portability unique to the
> Digital UNIX/Windows95(or NT) combination or could I have written the file from
> a SUN or SGI and read it on a Windows95 Intel-based machine in the same way?
SUNs and SGIs (and everything else, in fact) are byteswapped; but this can be
cured with "byteorder". (Errm, thats looking at it from the alpha perspective...)
- William
---
William M Connolley | wmc@bas.ac.uk | http://www.nbs.ac.uk/public/icd/wmc/
Climate Modeller, British Antarctic Survey | Disclaimer: I speak for myself
|
|
|
|
| Re: Unformatted data portability: Digital UNIX-->Windows 95 [message #11377 is a reply to message #11239] |
Fri, 20 March 1998 00:00 |
rivers
Messages: 228
Registered: March 1991
|
Senior Member |
|
|
> In a more general sense, is this "almost" binary portability unique to the
> Digital UNIX/Windows95(or NT) combination or could I have written the file from
> a SUN or SGI and read it on a Windows95 Intel-based machine in the same way?
Yes, it is unique to Digital Unix/Windows 95. Both of those architectures are
little-endian and use IEEE floating point. Sun's and SGI are big-endian, so
there is no binary compatibility.
____________________________________________________________
Mark Rivers (773) 702-2279 (office)
CARS (773) 702-9951 (secretary)
Univ. of Chicago (773) 702-5454 (FAX)
5640 S. Ellis Ave. (708) 922-0499 (home)
Chicago, IL 60637 rivers@cars.uchicago.edu (e-mail)
or:
Argonne National Laboratory (630) 252-0422 (office)
Building 434A (630) 252-0405 (lab)
9700 South Cass Avenue (630) 252-1713 (beamline)
Argonne, IL 60439 (630) 252-0443 (FAX)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
