Fortran formatted read problem (for matlab MEX file)
Nathan
I don't know Fortran well enough to do file i/o, let alone formatted
file i/o.
I am trying to read data into my fortran code that is to be used for
calculations that will be returned to Matlab.
What I have tried, and what doesn't seem to work is as follows:
NFUEL is the fuel number (look at data example below. 1003 corresponds
to METHYL OLEATE)
IF (NFUEL .GT. 1000) THEN
OPEN(13, FILE = 'dipprig.dat', Access = 'sequential',
+ Form = 'formatted', STATUS = 'unknown')
OPEN(14, FILE = 'dipprld.dat', Access = 'sequential',
+ Form = 'formatted', STATUS = 'unknown')
20 FORMAT(I5,A33,5EN12.4)
21 FORMAT(I5,A33,4EN12.4)
NF = -999
DO WHILE (NF .NE. NFUEL .AND. NF .NE. 0) !Read IG
READ(13,20) NF, FUELNAME,IGCOEF(1),IGCOEF(2),IGCOEF(3),
+ IGCOEF(4),IGCOEF(5)
ENDDO
NF = -999
DO WHILE (NF .NE. NFUEL .AND. NF .NE. 0) !Read LD
READ(14,21) NF, FUELNAME,LDCOEF(1),LDCOEF(2),LDCOEF(3),
+ LDCOEF(4)
ENDDO
ENDIF
Examples of the corresponding data files are as follows (the data is
contained within 1 line, for each file)
(dipprig.dat data example):
1003 METHYL OLEATE 3.2997E+05 9.7160E
+05 1.6456E+03 6.7448E+05 7.4800E+02
(dipprld.dat data example):
1003 METHYL OLEATE 2.4755E-01
2.6240E-01 7.6400E+02 3.3247E-01
The data values may contain a - in front of them, depending on the
fuel.
If there is any more information you need to help me, please ask.
I know that this doesn't work because while debugging, nothing is read
into the variables.
-Nathan
Nathan
Ah. One more READ statement that doesn't seem to work. MEX gives me a
message regarding something about input conversion?
"forrtl: severe(64): input conversion error, unit 10, file c:\(OMITTED)
\dippr.dat
etc.
IF (NFUEL .GT. 899) THEN
OPEN (10, FILE = 'dippr.dat', Access = 'sequential',
+ Form = 'formatted', STATUS = 'unknown')
NF = -999
DO WHILE (NF .NE. NFUEL .AND. NF .NE. 0)
READ(10,301) NF, FUELNAME,MW,TBF,TFCF,PC,VC,ZC,ACEN,ZRA,
+ ACENW,VCH
ENDDO
ENDIF
301 FORMAT(I5,A33,3F10.3,E12.4,6F13.5)
Example data in dippr.dat (this example data is all one line):
1003 METHYL OLEATE 296.494 650.930 915.530
1.8565E+02 1.06000 0.21400 1.04940 -1.00000 -1.00000 16.97957
dpb
Well, several things--
You don't show declarations so can't tell what variables are. Implicit
typing would have IG-&LDCOEF() as integer variables so the values that
are non-integers would be wrong at best.
Second, are you sure the IF section is actually being executed?
The formatting appears reasonable except if I count characters it looks
like the spacing for the name is wider than 33 characters.
Note that TAB is not a valid Fortran character; you'll want to make sure
your input data files don't contain same--it's possible maybe that has
something to do w/ the spacing of the data lines.
Too bad your names include embedded spaces, then you could use
list-directed formatting.
OBTW, the OPENs could be more like
OPEN(13, FILE = 'dipprig.dat', STATUS = 'old')
as sequential and formatted will be default.
You don't want "unknown" as a status as it will create an empty file of
that name if one doesn't exist and if you're planning on reading from
it, you had best already have one containing data.
Adding error handling will in the end be desirable altho for
testing/debugging seeing any runtime errors directly is probably just as
useful.
Those are places to start, anyway.
--
Nathan
Hm. Alright. My data files do contain tabs, as I wanted to make them
in a readable format. (They were created through Matlab, after reading
in real data sheets and extracting information). Perhaps I'll try to
find a way to remedy that first. Thanks for pointing that out to me. I
think I understand how the formatting is supposed to work now, but
I'll definitely be back when more errors occur.
My variable declarations are spread across multiple files, I think.
(The code I am working on was passed down to me by previous student
interns, and I am still trying to figure it out. I have no fortran
experience beyond the last couple of months, reading this code)
Some of my variables seem to just appear out of nowhere, with no data
type declaration... Could this be a problem?
-Nathan
dpb
...
> Hm. Alright. My data files do contain tabs, as I wanted to make them
> in a readable format. (They were created through Matlab, after reading
> in real data sheets and extracting information). Perhaps I'll try to
> find a way to remedy that first. Thanks for pointing that out to me. I
> think I understand how the formatting is supposed to work now, but
> I'll definitely be back when more errors occur.
Well, fixing that is pretty easy, just don't write tabs... :)
> My variable declarations are spread across multiple files, I think.
> (The code I am working on was passed down to me by previous student
> interns, and I am still trying to figure it out. I have no fortran
> experience beyond the last couple of months, reading this code)
>
> Some of my variables seem to just appear out of nowhere, with no data
> type declaration... Could this be a problem?
...
Possibly, remember implicit typing rules are i-n are integers by default.
The strongest thing to do would be to add
IMPLICIT NONE
to each routine, but that will undoubtedly require quite some time to
sort out all the errors that will suddenly show up. But, then again, it
could potentially find real errors as well.
The arrays will have to have been declared somewhere/somehow in order to
have become arrays. One would presume they were declared as floats of
default or double precision, but then again, mistakes have been known to
be made...
--
Richard Maine
> Some of my variables seem to just appear out of nowhere, with no data
> type declaration... Could this be a problem?
Yes, very often. That's called implicit typing. It is a common source of
errors for multiple reasons.
If you allow implicit typing, then that means simple typos are likely to
get misinterpreted as new different variables instead of flagged as
errors. This one is quite common.
Also, implicit typing encourages sloppy thinking. This is even more the
case if you think of it as variables just appearing "out of nowhere."
Data type is important. You should think about the appropriate data type
for each and every variable in a program. Sometimes it doesn't take very
much thought at all. But it sure shouldn't be that "the compiler will
take care of making everything right"; it should be your deliberate
choice. Explicitly declaring the type of a variable is at least an
encouragement to think briefly whether it is the appropriate type. It is
certainly so that people are capable of getting into such an automated
mode that writing a declaration doesn't necessarily trigger any thought
about whether it is the appropriate declaration, but at least it serves
as an encouragement.
Implicit typing does work. It is not a problem in the sense that it
necessarily means the code isn't correct. It is just a problem in that
it is error prone. It also makes the code hard to understand when
reading because if you don't see a declaration, you can't tell whether
that means the variable is implicitly declared or that its declaration
is someplace you haven't looked yet (possibly in a separate include file
or module).
Putting an
IMPLICIT NONE
statement in each subroutine will turn off implicit typing. You have to
put that statement near the beginning of the subroutine, after the
subroutine statement, but before almost anything else. (USE statements
do come earlier if you have any of them).
Though if you do that for code that was written using implicit typing,
it will probably generate a lot of error messages at first until you add
declarations for everything.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
> I don't know Fortran well enough to do file i/o, let alone formatted
> file i/o.
(snip)
> 20 FORMAT(I5,A33,5EN12.4)
> 21 FORMAT(I5,A33,4EN12.4)
> 1003 METHYL OLEATE 3.2997E+05 9.7160E
> +05 1.6456E+03 6.7448E+05 7.4800E+02
1234567890123456789012345678901234567890123456789012345678901234567890
Your format gives 5 columns for the integer, 33 for the character variable,
and then 12 for each of the floating point values, but that doesn't
match the data.
More specifically, the first five columns are the integer, the next 33
the character, then 12 each for the rest. You might want to use
the X format descriptor to skip some columns, maybe
20 FORMAT(I5, 3X, A33, 5X, 5EN15.4)
You could also use X between the E descriptors, but it is more usual
to just use a wide enough field, 15 in this case.
You might read the section on FORMAT statemens in your Fortran book.
-- glen
glen herrmannsfeldt
(snip)
>> Examples of the corresponding data files are as follows (the data is
>> contained within 1 line, for each file)
>> (dipprig.dat data example):
>> 1003 METHYL OLEATE 3.2997E+05 9.7160E
>> +05 1.6456E+03 6.7448E+05 7.4800E+02
(snip)
> The formatting appears reasonable except if I count characters it looks
> like the spacing for the name is wider than 33 characters.
Depending on where it is to start and end...
> Note that TAB is not a valid Fortran character; you'll want to make sure
> your input data files don't contain same--it's possible maybe that has
> something to do w/ the spacing of the data lines.
That one I didn't think about. In that case, there are programs
that will convert tabs to the appropriate number of spaces.
> Too bad your names include embedded spaces, then you could use
> list-directed formatting.
Well, with non-advancing I/O one could read the name with A format,
then the rest with list directed. I think you can do that, though
it seems that mixing non-advancing and list directed isn't as
easy as it should be.
-- glen
Nathan
In my main routine, a separate file from my MEX driver file, I have
this:
SUBROUTINE LIQVAP(IDB,NFUEL,NGAS,MTYPE,MNUM,XL, XLIQret, TSATret,
+BTret, NCOMP,ICOMPG,MWG,TCGF,PCG,ACENG,CONC,TCGC,tanang,FUELNAME,
+ICOMP,MW,TBF,TFCF,PC,ZC,ACEN,ZRA,ACENW,VCH,zz,TFCC)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
DOUBLE PRECISION MW, MWG(5), MWMG, MCONC(5), MCONCSUM
DOUBLE PRECISION IGCOEF(5), LDCOEF(4) !DIPPR equation coefficient
variables
DIMENSION ICOMPG(5), ACENG(5), TCGC(5), TCGF(5), XL(20)
DIMENSION PCG(5), CONC(5), ENTHIGG(5), VCG(5), ZCG(5)
DIMENSION IER(11), IERF(7), IERZ1(4), IERZ2(4),IERZ3(4),IERZ4(4)
CHARACTER FUELNAME*45
In the routine used to read in the dippr.dat, I only have
SUBROUTINE FUELSDAT (NFUEL, FUELNAME,ICOMP,MW,TBF,TFCF,PC,ZC,
+ ACEN,ZRA,ACENW,VCH,zz,TFCC)
IMPLICIT DOUBLE PRECISION (A-H,M,O-Z)
CHARACTER FUELNAME*45
In my driver file, as a subroutine (which calls LIQVAP), I have this:
SUBROUTINE liqvapMex(XLIQ,TSAT, BT, nsteps,conv_nfuel,tanang,Ca,
+ DCONC,Ta,rhoa,Tfuel,Snozzle)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
DIMENSION Ta(0:nsteps), rhoa(0:nsteps), Tfuel(0:nsteps)
DIMENSION Snozzle(0:nsteps), pressure(0:nsteps), XL(20)
DIMENSION XLIQ(0:nsteps), TSAT (0:nsteps), BT (0:nsteps)
DIMENSION DCONC(1:5)
DIMENSION ICOMPG(5), ACENG(5), TCGC(5), TCGF(5),PCG(5), CONC(5)
DOUBLE PRECISION MW, MWG(5)
CHARACTER FUELNAME*45
and call the FUELSDAT routine as such (within this liqvapmex
subroutine):
CALL FUELSDAT (NFUEL, FUELNAME,ICOMP,MW,TBF,TFCF,PC,ZC,
+ ACEN,ZRA,ACENW,VCH,zz,TFCC)
Notice that ICOMP,TBF,TFCF,PC,ZC,ACEN,ZRA,ACENW,VCH,zz, and TFCC are
all "poofed" into existence (according to the IMPLICIT DOUBLE
PRECISION declaration above, I presume)
I fixed the formatting for each of my data files to correctly match
the format statements.
The only one I might be concerned with is the E format terms regarding
numbers such as:
9.7160E+02 and the like.
I used the format statement %E15.4 such that from the first white
space until the last digit (2), there are 15 characters and 4
decimals. Is that correct?
I am still receiving errors when trying to run with MEX.
-Nathan
nm...@cam.ac.uk
dpb <no...@non.net> wrote:
>Nathan wrote:
>...
>> Hm. Alright. My data files do contain tabs, as I wanted to make them
>> in a readable format. (They were created through Matlab, after reading
>> in real data sheets and extracting information). Perhaps I'll try to
>> find a way to remedy that first. Thanks for pointing that out to me. I
>> think I understand how the formatting is supposed to work now, but
>> I'll definitely be back when more errors occur.
>
>Well, fixing that is pretty easy, just don't write tabs... :)
Leslie Lamport said:
It has been suggested that building a system that allows the
insertion of tabs into a text file should be a capital offense.
I'm not that extreme; I think that ten years of writing COBOL
code in Novosibirsk would be adequate punishment.
Regards,
Nick Maclaren.
Nathan
Updated data format and format code:
code regarding dippr.dat:
IF (NFUEL .GT. 899) THEN
OPEN (10, FILE = 'dippr.dat', Access = 'sequential',
+ Form = 'formatted', STATUS = 'unknown')
NF = -999
DO WHILE (NF .NE. NFUEL .AND. NF .NE. 0)
READ(10,301) NF, FUELNAME,MW,TBF,TFCF,PC,VC,ZC,ACEN,ZRA,
+ ACENW,VCH
ENDDO
ENDIF
301 FORMAT(I5,A33,3F10.3,E15.4,6F13.5)
dippr.dat data:
1001 METHYL OLEATE 296.494 650.930
915.530 1.8565E+02 1.06000 0.21400 1.04940
-1.00000 -1.00000 16.97957
code regarding dipprig.dat:
OPEN(13, FILE = 'dipprig.dat', Access = 'sequential',
+ Form = 'formatted', STATUS = 'unknown')
20 FORMAT(I5,A33,5E15.4) !IG coef
NF = -999
DO WHILE (NF .NE. NFUEL .AND. NF .NE. 0) !Read IG
READ(13,20) NF, FUELNAME,IGCOEF(1),IGCOEF(2),IGCOEF(3),
+ IGCOEF(4),IGCOEF(5)
ENDDO
dipprig.dat data:
1001 METHYL OLEATE 3.2997E+05 9.7160E
+05 -1.6456E+03 6.7448E+05 7.4800E+02
code regarding dipprld.dat:
OPEN(14, FILE = 'dipprld.dat', Access = 'sequential',
+ Form = 'formatted', STATUS = 'unknown')
21 FORMAT(I5,A33,4E15.4) !LD coef
NF = -999
DO WHILE (NF .NE. NFUEL .AND. NF .NE. 0) !Read LD
READ(14,21) NF, FUELNAME,LDCOEF(1),LDCOEF(2),LDCOEF(3),
+ LDCOEF(4)
ENDDO
dipprld.dat data:
1001 METHYL OLEATE 2.4755E-01
2.6240E-01 7.6400E+02 3.3247E-01
One thing I have a question about:
Trying to run this through fortran (using Compaq Visual Fortran 6.6),
it also does not like to read in files. (I based my formatting for
dippr.dat off of a previous format for reading a different file that
seems to have worked in the past. I'm not certain, however, because I
didn't write it)
I noticed one thing when I received these files to work with: After
opening each file, neither version bothered trying to close the
files...
Could that be another problem?
-Nathan
glen herrmannsfeldt
> The only one I might be concerned with is the E format terms regarding
> numbers such as:
> 9.7160E+02 and the like.
> I used the format statement %E15.4 such that from the first white
> space until the last digit (2), there are 15 characters and 4
> decimals. Is that correct?
That sounds right. For input the .4 doesn't do anything unless
there are no decimal points in the input data. In the days of
cards it was not unusual to specify card columns as before and
after an implied decimal point. It works fairly well for F format
(no exponent) input, but I would not recommend it at all with
an exponent.
(The music generation program recently discussed reads in a large
data file with no decimal points.)
-- glen
Nathan
So reading in 9.7160E+02, I can use F rather than E and disregard
decimals?
I'm a little confused as to what you are trying to tell me.
Why are the decimals unimportant? (or rather, not required)?
-Nathan
glen herrmannsfeldt
> So reading in 9.7160E+02, I can use F rather than E and disregard
> decimals?
> I'm a little confused as to what you are trying to tell me.
> Why are the decimals unimportant? (or rather, not required)?
If you read with F10.4 format and the data field contains 1234567890
then you get the value of 123456.7890, such that four digits are
after the decimal point. If you actually write a decimal point
then it uses that independent of the d part of the descriptor.
For input with an exponent but without a decimal point, the d
part indicates the number of digits after the implied decimal point.
With E10.4 if the input contains 1234E0 you get the value 0.1234,
so it is probably best to use the form with d of 0.
On input, I believe that D, E, and F all do the same thing.
For output you get different results from D, E, and F.
-- glen
Nathan
So...
Should I change my format string?
E15.4 seems like it should work fine, as the decimal is there anyways.
Would that mean that
E15 would return the same thing, because I purposefully placed a
decimal in the data file?
Btw: I still receive errors when trying to read in.
Running in fortran error:
forrtl: severe (24): end-of-file during read, unit 10, file C:\...
...\dippr.dat
Image PC Routine Line Source
LLDebug.exe 00459389 Unknown Unknown Unknown
LLDebug.exe 004591E7 Unknown Unknown Unknown
LLDebug.exe 004583C4 Unknown Unknown Unknown
LLDebug.exe 004587F9 Unknown Unknown Unknown
LLDebug.exe 00453225 Unknown Unknown Unknown
LLDebug.exe 0043B9D6 FUELSDAT 340 fuels.f
LLDebug.exe 00444648 RANGES 43
LiqVapRange.f
LLDebug.exe 004441F9 MAIN$LIQVAPRANGE 10
LiqVapRange.f
LLDebug.exe 00495EE9 Unknown Unknown Unknown
LLDebug.exe 0047B349 Unknown Unknown Unknown
kernel32.dll 7C816FE7 Unknown Unknown Unknown
And, as shown above, this line (304) causes the error:
READ(10,301) NF, FUELNAME,MW,TBF,TFCF,PC,VC,ZC,ACEN,ZRA,
+ ACENW,VCH
As I mentioned before, there is no close statement. Would that cause
this error? If so, where would I place the close?
After the loop of reading?
-Nathan
Ron Shepard
wrote:
> Leslie Lamport said:
>
> It has been suggested that building a system that allows the
> insertion of tabs into a text file should be a capital offense.
> I'm not that extreme; I think that ten years of writing COBOL
> code in Novosibirsk would be adequate punishment.
Even worse than *allowing* tabs is the make utility, which *requires*
tabs in certain places where a regular space is not allowed (but no
error is generated). Of course, I could go on for a while about how
poorly designed the make utility is, but we've all been there, and after
about 30 years, nothing has come along to replace it.
$.02 -Ron Shepard
glen herrmannsfeldt
> Should I change my format string?
> E15.4 seems like it should work fine, as the decimal is there anyways.
> Would that mean that
> E15 would return the same thing, because I purposefully placed a
> decimal in the data file?
The .d is requried, but it could be E15.0, though if you are
sure to always put in a decimal point then E15.4 is fine.
> Btw: I still receive errors when trying to read in.
> Running in fortran error:
> forrtl: severe (24): end-of-file during read, unit 10, file C:\...
> ...\dippr.dat
(snip)
> And, as shown above, this line (304) causes the error:
> READ(10,301) NF, FUELNAME,MW,TBF,TFCF,PC,VC,ZC,ACEN,ZRA,
> + ACENW,VCH
> As I mentioned before, there is no close statement. Would that cause
> this error? If so, where would I place the close?
> After the loop of reading?
The one you should previously had a WHILE loop with a test to exit
at the appropriate point, I believe NF=0. Check that this one has
the appropriate test, and that the appropriate data record (such as
with NF=0) exists. Or you can put an END= option on the READ to
exit the loop.
CLOSE is a very good idea for output files, less important for
input, but it is not the cause of this problem. (Unless you are
trying to read a file twice.)
-- glen
Nathan
Hm. Alright, in this example:
IF (NFUEL .GT. 899) THEN
OPEN (10, FILE = 'dippr.dat', Access = 'sequential',
+ Form = 'formatted', STATUS = 'unknown')
NF = -999
DO WHILE (NF .NE. NFUEL .AND. NF .NE. 0)
READ(10,301) NF, FUELNAME,MW,TBF,TFCF,PC,VC,ZC,ACEN,ZRA,
+ ACENW,VCH
ENDDO
CLOSE(10)
ENDIF
The while loop says to read unit 10 with format 301 while NF is not
equal to NFUEL and NF is not 0.
The NF .NE. 0 part comes into play because the last line of each of my
data files is 0000 END
What do you mean by "unless you are trying to read a file twice"? In
this scenario, is opening my file and reading it within a loop
considered reading it once or reading it as many times as defined by
the while loop?
And if it is the latter case, how can I go about reading the correct
data line into Fortran?
My data lines all start with a number (starting from 1001, 1002, 1003,
(more data will be added later) until 0000)
If I want to read in the third data set (NFUEL = 1003, meaning read
the line starting with 1003), how do I go about doing this?
Is my while statement incorrect?
Does the location of the FORMAT line matter?
Thanks for all your comments and help.
-Nathan
Richard Maine
> On Nov 6, 1:15 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > If you read with F10.4 format and the data field contains 1234567890
> > then you get the value of 123456.7890, such that four digits are
> > after the decimal point. If you actually write a decimal point
> > then it uses that independent of the d part of the descriptor.
But don't *EVER* use that feature of implicit decimal point insertion.
Regard it as just a bit of historical arcania. Even better, forget it
completely, if you can manage that. :-( Put decimal points in your
floating-point data. Always. If you intentionally use this feature, you
should be "punished" by having to prepare all of your input data on
punched cards, where there was at least some reason for this feature in
context. For a second offense, they should take away the keypunch
machine and make you punch the cards by hand.
> Should I change my format string?
> E15.4 seems like it should work fine, as the decimal is there anyways.
> Would that mean that
> E15 would return the same thing, because I purposefully placed a
> decimal in the data file?
No. E15 isn't a valid edit descriptor at all. You have to specify a
number of decimal digits, even though it won't make any difference for
input that has a decimal point; the syntax still requires you put a
number there.
> forrtl: severe (24): end-of-file during read, unit 10, file C:\...
An end-of-file error is from trying to read past the end of the file -
that is more lines than are there.
> And, as shown above, this line (304) causes the error:
> READ(10,301) NF, FUELNAME,MW,TBF,TFCF,PC,VC,ZC,ACEN,ZRA,
> + ACENW,VCH
Well, no, I doubt it. An error like that is not usually caused by a
single line of code. That might be where the error ocurred, but that's
not the same thing as that being the cause. An end of file condition
means that you tried to read past the last line of the file. That is
reasonably likely to be caused by previously executed code, which read
all the lines that were in the file before you got to this one. If
previous code read too many lines from the file, then you can look at
this line of code all day and it won't help you find the problem.
I also don't see that you showed what format 301 looks like; if it was
in some other post in the thread, a quick skim didn't uncover it (and a
careful search is too much bother).
This is a classic case of *WAY* too little context being provided. No
way that anyone can look at that line in isolation and tell you what is
wrong. As I said, there is at least significant chance that the problem
has nothing to do with that line of code at all, but instead with
previous ones. If the problem is related to that line of code, then at
the very least, one would need to see the relevant declarations, the
format statement, and the line from the data file. All of those things.
And together; no having shown in a separate post some declarations that
might or might not even be in the same subroutine or the sam eversion of
the subroutine isn't adequate.
> As I mentioned before, there is no close statement. Would that cause
> this error?
No. Well probably not. A close is optional. I consider it good
programming style, but it isn't required in most cases, particularly
when you are reading a file. The compiler wil automatically close the
file at the end of the program if you don't do so yourself.
One case where lack of a close could be a problem is when you try to
open a file multiple times (say, if your subroutine got called multiple
times in the same run). The effects of an OPEN can be very different
(and surprising) if the file is already opened when the OPEN statement
executes.
glen herrmannsfeldt
>> The one you should previously had a WHILE loop with a test to exit
>> at the appropriate point, I believe NF=0. ?Check that this one has
>> the appropriate test, and that the appropriate data record (such as
>> with NF=0) exists. ?Or you can put an END= option on the READ to
>> exit the loop.
>> CLOSE is a very good idea for output files, less important for
>> input, but it is not the cause of this problem. ?(Unless you are
>> trying to read a file twice.)
> Hm. Alright, in this example:
> IF (NFUEL .GT. 899) THEN
> OPEN (10, FILE = 'dippr.dat', Access = 'sequential',
> + Form = 'formatted', STATUS = 'unknown')
> NF = -999
> DO WHILE (NF .NE. NFUEL .AND. NF .NE. 0)
> READ(10,301) NF, FUELNAME,MW,TBF,TFCF,PC,VC,ZC,ACEN,ZRA,
> + ACENW,VCH
> ENDDO
> CLOSE(10)
> ENDIF
> The while loop says to read unit 10 with format 301 while NF is not
> equal to NFUEL and NF is not 0.
> The NF .NE. 0 part comes into play because the last line of each of my
> data files is 0000 END
It doesn't look like you do much with the data read, but it should
exit the loop when NF is zero. Make sure that the 0000 line is there.
> What do you mean by "unless you are trying to read a file twice"? In
> this scenario, is opening my file and reading it within a loop
> considered reading it once or reading it as many times as defined by
> the while loop?
That is once. (Unless there is another, outer, loop.) If you
do want to read the same file again, you can close and then reopen,
or REWIND it.
> And if it is the latter case, how can I go about reading the correct
> data line into Fortran?
> My data lines all start with a number (starting from 1001, 1002, 1003,
> (more data will be added later) until 0000)
> If I want to read in the third data set (NFUEL = 1003, meaning read
> the line starting with 1003), how do I go about doing this?
> Is my while statement incorrect?
Your READ expects to read an integer, a character string, and some
number of additional values. I believe it is still true for formatted
(not including list directed) input that all blanks will read as zero.
It should consider a short record padded with blanks, enough to fill
out the rest of the list, but I am not sure that all do that.
You might add enough numbers to the 0000 END line to satisfy the
rest of the READ statement.
> Does the location of the FORMAT line matter?
No. It is found by the statement number.
-- glen
glen herrmannsfeldt
>> On Nov 6, 1:15 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> > If you read with F10.4 format and the data field contains 1234567890
>> > then you get the value of 123456.7890, such that four digits are
>> > after the decimal point. If you actually write a decimal point
>> > then it uses that independent of the d part of the descriptor.
> But don't *EVER* use that feature of implicit decimal point insertion.
> Regard it as just a bit of historical arcania. Even better, forget it
> completely, if you can manage that. :-( Put decimal points in your
> floating-point data. Always. If you intentionally use this feature, you
> should be "punished" by having to prepare all of your input data on
> punched cards, where there was at least some reason for this feature in
> context. For a second offense, they should take away the keypunch
> machine and make you punch the cards by hand.
The music program (with the X RANF in it) read a big file all
with implied decimal points. I presume the data originated
on cards, though. I was suggesting E15.0 such that the implied
decimal is where one would expect it, but I agree this feature
should not be used except with cards. (Rare these days.)
Even so, I would say it should not be used with data with an exponent.
-- glen
Nathan
I'm at the point in which Fortran will read the files correctly and
give me my data, but Matlab (through my MEX implementation) won't.
It appears that the only reason why Fortran wasn't doing it right
(after I fixed all of the formattings) was because my data files
either weren't up to date or weren't in the correct directory.
But, still. Why will the MEX version not work? (I realize this is now
leaning towards the Matlab side of things, but for you fortran users,
any and all help is appreciated)
And Richard, the 301 format statement happens to be in the second post
of this thread. Sorry for not repeating myself later. I will try to
put everything together next time I post relevant (or not) code.
-Nathan
Nathan
forrtl: severe (30): open failure, unit 10, file c:\(omitted)
\dippr.dat
Image PC Routine Line Source
...
...
I'm assuming this means that, through matlab, my fortran code doesn't
want to open files to read?
I'm quite confused. What information do you need to help me?
-Nathan
Nathan
until then with no code at home.
Thanks for all your help.
-Nathan
Richard Maine
> In comp.lang.fortran Richard Maine <nos...@see.signature> wrote:
> > But don't *EVER* use that feature of implicit decimal point insertion.
> The music program (with the X RANF in it) read a big file all
> with implied decimal points. I presume the data originated
> on cards, though.
I stick by my recommendation to *NEVER* do it.
I'm aware that there exists code that does it. Hard as it is to believe,
there exist people who don't always follow every one of my
recommendations. :-)
There also exists Fortran code from before when I was making such
recommendations or otherwise paying attention to Fortran. (I did barely
beat Fortran into this world, but at age 2, I wasn't paying a whole lot
of attention to it.)
If you have to read a file without the decimal points, I'd read it as
integers and then convert as appropriate. (Well, first I'd think about
fixing whatever wrote the file, but that isn't always an option).
TideMan
I suspect you are sitting in c:\Matlab (or similar), but your file is
in c:\(omitted)
You need to cd to c:\(omitted)
IMHO, hardwiring the filename into Fortran is bad practice.
You should send it in as a variable.
This way, you can sit in c:\Matlab, but access your file anywhere on
the machine (or the network) without having to cd back and forth all
the time.
glen herrmannsfeldt
(snip)
> I suspect you are sitting in c:\Matlab (or similar), but your file is
> in c:\(omitted)
> You need to cd to c:\(omitted)
> IMHO, hardwiring the filename into Fortran is bad practice.
> You should send it in as a variable.
> This way, you can sit in c:\Matlab, but access your file anywhere on
> the machine (or the network) without having to cd back and forth all
> the time.
Also, watch out for Fortran compilers that follow C escape sequences.
Note that the DOS/Windows OPEN call accepts path names with either /
or \, even though the command line processor does not. It is somewhat
less confusing, especially if you sometimes use other systems, to
use / in path names.
-- glen
Ben Hetland
> Note that TAB is not a valid Fortran character; you'll want to make sure
> your input data files don't contain same--it's possible maybe that has
> something to do w/ the spacing of the data lines.
But..., while TAB may not be a valid "Fortran character" (whatever that
is), and it isn't allowed as character in the source code itself, there
is surely a way to process text files containing them, isn't there?
Those different type of files are, after all, quite distinct entities,
and TAB-delimited text files are a very common way of transferring data.
If not, then how about other ASCII control characters, especially the
BEL, CR, VT and FF ones?
> Too bad your names include embedded spaces, then you could use
> list-directed formatting.
Yes, a common situation where an alternative delimiter such as : ; , or
TAB come to the "rescue" when more advanced schemes of escaping/
embedding them aren't "worth the efford"...
:-)
--
-+-Ben-+-
dpb
Yes, but... :)
There are certainly ways to process tab-delimited files w/ Fortran i/o;
the problem is that one has to write the parsing directly if it is
indeed an embedded tab character or specifically either skip over it w/
an X or T field descriptor or read it as a character w/ an A1 field.
All require the field position be fixed or computable to get the right
position in the input record.
If, otoh, the code which writes the file translates internal tabs to
spaces, there are multiple cases where the user can set what tab spacing
is in number.
All in all, it's just generally simpler on the input end to use
something I'll term "more graceful" as a general coin of phrase.
--
Richard Maine
> Ben Hetland wrote:
> > dpb wrote:
> >> Note that TAB is not a valid Fortran character; you'll want to make sure
> >> your input data files don't contain same-
> > But..., while TAB may not be a valid "Fortran character" (whatever that
> > is), and it isn't allowed as character in the source code itself, there
> > is surely a way to process text files containing them, isn't there?
...
> There are certainly ways to process tab-delimited files w/ Fortran i/o;
> the problem is that one has to write the parsing directly...
Or to put in another way. That's one of those "if you have to ask, then
it is too complicated for you" kind of questions. Sure, it is doable. In
fact, if one understands the basic principles, it is even pretty easy -
enough so that one wouldn't need to ask, except perhaps along the line
of "of course, I could parse it the obvious way, but did I miss some
other option?"
But the compiler's I/O library isn't going to do anything particularly
useful about it. Anyone looking for something on the order of
list-directed I/O is going to be dissapointed... well if they want it to
also be standard conforming and portable. Some compilers might happen to
treat tab as a delimitter for list-directed I/O, but people who count on
that are likely to end up here later wondering why their programs that
were fine on system X don't work on system Y.
Eli Osherovich
> in a readable format. (They were created through Matlab, after reading
> in real data sheets and extracting information). Perhaps I'll try to
> find a way to remedy that first. Thanks for pointing that out to me. I
> think I understand how the formatting is supposed to work now, but
> I'll definitely be back when more errors occur.
In case you create the files you can do it in a simpler/more
appropriate way.
From matlab you can write .mat or netcdf files and then read those
from your fortran program using existing libraries.
Another way to cope with tabs is by pre-processing. On unix you have
tr command or a bunch of scripting languages (pery/python/...) that
can do it with a one-line script.