There is 3 columns in the file i'm reading and I want to average each column and take the std. The code compiles now, but nothing is being printed.
Here is my code:
program cardata
implicit none
real, dimension(291) :: x
intEGER I,N
double precision date, odometer, fuel
real :: std=0
real :: xbar=0
open(unit=10, file="car.dat", FOrm="FORMATTED", STATUS="OLD", ACTION="READ")
read(10,*) N
do I=1,N
read(10,*) x(I)
xbar= xbar +x(I)
enddo
xbar = xbar/N
DO I =1,N
std =std +((x(I) -xbar))**2
enddo
std = SQRT((std / (N - 1)))
print*,'mean:',xbar
print*, 'std deviation:',std
close(unit=10)
end program cardata
I am fairly new to this, any input will be greatly appreciated.
Example of car.dat:
date odometer fuel
19930114 298 22.4
19930118 566 18.1
19930118 800 18.9
19930121 960 15.8
19930125 1247 19.8
19930128 1521 17.1
19930128 1817 19.8
19930202 2079 18.0
19930202 2342 10.0
19930209 2511 16.4
19930212 2780 16.7
19930214 3024 19.0
19930215 3320 17.7
19930302 3560 16.4
19930312 3853 18.8
19930313 4105 18.5
From the car.dat that you gave in the comments, it's surprising that the program doesn't show anything. When I run it, it shows a very clear runtime error:
$ gfortran -o cardata cardata.f90
$ ./cardata
At line 12 of file cardata.f90 (unit = 10, file = 'car.dat')
Fortran runtime error: Bad integer for item 1 in list input
You seem to be copying code from another example without really understanding what it does. The code, as you wrote it, expects the file car.dat to be in a certain format: First an integer, which corresponds to the number of items in the file, then a single real per line. So something like this:
5
1.2
4.1
2.2
0.4
-5.2
But with your example, the first line contains text (that is, the description of the different columns), and when it tries to parse that into an integer (N) it must fail.
I will not give you the complete example, as I have the nagging suspicion that this is some sort of homework from which you are supposed to learn something. But here are a few hints:
You can easily read several values per line:
read(10, *) date(I), odometer(I), fuel(I)
I'm assuming here that, different to your program, date, odometer, and fuel are arrays. date and odometer can be integer, but fuel must be real (or double precision, but that's not necessary for these values).
You need to jump over the first line before you can start. You can just read the line into a dummy character(len=64) variable. (I picked len=64, but you can pick any other length that you feel confident with, but it should be long enough to actually contain the whole line.)
The trickiest bit is how to get your N as it is not given at the beginning of the file. What you can do is this:
N = 0
readloop : do
read(10, fmt=*, iostat=ios) date(N+1), odometer(N+1), fuel(N+1)
if (ios /= 0) exit readloop
N = N + 1
end do readloop
Of course you need to declare INTEGER :: ios at the beginning of your program. This will try to read the values into the next position on the arrays, and if it fails (usually because it has reached the end of the file) it will just end.
Note that this again expects date, odometer, and fuel to be arrays, and moreover, to be arrays large enough to contain all values. If you can't guarantee that, I recommend reading up on allocatable arrays and how to dynamically increase their size.
Related
I have a section in a program that writes a direct-access binary file as follows:
open (53, file=filename, form='unformatted', status='unknown',
& access='direct',action='write',recl=320*385*8)
write (53,rec=1) ulat
write (53,rec=2) ulng
close(53)
This program is compiled with ifort. However, I cannot reconstruct the data correctly if I read the data file from a different program compiled with gfortran. If the program reading the data is also compiled in ifort, then I can correctly reconstruct the data. Here's the code reading the data file:
OPEN(53, FILE=fname, form="unformatted", status="unknown", access="direct", action="read", recl=320*385*8)
READ(53,REC=2) DAT
I do not understand why this is happening? I can read the first record correctly with both compilers, it's the second record that I cannot reconstruct properly if I mix the compilers.
Ifort and gfortran do not use the same block size for record length by default. In ifort, the value of recl in your open statement is in 4-byte blocks, so your record length isn't 985,600 bytes, it is 3,942,400 bytes long. That means the records are written at intervals of 3.9 million bytes.
gfortran uses a recl block size of 1 byte and your record length is 985,600 byes. When you read the first record, everything works, but when you read the second record you look at 985,600 bytes into the file but the data is at 3,942,400 bytes into the file. This also means you are wasting a ton of data in the file, as you are using only 1/4 of its size.
There are a couple ways to fix this:
In ifort specify recl in 4-byte blocks, e.g. 320*385*2 instead of *8
In ifort, use the compile flag -assume byterecl to have recl values interpreted as bytes.
In gfortran compensate for the size and use recl=320*385*32 so that your reads are correctly positioned.
A better way, however, is to engineer agnosticism in the recl unit size. You can use inquire to figure out the recl of an array. For example:
real(kind=wp), allocatable, dimension(:,:) :: recltest
integer :: reclen
allocate(recltest(320,385))
inquire(iolength=reclen) recltest
deallocate(recltest)
...
open (53, file=filename, form='unformatted', status='unknown',
& access='direct',action='write',recl=reclen)
...
OPEN(53, FILE=fname, form="unformatted", status="unknown", &
access="direct", action="read", recl=reclen)
This will set reclen to the value needed to store a 320x385 array based on the that compilers base unit for record length. If you use this when both writing and reading your code will work with both compilers without having to use compile-time flags in ifort or compensate with hardcoded recl differences between compilers.
An illustrative example
Testcase 1
program test
use iso_fortran_env
implicit none
integer(kind=int64), dimension(5) :: array
integer :: io_output, reclen, i
reclen = 5*8 ! 5 elements of 8 byte integers.
open(newunit=io_output, file='output', form='unformatted', status='new', &
access='direct', action='write', recl=reclen)
array = [(i,i=1,5)]
write (io_output, rec=1) array
array = [(i,i=101,105)]
write (io_output, rec=2) array
array = [(i,i=1001,1005)]
write (io_output, rec=3) array
close(io_output)
end program test
This program writes an array of 5 8-byte integers 3 times to the file in records 1,2 and 3. The array is 5*8 bytes and I have hardcoded that number as the recl value.
Testcase 1 with gfortran 5.2
I compiled this testcase with the command line:
gfortran -o write-gfortran write.f90
This produces the output file (interpreted with od -A d -t d8):
0000000 1 2
0000016 3 4
0000032 5 101
0000048 102 103
0000064 104 105
0000080 1001 1002
0000096 1003 1004
0000112 1005
0000120
The arrays of 5 8-bye elements are packed contiguously into the file and record number 2 (101 ... 105) starts where we would expect it to at offset 40, which is the recl value in the file 5*8.
Testcase 1 with ifort 16
This is compiled similarly:
ifort -o write-ifort write.f90
And this, for the exact same code, produces the output file (interpreted with od -A d -t d8):
0000000 1 2
0000016 3 4
0000032 5 0
0000048 0 0
*
0000160 101 102
0000176 103 104
0000192 105 0
0000208 0 0
*
0000320 1001 1002
0000336 1003 1004
0000352 1005 0
0000368 0 0
*
0000480
The data is all there but the file is full of 0 valued elements. The lines starting with * indicate every line between the offsets is 0. Record number 2 starts at offset 160 instead of 40. Notice that 160 is 40*4, where 40 is our specified recl of 5*8. By default ifort uses 4-byte blocks, so a recl of 40 means a physical record size of 160 bytes.
If code compiled with gfortran were to read this, records 2,3 and 4 would contain all 0 elements and a read of record 5 would correctly read the array written as record 2 by ifort. An alternative to have gfortran read record 2 where it lies in the file would be to use recl=160 (4*5*4) so that the physical record size matches what was written by ifort.
Another consequence of this is wasted space. Over-specifying the recl means you are using 4 times the necessary disk space to store your records.
Testcase 1 with ifort 16 and -assume byterecl
This was compiled as:
ifort -assume byterecl -o write-ifort write.f90
And produces the output file:
0000000 1 2
0000016 3 4
0000032 5 101
0000048 102 103
0000064 104 105
0000080 1001 1002
0000096 1003 1004
0000112 1005
0000120
This produces the file as expected. The command line argument -assume byterecl tells ifort to interpret any recl values as bytes rather than double words (4-byte blocks). This will produce writes and reads that match code compiled with gfortran.
Testcase 2
program test
use iso_fortran_env
implicit none
integer(kind=int64), dimension(5) :: array
integer :: io_output, reclen, i
inquire(iolength=reclen) array
print *,'Using recl=',reclen
open(newunit=io_output, file='output', form='unformatted', status='new', &
access='direct', action='write', recl=reclen)
array = [(i,i=1,5)]
write (io_output, rec=1) array
array = [(i,i=101,105)]
write (io_output, rec=2) array
array = [(i,i=1001,1005)]
write (io_output, rec=3) array
close(io_output)
end program test
The only difference in this testcase is that I am inquiring the proper recl to represent my 40-byte array (5 8-byte integers).
The output
gfortran 5.2:
Using recl= 40
ifort 16, no options:
Using recl= 10
ifort 16, -assume byterecl:
Using recl= 40
We see that for the 1-byte blocks used by gfortran and ifort with the byterecl assumption that recl is 40, which equals our 40 byte array. We also see that by default, ifort uses a recl of 10, which means 10 4-byte blocks or 10 double words, both of which mean 40 bytes. All three of these testcases produce identical file output and read/writes from either compiler will function properly.
Summary
To have record-based, unformatted, direct data be portable between ifort and gfortran the easiest option is to just add -assume byterecl to the flags used by ifort. You really should have been doing this already since you are specifying record lengths in bytes, so this would be a straightforward change that probably has no consequences for you.
The other alternative is to not worry about the option and use the inquire intrinsic to query the iolength for your array.
I am trying to use REFPROPs HSFLSH subroutine to compute properties for steam.
When the same state property is calculated over multiple iterations
(fixed enthalpy and entropy (Enthalpy = 50000 J/mol & Entropy = 125 J/mol),
the time taken to compute using HSFLSH after every 4th/5th iteration increases to about 0.15 ms against negligible amount of time for other iterations. This is turning problematic because my program places call to this subroutine over several thousand times. Thus leading to abnormally huge program run times.
The program used to generate the above log is here:
C refprop check
program time_check
parameter(ncmax=20)
dimension x(ncmax)
real hkj,skj
character hrf*3, herr*255
character*255 hf(ncmax),hfmix
C
C SETUP FOR WATER
C
nc=1 !Number of components
hf(1)='water.fld' !Fluid name
hfmix='hmx.bnc' !Mixture file name
hrf='DEF' !Reference state (DEF means default)
call setup(nc,hf,hfmix,hrf,ierr,herr)
if (ierr.ne.0) write (*,*) herr
call INFO(1,wm,ttp,tnbp,tc,pc,dc,zc,acf,dip,rgas)
write(*,*) 'Mol weight ', wm
h = 50000.0
s = 125.0
c
C
DO I=1,NCMAX
x(I) = 0
END DO
C ******************************************************
C THIS IS THE ACTUAL CALL PLACE
C ******************************************************
do I=1,100
call cpu_time(tstrt)
CALL HSFLSH(h,s,x,T_TEMP,P_TEMP,RHO_TEMP,dl,dv,xliq,xvap,
& WET_TEMP,e,
& cv,cp,VS_TEMP,ierr,herr)
call cpu_time(tstop)
write(*,*),I,' time taken to run hsflsh routine= ',tstop - tstrt
end do
stop
end
(of course you will need the FORTRAN FILES, which unfortunately I cannot share since REFPROP isn't open source)
Can someone help me figure out why is this happening.?
P.S : The above code was compiled using gfortran -fdefault-real-8
UPDATE
I tried using system_clock to time my computations as suggested by #Ross below. The results are uniform across the loop (image below). I will have to find alternate ways to improve computation speed I guess (Sigh!)
I don't have a concrete answer, but this sort of behaviour looks like what I would expect if all calls really took around 3 ms, but your call to CPU_TIME doesn't register anything below around 15 ms. Do you see any output with time taken less than, say 10 ms? Of particular interest to me is the approximately even spacing between calls that return nonzero time - it's about even at 5.
CPU timing can be a tricky business. I recommended in a comment that you try system_clock, which can be higher precision than CPU_TIME. You said it doesn't work, but I'm unconvinced. Did you pass a long integer to system_clock? What was the count_rate for your system? Were all the times still either 15 or 0 ms?
I have a code as following:
program th
implicit none
integer N1
integer maxi,ei,Nc,ns,na
real CH1,CH2
OPEN(unit=1,file='input_file',status="old")
read(1,*) ns !!!
read(1,*) ei !!!!!!!!!!!!!!!
read(1,*) maxi!!!!!!!!!!!!!!!!!!!
read(1,*) N1!!!!!!!!!!!!!!!!
close(unit=1)
CH1 = 0.07
CH2 = -0.35
Na = INT(abs(2.*((N1/2)*CH1 + (N1/2)*CH2)))
write(*,*) Na,abs(2.*((real(N1)/2.)*CH1 + (real(N1)/2.)*CH2));stop
end program th
and the input file is
1 !!!!!!!!!!!
1 !!!!!!!!!!
1 !!!
1600
Then I compile it with
ifort -O3 -autodouble t1.f90 -o out
but when I execute it I get 447 for na which is not correct. The correct answer is 448.
This problem can be understood by investigating the numbers upto their full precision.
The number 0.07 is 7.0000000298023224E-02 in single precision and 7.0000000000000007E-02 in double precision. The number 800 can be represented exactly in both models.
However, the product of these numbers is approximately 56.000000238418579 and 56.000000000000006, respectively. Due to the available precision, the first gets rounded towards 56 (in single precision) and the second towards 56.000000000000007 (in double precision).
As a result, the calculation in single precision "gains" some precision by rounding in the "right" direction.
Concerning the different behaviour of ifort 16 mentioned by #casey, I guess there are some differences in rearranging the equation or maybe use of excess-precision for intermediate results. Though, this is only a guess.
I have a section in a program that writes a direct-access binary file as follows:
open (53, file=filename, form='unformatted', status='unknown',
& access='direct',action='write',recl=320*385*8)
write (53,rec=1) ulat
write (53,rec=2) ulng
close(53)
This program is compiled with ifort. However, I cannot reconstruct the data correctly if I read the data file from a different program compiled with gfortran. If the program reading the data is also compiled in ifort, then I can correctly reconstruct the data. Here's the code reading the data file:
OPEN(53, FILE=fname, form="unformatted", status="unknown", access="direct", action="read", recl=320*385*8)
READ(53,REC=2) DAT
I do not understand why this is happening? I can read the first record correctly with both compilers, it's the second record that I cannot reconstruct properly if I mix the compilers.
Ifort and gfortran do not use the same block size for record length by default. In ifort, the value of recl in your open statement is in 4-byte blocks, so your record length isn't 985,600 bytes, it is 3,942,400 bytes long. That means the records are written at intervals of 3.9 million bytes.
gfortran uses a recl block size of 1 byte and your record length is 985,600 byes. When you read the first record, everything works, but when you read the second record you look at 985,600 bytes into the file but the data is at 3,942,400 bytes into the file. This also means you are wasting a ton of data in the file, as you are using only 1/4 of its size.
There are a couple ways to fix this:
In ifort specify recl in 4-byte blocks, e.g. 320*385*2 instead of *8
In ifort, use the compile flag -assume byterecl to have recl values interpreted as bytes.
In gfortran compensate for the size and use recl=320*385*32 so that your reads are correctly positioned.
A better way, however, is to engineer agnosticism in the recl unit size. You can use inquire to figure out the recl of an array. For example:
real(kind=wp), allocatable, dimension(:,:) :: recltest
integer :: reclen
allocate(recltest(320,385))
inquire(iolength=reclen) recltest
deallocate(recltest)
...
open (53, file=filename, form='unformatted', status='unknown',
& access='direct',action='write',recl=reclen)
...
OPEN(53, FILE=fname, form="unformatted", status="unknown", &
access="direct", action="read", recl=reclen)
This will set reclen to the value needed to store a 320x385 array based on the that compilers base unit for record length. If you use this when both writing and reading your code will work with both compilers without having to use compile-time flags in ifort or compensate with hardcoded recl differences between compilers.
An illustrative example
Testcase 1
program test
use iso_fortran_env
implicit none
integer(kind=int64), dimension(5) :: array
integer :: io_output, reclen, i
reclen = 5*8 ! 5 elements of 8 byte integers.
open(newunit=io_output, file='output', form='unformatted', status='new', &
access='direct', action='write', recl=reclen)
array = [(i,i=1,5)]
write (io_output, rec=1) array
array = [(i,i=101,105)]
write (io_output, rec=2) array
array = [(i,i=1001,1005)]
write (io_output, rec=3) array
close(io_output)
end program test
This program writes an array of 5 8-byte integers 3 times to the file in records 1,2 and 3. The array is 5*8 bytes and I have hardcoded that number as the recl value.
Testcase 1 with gfortran 5.2
I compiled this testcase with the command line:
gfortran -o write-gfortran write.f90
This produces the output file (interpreted with od -A d -t d8):
0000000 1 2
0000016 3 4
0000032 5 101
0000048 102 103
0000064 104 105
0000080 1001 1002
0000096 1003 1004
0000112 1005
0000120
The arrays of 5 8-bye elements are packed contiguously into the file and record number 2 (101 ... 105) starts where we would expect it to at offset 40, which is the recl value in the file 5*8.
Testcase 1 with ifort 16
This is compiled similarly:
ifort -o write-ifort write.f90
And this, for the exact same code, produces the output file (interpreted with od -A d -t d8):
0000000 1 2
0000016 3 4
0000032 5 0
0000048 0 0
*
0000160 101 102
0000176 103 104
0000192 105 0
0000208 0 0
*
0000320 1001 1002
0000336 1003 1004
0000352 1005 0
0000368 0 0
*
0000480
The data is all there but the file is full of 0 valued elements. The lines starting with * indicate every line between the offsets is 0. Record number 2 starts at offset 160 instead of 40. Notice that 160 is 40*4, where 40 is our specified recl of 5*8. By default ifort uses 4-byte blocks, so a recl of 40 means a physical record size of 160 bytes.
If code compiled with gfortran were to read this, records 2,3 and 4 would contain all 0 elements and a read of record 5 would correctly read the array written as record 2 by ifort. An alternative to have gfortran read record 2 where it lies in the file would be to use recl=160 (4*5*4) so that the physical record size matches what was written by ifort.
Another consequence of this is wasted space. Over-specifying the recl means you are using 4 times the necessary disk space to store your records.
Testcase 1 with ifort 16 and -assume byterecl
This was compiled as:
ifort -assume byterecl -o write-ifort write.f90
And produces the output file:
0000000 1 2
0000016 3 4
0000032 5 101
0000048 102 103
0000064 104 105
0000080 1001 1002
0000096 1003 1004
0000112 1005
0000120
This produces the file as expected. The command line argument -assume byterecl tells ifort to interpret any recl values as bytes rather than double words (4-byte blocks). This will produce writes and reads that match code compiled with gfortran.
Testcase 2
program test
use iso_fortran_env
implicit none
integer(kind=int64), dimension(5) :: array
integer :: io_output, reclen, i
inquire(iolength=reclen) array
print *,'Using recl=',reclen
open(newunit=io_output, file='output', form='unformatted', status='new', &
access='direct', action='write', recl=reclen)
array = [(i,i=1,5)]
write (io_output, rec=1) array
array = [(i,i=101,105)]
write (io_output, rec=2) array
array = [(i,i=1001,1005)]
write (io_output, rec=3) array
close(io_output)
end program test
The only difference in this testcase is that I am inquiring the proper recl to represent my 40-byte array (5 8-byte integers).
The output
gfortran 5.2:
Using recl= 40
ifort 16, no options:
Using recl= 10
ifort 16, -assume byterecl:
Using recl= 40
We see that for the 1-byte blocks used by gfortran and ifort with the byterecl assumption that recl is 40, which equals our 40 byte array. We also see that by default, ifort uses a recl of 10, which means 10 4-byte blocks or 10 double words, both of which mean 40 bytes. All three of these testcases produce identical file output and read/writes from either compiler will function properly.
Summary
To have record-based, unformatted, direct data be portable between ifort and gfortran the easiest option is to just add -assume byterecl to the flags used by ifort. You really should have been doing this already since you are specifying record lengths in bytes, so this would be a straightforward change that probably has no consequences for you.
The other alternative is to not worry about the option and use the inquire intrinsic to query the iolength for your array.
I'm reading an old book I found in a second-hand book shop (again). This one is called "Fortran techniques - with special reference to non-numerical applications", by A. Colin Day, published by Cambridge University Press in 1972. It is, after all, very important to keep up with the latest in software development ;-)
This book claims to cover Fortran-66 (X3.9-1966), aka Fortran-IV, with a minor departure from that standard for DATA statements which isn't relevant here.
The trouble is, the book seems to leave a lot to guesswork, and my guesses are pretty uncertain WRT the DO loop. This is in chapter 1, so not a very good sign.
Here is one example...
DO 15 I = 1, 87
J = I - 44
In the DO line, 1 and 87 seem to represent the inclusive range for the loop - I takes values 1 to 87 inclusive, so J takes values -43 to +43 inclusive. However, what does the 15 represent?
Another example is...
N = 1
DO 33 I = 1, 10
...
33 N = N + N
In this case, 33 looks like a label or line number - presumably the last line executed before the loop repeats (or exits). But 33 is an odd number to choose just as an arbitrary label.
EDIT That was a mistake - see the answer by duffymo - How do `DO` loops work in Fortran 66?
And the very next example after that is...
DO 33 I = 1, 10
N = 2 ** (I-1)
Again using the same 33, but without any line being explicitly labelled with it.
Am I being confused because these are short snippets taken out of context? What does the n in DO n ... represent?
Here is a complete program that should answer some of your questions. One can easily test this history question ... FORTRAN IV is still supported by numerous compilers, though portions of FORTRAN IV are either officially obsolescent or, in my opinion, should be obsolete. I compiled and checked this program with both g77 (which is close to obsolete since it is long unsupported) and gfortran.
Here is a sample program:
implicit none
integer i
real q
q = 1.0
do i=1, 10
q = q * 1.5
end do
write (6, *) "modern loop: q =", q
q = 1.0
do 100 i=1, 10
q = q * 1.5
100 continue
write (6, *) "loop with continue: q =", q
q = 1.0
do 200 i=1, 10
200 q = q * 1.5
write (6, *) "loop without continue: q =", q
stop
end
And how to compile it with gfortran:
gfortran -ffixed-form -ffixed-line-length-none -std=gnu test_loops.for -o test_loops.exe
Re your question: if you terminate the loop with a labeled line that is an executable code, is that line part of the loop? The output of the program clearly shows that the labeled line IS part of the loop. Here is the output of gfortran:
modern loop: q = 57.665039
loop with continue: q = 57.665039
loop without continue: q = 57.665039
The line number tells the code where to go when the loop is complete.
Yes, the numbers are odd, arbitrary, and meaningless. It's part of what made FORTRAN hard to read and understand.
The number 15 known as a "Label" it was decided by the programmer. Depending on organisational standards these numbers were controlled and followed specific rules. Although some programmers didn't keep to standards and their code was a mess; Comments and line indentations were also part of standards followed by most.