simple reading of a derived type

I created a derived type with a couple of 2K (8) vectors, a few strings, logicals, and misc variables for a total of 13 variables. I then dimensioned 100 of them, initialized them, and wrote them out (write (7,) scans). Created clean file but when I tried to read it with same (read(7,*) scans), I got an invalid character on read. Dropping down to a single example (a single instance of the derived type) didn't help. Reducing the size of the vectors to 1K vectors didn't help. Finally, by writing out each component seperately, even some explicitly formated, didn't help. I got around this by writing half of the variables (the two 2K vectors and some long strings) to one very large file and the few other scalar variables to another, very small, file. This I could read. I then tried it with the 100 instance case. Could only read about 30 instances before I got the invalid character error. By breaking up the pieces into 4 files, I could finally read back in the 100 scans.

I'm not a beginner to Fortran but this is the strangest thing I've seen in 40 years with the language.

Bruce

If you want to post a short program I will aim to investigate the problem.

Hi,

Here is a short version of the problem. My 2003 version of f95 writes out the 100 scans fine but generates a bogus 'trying to read an undefined variable' error on trying to read it back in. It doesn't help to initialize all the variables in scans so I took that part out. The latest version of f95 complains instead on the write statement that scans is undefined. tis is a tad frustrating. My first message explains some of the other things that I tried.

Thanks for your help.

module big1

integer, parameter:: maxsize= 2060 !integer, parameter:: maxscans= 100 !maximum number of scans

type ascan integer ndi !number of elements (DIodes) in this scan real*8 wavel(maxsize),flux(maxsize) character stype$*4 !scan,temp,dark,flat,sens character dtype$*2 !lf(lambda-flux),df(diode-f),rr(raw Reticon),rf(reticon file) character name$*128, fullname$*256 !later is full path & name character cur$*128, srec$1023 !operations on scan; full log real8 rlam0,rlam1,rlam2 logical magflag !false= photons/sec cm^2; true= mags/ frequency units (flux) logical useit !false= not to be used
end type ascan

end module big1

program Rettest use big1 type(ascan)scans integer, parameter maxscans= 100 !maximum number of scans

10 open (7,file='testret.dat') write (7,*)scans
print , 'hi' open (7,file='testret.dat') read (7,)scans

end

Bruce Weaver

Bruce

The initial problem with this approach is that, when using list directed input for CHARACTER variables, the data should be enclosed in quotation marks.

Like other compilers, FTN95 outputs a CHARACTER variable without the quotes (when using list directed output). The associated format is not in the Fortran Standard.

There may be other problems as well but I would tackle this one first if I were you.

You could try using unformatted output for example.

A quick thought based on sight of the definition of your derived type and the error message - you're not using Checkmate and falling foul of the 1 in 256 possibility of a single character being UNDEFINED, are you?

[small]Bruce Weaver wrote:[/small] *I don't know what that possibility is *

Checkmate implements UNDEFINED by a specific bytewise bit pattern - Hex80 - so it is possible to get a 'false positive'. The odds get greater as the number of bytes decreases. For character (or integer*1) data there is a 1 in 256 possibility. I work with raw bitmap data a lot and Hex 80 is just as likely as any other value, which has bitten me on occasions ...

I experimened with your program and found that the problem is with the list directed output and input of CHARACTER values. [pre] character(len=5) :: a = '12345', b = 'abcde' real :: r = 12345 write(7, *) a, b, r [/pre]

will give 12345abcde 12345.00

and then [pre] read(7, *) a, b, r [/pre]

will result in a = '12345' ; b = '12345' and an END error reading r

As said: list directed I/O is not symmetric 😦

JvO