From: Kurt Kallblad on

"ssheriff" <ssheriff3(a)gmail.com> wrote in message
news:10ce0b89-bfea-4147-b9bf-41bc37eb685c(a)c19g2000prf.googlegroups.com...
>I am trying to recompile some old .for code with g95. The binary
>runs
> fine, but I need to make the arrays larger. When I compile
> (g95 -o
> a.exe b.for) the program runs until it gags on reading an
> 'unformatted' file:
>
> here's the code:
>
> open(unit=12, file=zbot_file, form='unformatted',
> status='old')
> call read_write(0, 12, id, ny, nx, y0, dy, x0, dx, zbot)
> ***
> subroutine read_write(mode, lun, id, ncol, nrow, col1,
> delcol,
> &row1, delrow, array)
> dimension array(1), work(1000)
> character id*56
> character pgm*8
> read(unit=lun) id, pgm, ncol, nrow, nz, col1, delcol,
> row1,
> delrow
>
> The last line above is the one for which it says:
>
> UNIT 12 "100USGS.grd " Fortran runtime error: Reading more
> data
> than the record size (RECL)
>
> The record length, in another program that transforms files,
> appears
> to be 128, and I tried that with recl=128, but get the same
> messages.
>
> Any tips on how to get around this?
>
> TIA

I'm not familiar with g95 but as you say "old code" the
statement
"dimension array(1),.." might be the problem. It was an old way
to
handle assumed size arrays. A change to "array(*) ..." may be
worth
to try.

Kurt

From: glen herrmannsfeldt on
Kurt Kallblad wrote:

(snip)

>> subroutine read_write(mode, lun, id, ncol, nrow, col1, delcol,
>> &row1, delrow, array)
>> dimension array(1), work(1000)
>> character id*56
>> character pgm*8
>> read(unit=lun) id, pgm, ncol, nrow, nz, col1, delcol, row1,
>> delrow
(snip)

> I'm not familiar with g95 but as you say "old code" the statement
> "dimension array(1),.." might be the problem. It was an old way to
> handle assumed size arrays. A change to "array(*) ..." may be worth
> to try.

Since ARRAY isn't in the READ statement it shouldn't matter.

In any case, with array(*) the array can't be used in places
where the length is needed. With array(1) a length of 1 will
be used, which may be wrong.

To say anymore, more of the program, especially the WRITE
statement and any declarations for variables being written,
will be needed.

-- glen

From: ssheriff on
On Apr 11, 4:36 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:


> (snip)..
>
> To say anymore, more of the program, especially the WRITE
> statement and any declarations for variables being written,
> will be needed.
>
> -- glen

OK - here's the write statement, and the subroutine where array is
dimensioned. Basically, it writes an array as one vector.

call read_write(1, 13, id, ny, nx, y0, dy, x0, dx, h)
***
subroutine read_write(mode, lun, id, ncol, nrow, col1, delcol,
&row1, delrow, array)
dimension array(1), work(1000)
character id*56
c.......................................................................
c This subroutine reads a standard file into a one-dimensional
array
c Inputs are mode (0 for read, 1 for write) and lun (logical unit
numbe
cr).
cOutputs are id,ncol,nrow,col1,delcol,row1,delrow, and array.
c.......................................................................
character pgm*8
if (mode .eq. 1) goto 5
read(unit=lun) id, pgm, ncol, nrow, nz, col1, delcol, row1,
delrow
goto 6
5 nz = 1
pgm = 'sds-PFMAG3D '
write(unit=lun) id, pgm, ncol, nrow, nz, col1, delcol, row1,
&delrow
c
6 continue
do 1 j = 1, nrow
l = 0
i1 = ((j - 1) * ncol) + 1
i2 = (i1 + ncol) - 1
if (mode .eq. 1) goto 3
call row_read(lun, work, ncol)
do 2 i = i1, i2
l = l + 1
2 array(i) = work(l)
goto 1
3 continue
do 4 i = i1, i2
l = l + 1
4 work(l) = array(i)
call row_write(lun, work, ncol)
1 continue
return
end
subroutine row_read(lun, work, ncol)
dimension work(ncol)
read(unit=lun) dummy, work
return
end
subroutine row_write(lun, work, ncol)
dimension work(ncol)
dummy = 999.
write(unit=lun) dummy, work
return
end
From: Kurt Kallblad on

"glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message
news:qY2dnWZp1YUfe2LanZ2dnUVZ_o-mnZ2d(a)comcast.com...
> Kurt Kallblad wrote:
>
> (snip)
>
>>> subroutine read_write(mode, lun, id, ncol, nrow, col1,
>>> delcol,
>>> &row1, delrow, array)
>>> dimension array(1), work(1000)
>>> character id*56
>>> character pgm*8
>>> read(unit=lun) id, pgm, ncol, nrow, nz, col1, delcol,
>>> row1,
>>> delrow
> (snip)
>
>> I'm not familiar with g95 but as you say "old code" the
>> statement
>> "dimension array(1),.." might be the problem. It was an old
>> way to
>> handle assumed size arrays. A change to "array(*) ..." may be
>> worth
>> to try.
>
> Since ARRAY isn't in the READ statement it shouldn't matter.
>
> In any case, with array(*) the array can't be used in places
> where the length is needed. With array(1) a length of 1 will
> be used, which may be wrong.
>
> To say anymore, more of the program, especially the WRITE
> statement and any declarations for variables being written,
> will be needed.
>
> -- glen

I really agree with your last sentence!

As I said I'm not familiar with g95. But compilers some times
give
diagnostics far away from the real problem and the OP showed
later that the routine includes
do 2 i = i1, i2
l = l + 1
2 array(i) = work(l)
This seems to address more then one element, thus I still think
he
should consider to change the declaration array(1).

Kurt

From: glen herrmannsfeldt on
Kurt Kallblad wrote:
(snip)

> As I said I'm not familiar with g95. But compilers some times give
> diagnostics far away from the real problem and the OP showed
> later that the routine includes
> do 2 i = i1, i2
> l = l + 1
> 2 array(i) = work(l)
> This seems to address more then one element, thus I still think he
> should consider to change the declaration array(1).

There isn't much reason not to change the (1) to (*), but it won't
change much in most cases. With (1), bounds checking will attempt
to check with 1 as the dimension, with (*) it won't check the upper
bound at all.

The statements shown originally didn't read or write with array
or work. The OP should be sure that each READ reads the data
corresponding to the appropriate WRITE.

-- glen

-- glen