forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

simple reading of a derived type

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
weaverwb



Joined: 04 Aug 2005
Posts: 37
Location: Monterey

PostPosted: Thu Aug 04, 2005 1:23 am    Post subject: simple reading of a derived type Reply with quote

I created a derived type with a couple of 2K (*Cool 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
_________________
Bruce+Weaver
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Aug 04, 2005 3:15 am    Post subject: simple reading of a derived type Reply with quote

If you want to post a short program I will aim to investigate the problem.
Back to top
View user's profile Send private message AIM Address
weaverwb



Joined: 04 Aug 2005
Posts: 37
Location: Monterey

PostPosted: Fri Aug 05, 2005 3:47 am    Post subject: simple reading of a derived type Reply with quote

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
real*8 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+Weaver
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Aug 05, 2005 7:47 am    Post subject: simple reading of a derived type Reply with quote

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.

Back to top
View user's profile Send private message AIM Address
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Fri Aug 05, 2005 9:53 am    Post subject: simple reading of a derived type Reply with quote

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?
Back to top
View user's profile Send private message Send e-mail
Anonymous
Guest





PostPosted: Fri Aug 05, 2005 11:42 am    Post subject: simple reading of a derived type Reply with quote

I don't know what that possibility is but I'm trying this on two machines, two different versions of f95, and two different versions of Checkmate.

OBTW, unformatted doesn't help. I'm now off to work on the quotes issue.
Back to top
Anonymous
Guest





PostPosted: Fri Aug 05, 2005 3:11 pm    Post subject: simple reading of a derived type Reply with quote

Hi,

I guess I was (and still am) confused by section 10.10.1.1 of the Fortran 90 Handbook, Complete ANSI/ISO Standard, that claims you can read non-delimited character strings if you meet certain, easily met, conditions. Unformatted, while it seemed like a good idea, didn't work, either.

In any case, following your (implied) suggestion, I just formatted the strings with G format, and that seemed to work.

Thanks for your time.

Back to top
sparge



Joined: 11 Apr 2005
Posts: 371

PostPosted: Mon Aug 08, 2005 3:21 am    Post subject: simple reading of a derived type Reply with quote

[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 ...
Back to top
View user's profile Send private message Send e-mail
JvO



Joined: 18 Aug 2005
Posts: 15

PostPosted: Thu Aug 18, 2005 10:10 am    Post subject: simple reading of a derived type Reply with quote

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 Sad



JvO
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group