Re: reading more data than the record size (RECL)

On Apr 15, 4:33 pm, Gordon Sande <g.sa...@xxxxxxxxxxxxxxxx> wrote:
On 2008-04-15 18:57:39 -0300, ssheriff <ssheri...@xxxxxxxxx> said:





On Apr 14, 11:43 am, glen herrmannsfeldt <g...@xxxxxxxxxxxxxxxx>
wrote:
I believe your problem is that you arereadingwith read statements
that don't match the write statement that wrote the appropriaterecord.
This works withg95:
snip
...
end snip

Glenn,

Thanks (again). If you could give me one more tip I'd really
appreciate it.

Your code writes and reads like it should.

My old compiles also write and read correctly with the subroutine I
posted.

But I can't read the files written by the old code with the new g95
compile. Thus I guess you and Richard are correct in that I'd probably
have to recompile all the programs that read write with that
subroutine.

Yet, I know the structure of the files that are wrtten and read:

Here is the header information:
Basic header record (23 4-byte words):

id: 56 ASCII characters of identification (character*56).
pgm: 8 ASCII characters identifying creating program (not all programs
add this information); character*8.
ncol: number of columns (integer*4).
nrow: number of rows (integer*4).
nz: number of words per data element. Normally nz = 1 (integer*4).
x0: position of first column of data, for example, in kilometers or
degrees of longitude (real*4).
dx: delta x, spacing interval of columns, normally in the same units
as x0 (real*4).
y0: position of first row of data (real*4).
dy: delta y, spacing interval of rows, normally in the same units as
y0 (real*4).

Is there some way I can just read the first variable (id) in an
existing file with a new (g95) fortran code without it reading past
the record length and giving me an error? If so, it seems I ought to
be able to rewrite the read form this one program and get what I need
to finish done.

Steve

It appars that you did not understand what you were being told.

The structure that may have (evidently did) change is hidden from you and
only seen the the runtime support. It is the record length (and whatever
else might be there) at the beginning of the record. It is typically repeated
at the end. To see this stuff you would have to do a system level (hex)
dump of the the physical files. This overhead is there to allow Fortran
to support backspacing, partial reads and other RECORD oriented features.
This is also why the "same" records are not compatable with C programs
which do not use a record oriented runtime which adds the required
overhead. C uses a stream notion for I/O. You need F03 or vendor specific
nonportable extensions to play such games from Fortran.

The issue is that the overhead can (and does) change between vendors and
upon occasion versions. Lately there has been a problem with whether the
lengths are to take 4 bytes or 8 bytes. Some systems tried using 8 bytes
on the newer versions but too many compatability complaints lead to switching
back to 4 bytes within a moderately common (but not universal) form. The
betting is you got caught up in this. Some offer compiler switches to
choose exactly which version is in use. So RTFM carefully! All this assume
that your claim of no other changes is actually correct. Too often the claim
is of no important changes but the changes turn out to have been important..- Hide quoted text -

- Show quoted text -

Not only do I "not understand what you were being told", I'm probably
not explaining it very well either.

But I do know there are two bytes at the start of the 'unformatted'
files because I can read & write them with a v-basic program I wrote
in 1996:

Open FileOut For Binary As #2
Bytes2 = 23627 ' calculated from USGS header description: 75-BOF,
92 bytes of header
Put #2, , Bytes2 ' Start the USGS grid file
Put #2, , idGS
Put #2, , pgm
Put #2, , ncolGS
... etc.

The compiled .exes read those grids from VB, and they read the grids
written by the Fortran code, just fine. I was just hoping I could re-
compile the original source code with g95, make sure it worked (it
doesn't), and then adapt them for larger arrays. Apparently not.
.

Relevant Pages

  • Header files
    ... In the fortran code that I have, there is a subroutine in which ... I am using a pgi compiler to compile 2D.F and my code. ... character...and it gives the names of all header files. ...
    (comp.lang.fortran)
  • Add one trailing underscore in GCC (OT)
    ... I write mainly fortran code. ... Now, when we compile this C code, the resulting symbol name is just lowercase. ... are all the available flags for this sort of things and where to find it? ... Also, if you could point me to a good GCC user mailing list, that would be ...
    (RedHat)
  • Re: Segmentation error when using WRITE/READ in Fortran Matlab interface
    ... compile the Fortran code into an executable to do the job, ... when I call the function in Matlab after ... from those snippets (i hope they are separate snippets and fid!= 11) one can't tell whats wrong. ...
    (comp.soft-sys.matlab)
  • How to compile g95 and get 64-bit executable
    ... I am just wondering how does one compile a fortran code with g95 and ... on a 64-bit Opteron machine? ... set when I run the g95 ...
    (comp.lang.fortran)
  • Re: linking FORTRAN code to simulink
    ... you can link a piece of Fortran code to Simulink by an S-Function ... You have to compile first the Fortran files and then is necessary to ... link the C-gate function with them. ...
    (comp.soft-sys.matlab)