|
From: Kurt Kallblad on 11 Apr 2008 18:04 "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 11 Apr 2008 18:36 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 11 Apr 2008 19:33 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 12 Apr 2008 16:21 "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 13 Apr 2008 18:45 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
|
Next
|
Last
Pages: 1 2 3 4 Prev: g95: reading more data than the record size (RECL) Next: Sun Fortran on DVD |