Hi. 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.
> Hi. > 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
> 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
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
Nathan wrote: > Hi. > 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
> 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.
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.
> Nathan wrote: > > Hi. > > 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)
> > 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
> > 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.
> 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.
> --
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?
> 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...
Nathan <ngrec...@gmail.com> wrote: > 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
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.
>> 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.
> > 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...
> --
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)
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)
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.
In article <hd1v00$ki...@news.eternal-september.org>,
dpb <n...@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.
> > > 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...
> > --
> 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)
> 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)
> 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
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)
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?
In comp.lang.fortran Nathan <ngrec...@gmail.com> wrote: (big snip)
> 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.)
> In comp.lang.fortran Nathan <ngrec...@gmail.com> wrote: > (big snip)
> > 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
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)?
In comp.lang.fortran Nathan <ngrec...@gmail.com> wrote: (snip)
> 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.
> In comp.lang.fortran Nathan <ngrec...@gmail.com> wrote: > (snip)
> > 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
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?
In article <hd20ph$36...@smaug.linux.pwf.cam.ac.uk>, n...@cam.ac.uk 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.
In comp.lang.fortran Nathan <ngrec...@gmail.com> wrote: (snip)
> 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?
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.)
> In comp.lang.fortran Nathan <ngrec...@gmail.com> wrote: > (snip)
> > 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?
> 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
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?
Nathan <ngrec...@gmail.com> wrote: > 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.
-- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
>> 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.
In comp.lang.fortran Richard Maine <nos...@see.signature> wrote:
>> 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.
> Nathan <ngrec...@gmail.com> wrote: > > 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.
> -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain
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.
My most recent error message when trying to run through MEX: forrtl: severe (30): open failure, unit 10, file c:\(omitted) \dippr.dat Image PC Routine Line Source DFORMD.DLL 7D316849 Unknown Unknown Unknown ... ...
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?
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > 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).
-- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
|
