Read problem in fortran for matrices

  • Context: Fortran 
  • Thread starter Thread starter autobot.d
  • Start date Start date
  • Tags Tags
    Fortran Matrices
Click For Summary

Discussion Overview

The discussion revolves around reading matrix data from files in Fortran, particularly focusing on issues encountered when transitioning from MATLAB data formats. Participants explore various coding approaches, error messages, and the relevance of Fortran in modern programming contexts.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Homework-related

Main Points Raised

  • One participant shares a Fortran program that encounters a runtime error when attempting to read a matrix from a file, suggesting that the issue may stem from the way the data is structured in the file.
  • Another participant proposes an alternative method to read the matrix by first reading a single variable and then assigning it to the matrix, indicating a potential misunderstanding of how the READ statement operates.
  • A suggestion is made to replace nested DO loops with a single READ statement that reads the entire matrix in one go, which is noted to work effectively by a later participant.
  • A participant expresses curiosity about the relevance of Fortran, prompting a discussion about its utility in engineering and scientific computations compared to other languages like MATLAB and Python.
  • Concerns are raised about the proper handling of file operations in subroutines, with one participant noting issues with reading and writing data, leading to confusion about the state of the output.
  • Another participant reflects on the historical context of Fortran, expressing skepticism about its future relevance for new applications while acknowledging its continued use in legacy systems.
  • One participant shares a resolution to their file handling issue by changing the file unit number, indicating that certain unit numbers may be reserved by compilers.
  • There is a mention of Fortran's strengths in high-performance computing contexts, such as using Open_MPI and CUDA, suggesting that it still holds value for specific applications despite its perceived antiquity.

Areas of Agreement / Disagreement

Participants express a range of views on the relevance of Fortran, with some acknowledging its utility in specific fields while others argue it is outdated for new applications. The discussion on coding practices and file handling also reveals differing opinions on the best approaches to take.

Contextual Notes

Participants note various limitations and assumptions regarding file structure, the handling of matrix data, and the implications of using specific file unit numbers. There are unresolved questions about the best practices for reading and writing data in Fortran.

Who May Find This Useful

This discussion may be useful for students learning Fortran, engineers working with legacy code, and those interested in the practical applications of Fortran in scientific computing.

autobot.d
Messages
67
Reaction score
0
Have data that is coming from Matlab and want to read it into Fortran. Simple example of what I have:

Code:
PROGRAM file_read

IMPLICIT NONE

REAL, ALLOCATABLE :: read_matrix(:,:)
INTEGER :: i,j

OPEN(1,FILE = 'data_wanted.prn', ACTION = 'READ', STATUS = 'OLD')

do i = 1,50
do j = 1,25

READ(1,*) read_matrix(i,j)

end do
end do

END PROGRAM file_read

I have tried csv, dat, prn file extensions. If I get rid of one of the loops and just read in a vector than I am fine. As soon as I try read in the whole matrix I get the error:

Fortran runtime error: End of file

Also, this code worked for me before, but that is when Fortran wrote the data file.

Any help is appreciated. Thanks.
 
Technology news on Phys.org
perhaps try reading a single variable say x and then do an assignment of x to read_matrix:

read(1,*) x
read_matrix(i,j)=x

I'm thinking the read_matrix is telling the compiler to do an internal loop for you to load the whole thing.
 
Each READ statement starts reading a new line from the file. If you have more than one number on each line, that is not what you want. (If you get rid of one of the loops, the program probably "runs", but reads in the wrong numbers).

Try replacing the DO loops with

READ(1,*) ((read_matrix(i,j),j=1,25),i=1,50)

That will read all the numbers from the each line of the file, not just the first one.
 
AlphZero, thank you. Worked perfectly.
I would like to ask since it looks like you are in the engineering field and know fortran, how relevant is fortran?

Just learning it this semester for a class and was wondering.

Thanks again.
 
Also one more question.

I am using a subroutine to call in all my files. This subroutine is in a module.

My main program calls the subroutine with empty but allocatted matrices

Code:
Program Test

IMPLICIT NONE

INTEGER :: num
REAL, ALLOCATABLE :: test_matrix(:,:)

Allocate(test_matrix(5,5))

call file_open(num,test_matrix)!This does not print anything, any output is fine now, format later
write(*,*) test_matrix
write(*,*) num

END PROGRAM test

!*****************************************************

SUBROUTINE file_open(num,test_matrix)

IMPLICIT NONE

INTEGER :: num
REAL, ALLOCATABLE :: test_matrix(:,:)

OPEN (1,file='num_file.dat',ACTION = 'READ', STATUS = 'OLD')
READ(1,*) num

OPEN (2,file='test_matrix_file.dat',ACTION='READ','STATUS='OLD)
READ(2,*) ((test_matrix(i,j),i=1,5),j=1,5)

close(1)
close(2)

END SUBROUTINE file_open

Maybe how I am calling the matrices, I am not sure. Thanks for the help.
 
Here is your code...fixed.

Code:
Program Test

IMPLICIT NONE

INTEGER :: num, m, n
REAL, ALLOCATABLE :: test_matrix(:,:)

m = 5
n = 5
Allocate(test_matrix(m,n))

call file_open(num,m,n,test_matrix)


!This does not print anything, any output is fine now, format later
write(*,*) test_matrix
write(*,*) num

END PROGRAM test

!*****************************************************

SUBROUTINE file_open(num,m,n,test_matrix)

IMPLICIT NONE

INTEGER :: i,j,num, m, n
REAL, dimension(m,n) :: test_matrix

!OPEN (1,file='num_file.dat',ACTION = 'READ', STATUS = 'OLD')
!READ(1,*) num

OPEN (2,file='test_matrix_file.dat',ACTION='READ',STATUS='OLD')
READ(2,*) ((test_matrix(i,j),i=1,m),j=1,m)

!close(1)
close(2)

END SUBROUTINE file_open

As far as Fortran being relevant...well, you are going to find that most people don't care for Fortran.

For what I do (engineering calculations, physics modeling, etc.) I find Fortran as good as any; actually, it is easier to learn and program than C and C++. If you are going to want to create GUI or carry out visualizations, then I would switch to Python...you can easily call fortran from python with f2py.

As you may be learning, Fortran can handle arrays a-la-matlab, which is pretty handy; typical loops can be handle in a single line, and the code lends itself for optimization for multiple processors, etc.

For engineering calculations, Fortran is great; but it is not a systems programming language, it is a FORmula TRANslator.
 
Most of the engineers I know use MatLab extensively.
 
The engineers/physicists I know use MATLAB to come up with the problem then write it in C/C++/Fortran to parallelize it if is considered computationally needed.
 
That modification to the code did not work gsal, but thanks for trying to help.
When I comment out

close(2)

I get the error

Fortran runtime error: Cannot write to file opened for READ

referring to the file opened for the array

if I leave close(2) there, then the main program does not write to the terminal, it just comes up blank.

If I don't have the read statement in the subroutine then I do get back a 2d array of zeros, which at least there is a baseline.

Thanks for the help.
 
  • #10
autobot.d said:
how relevant is fortran?

There's a lot of Fortran code still being used, and it's not economic to convert it all to a different language without adding any value.

However IMO Fortran is pretty much past its sell by date for NEW applications. The original language design was intended entirely for off-line (batch) computation, and reading and writing files a line at a time rather than a character at a time, simply because that was the only way most computers worked back in 1960. By 1980 there were a set of non-standard extensions to Fortran IV (or Fortran 77, which was pretty much the same language) which every "real Fortran programmer" knew about, and every serious Fortran compiler implemented. Back then, people (including me) were quite happily writing Fortran code using data structures like dynamcially allocated multiply linked lists, and designing programs using OO ideas like classes and inheritance, that ran on a range of hardware and operating systems as different from each other as say IBM mainframes, Cray supercomputers, and assorted proprietary versions of Unix, without any need for the "improvements" in the language to "officially" support what already existed unofficially.

IMO F90 was basically a political exercise, and the standards committee did an excellent job of redesigning a horse to look like a camel. Adding ever more features to the language in later versions hasn't disguised that fact.

I don't complain much about maintaining hundreds of thousands of lines of Fortran code as part of my job (if only because most of it is still F77 that hasn't been obfuscated by the "standards police") but Fortran wouldn't be my language of choice for writing any completely new application. And F90/95 wouldn't be my language of choice to write ANY application. Period. No exceptions. Life's too short to waste on typnig nonsense like "REAL, ALLOCATABLE :: test_matrix(:,:)" when you can easily find half a dozen other languages (including "real world but nonstandard" F77!) that express the same idea in half the number of keysstrokes.
 
Last edited:
  • #11
I figured it out. I was using Open(6,blahblah), and then I vaguely remembered some compilers dedicate the first few numbers for something (correct me if I am wrong). Anyways, changed 6 to 50 and now works.
Thank for the help.

Fortran does seem antiquated, but it seems like for heavy duty calculations it is a must, especially for using Open_MPI, Open_MP, and CUDA. Does this seem accurate?

Thanks again.
 

Similar threads

  • · Replies 8 ·
Replies
8
Views
2K
  • · Replies 4 ·
Replies
4
Views
3K
  • · Replies 5 ·
Replies
5
Views
5K
  • · Replies 12 ·
Replies
12
Views
3K
  • · Replies 17 ·
Replies
17
Views
7K
  • · Replies 3 ·
Replies
3
Views
2K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 4 ·
Replies
4
Views
3K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 8 ·
Replies
8
Views
2K