I am writing a Fortran program in which one line is written like this
open(unit=un1,file=filenm,form='unformatted',buffered='yes',status='replace',buffercount=127)
I have defined
character*256 filenm.
un1=11
but still I am getting error
"Syntax error at or near =" in that line..
The problem lies in the buffered='yes', which is not standard Fortran, but some vendor extension and your compiler does not recognize it. I would just delete it and also delete the buffercount=127 (mentioned in the comment).
Modern compilers and operating systems allow control of these things (external I/O buffering) by other means. For example, using environment variables in gfortran https://gcc.gnu.org/onlinedocs/gfortran/Runtime.html#Runtime
Related
First: I do not know how to create an MVCE of this problem. I realize that is a big no no for this site, but I frankly there is a lot of expertise here and I don't know a better place to ask this question. Maybe the answer is, post this question <insert other site here>.
The question: any thoughts as to what is going on here, and how can I probe this problem?
Anyway, code base is >10K lines of fortran that is also linking in an open source C++ library, nanort. So its a combined in house code of Fortran and C++ with a lot going on.
Somewhere in the code I have to read in a binary file in C++ and parse it. The problem I am running into is that 10% of the time, the function std::filesystem::exists is telling me the file does not exist, even though it does. In fact, the fortran inquire routine tells me it does exist in the same execution of the program. Furthermore, at the beginning of the program, the std::filesystem::exists routine tells me it does exist.
So here's that layed out in a simple text diagram
program starts
fortran calls C++ -> std::filesystem::exists reports that the file exists
...
many other things happen
...
fortran calls C++ -> std::filesystem::exists reports that the file does not exists and returns to fortran with an error flag
the fortran inquire function reports that the file does in fact exist
Remember, this only happens 10% of the time. The other 90% of the time the program runs fine (as far as I can tell).
System Info:
Mac OSX Big Sur
g++11, with -std=c++17 and -O3
gfortran with -fbounds-check and -O3
Going to answer this one even though it's a little embarrassing.
When passing a fortran character array to a C void function, you pass it as a pointer to a character array. When doing so, you need to make sure that your character array has a null termination at the point where you want it.
Although I was creating a copy of the filename with a null termination, I was passing the non-null terminated string to C++ by mistake. Given the undefined bits of the program, most of the time this was actually succeeding anyway, but sometimes it was not and I was getting a non-null terminated string for a filename that the system was telling me did not exist.
I'm porting a legacy Fortran console app to C# and encountered this statement:
OPEN(UNIT=12,FILE = bufProgress,STATUS='UNKNOWN'
1 ,SHARED,ERR = 9300)
(Indentation as-is.) What does SHARED mean in this context? (And it is part of the OPEN statement due to the 1 used for line continuation, right?)
Things I've found:
There are no variables with this name in the entire program (comprising a single +7k-line file).
This program was at one time compiled with "Digital Visual Fortran 6.0 Professional", a couple decades ago. I believe Intel's Fortran compiler has been used in the past decade, but am not sure.
The file specified by the contents of buffer is (when the program is running as part of its "parent" multi-platform system) being written to by this console app and read from by another process.
There is a commented-out statement just above this statement that looks like this:
c OPEN(UNIT=12,FILE='progress.tmp',STATUS='UNKNOWN'
c 1 ,SHARE='DENYRD',ERR = 9300)
It seems like SHARE='DENYRD' once had a similar semantic at one point?
I've found nothing online regarding SHARED or SHARE in the context of OPEN.
Best reference find-able for me:
Try this site for FORTRAN reference: https://software.intel.com/en-us/intel-fortran-compiler-17.0-user-and-reference-guide
SHARED:
https://software.intel.com/en-us/node/678862
The SHARED specifier indicates that the file is connected for shared
access by more than one program executing simultaneously.
appears to prevent record locking for performance and may not be used in current versions of FORTRAN.
For SHARE=[type]
https://software.intel.com/en-us/node/678861
'DENYRD' Indicates deny-read mode. No process can open the file with
read access.
Other FORTRAN notes can be found at the Intel site.
I am working on Fortran code with MPI and introducing the following MPI command
call MPI_Gather(nlocal,1,MPI_INTEGER,counts,1,MPI_INTEGER,0&
&,comm_cart,ierror)
with in a particular subroutine gives following error:
This name does not have a type, and must have an explicit type. [MPI_INTEGER]
I understand that the compiler does not recognize the MPI part of this code. However, all other related variables such as nlocal, counts and comm_cart are recognized except the Fortran MPI data type MPI_INTEGER. Can someone throw light, where I am doing wrong?
Note: The compiler is Intel compiler
You must tell the compiler about the MPI stuff (mainly variables).
The modern way is introducing
use mpi
in every scope.
In the old days it was also done using
include "mpif.h"
but that has several disadvantages. Namely, because it is compatible with FORTRAN 77, it does not introduce explicit interfaces for any MPI subroutines and therefore the error checking is less thorough than with use mpi. The modern method will help you more in keeping your code correct.
On the other hand, if you use use mpi the module mpi must be compiled with the same compiler (sometimes even with the same version) which you use to compile your program.
Why is it required to put a name after the PROGRAM keyword when programming in Fortran? Does it make a difference? Did it have some use in the past? I can't think of any effect it has on the rest of the code other than that the name is now reserved for the main program and can't be used for any other variable or procedure.
It works the same as pascal, to provide a module name for some operating systems and environments which need an explicit job name. Examples include KRONOS, OS/360, RSX-11, and GCOS. Three of those run on iron dinosaurs. RSX-11 may have been partially designed to appeal to iron dinosaur programmers, but I notice that stuff was dropped by VAX/VMS.
Otherwise, the program name is all but useless. Maybe there are some compilation error messages which use it.
It may be useful to have a program name to easily distinguish different programs, if for nothing else. But note that PROGRAM statement is not necessary in a Fortran program at all. The only mandatory statement, which also makes the shortest Fortran program possible (although not particularly useful), is:
END
I am quite new to fortran, and only write in fortran 95 and 2003. Now I have a program that is mainly written in 95, but it is completely in fortran 77 syntax and also contains some 77 functins.
Now I need the functionality in another program, but don't want to rewrite the whole program. My idea was to replace
program my_prog
with
module my_mod
subroutine my_prog()
The replacement does not seem to work. The compiler states, that the syntax from
subroutine my_prog()
is wrong. Does anyone have some experiance with the topic, or knows if it is even possible to implement the code without rewriting it?
The correct syntax for a module subroutine sub is
module name_of_the_module
use whatever
implicit none
!some variables and interfaces
contains
subroutine sub
!here is the code of your subroutine
end subroutine sub
end module name_of_the_module
Otherwise, it should be noted, that you can call the code in FORTRAN 77 from a newer code. It is (with some exceptions) still a valid Fortran 2008 code, just in an old style. The only exception is you cannot mix free and fixed source format in one source file. That may also be your problem.
The best thing to do is to make the old functions and subroutines to conform also to the free source format (see "intersection format" here) and place them into a module as I showed above.
Merely packaging a subroutine into a module may work in some cases but it may not work in others.
There are some features of Fortran 77 that have been declared obsolete now. You have several options.
Compiler switches: Many compilers provide compile time switches to compile legacy code. This depends on compiler to compiler and may change in the future
Use tools: There are tools that people have written that allow you to convert f77 code into f90/95. For this see:
http://www.atmos.illinois.edu/courses/atms391-sp11/Fortran-converters.html
Update source manually: Some people have used floating point variables in do-loops. This may be hard using automatic tools discussed above. In such cases where legacy statements like (goto) are present you may have to work manually. For this see the following link:
http://www.cisl.ucar.edu/zine/96/fall/articles/3.f90.conversion.html
http://iprc.soest.hawaii.edu/users/furue/improve-fortran.html
In the long run it will pay that you go through the code manually line-by-line and make the changes yourself. This is the most portable solution.