Basic/fundamental questions in Fortran

I've just started programming in Fortran 90 and have some fundamental questions;

1. I want to comment several lines (i.e. block comment) in my program.I have been commenting single lines using !. Is there a possibility of doing a block comment? That is comenting several successive lines instead of inserting an ! in every line?

2. This is a simple one again;

I have got

code subroutine A

end subroutine A

PROGRAM MYPROGRAM

REAL*8 X

PRINT*, 'X'

READ*, X

call subroutine A

end POGRAM MYPROGRAM end code

Now, I do not want to pass X to my subroutine A.I presume X is a global variable , so it should be visible to my subroutine A even if it is not passed as an argument. Right?

3. I want to learn about debugging in Fortran 90.Any references in the web (simple and good) will be really appreciated.

1. Not that I know or use - just keep using !

2. Two ways, the old fashioned common block or a new fangled module. The common block way is:

   subroutine A real*8 x,y common/stuff_for subA/x,y !square it and return the answer in y y = x**2 end subroutine A

   PROGRAM MYPROGRAM

   real8 x,y common/stuff_for subA/x,y ! read a value for X PRINT, 'X' READ*, X ! do something with it call subroutine A PRINT *, x,y end PROGRAM MYPROGRAM end code

Common blocks do not have to have the same variable names or types in the program modules that they are used in. It is possible to do things like:

!program module 1
integer*4 i,j
common/block1/i,j
.
.
!program module 2
real*8 x
common/block1/x
.
.

It is the alignment that matters, hence to keep them all consistent, create an include file called say inc1.ins and use the following statement in each program module in which it is required

include 'inc1.ins'

3. Don't know - try Metcalf's book Regards Ian

Sometimes you don't need comments.

I come from the past, where comment lines began with the letter C in the first column. I can't remember when (or if it ever) became valid to have completely blank lines in code. However, blank lines, or lines beginning with C, or with !, are very useful. Divide your code up into logical blocks. Sometimes just white space around a block of code is enough to make it more readable even with no comments.

Use sensible names for variables. If you like to program in Mixed Case, then this helps. The underscore character helps too. For example:

NoOfElements or No_of_elements are far more meaningfull than NELES - although even that is better than NE ... now we can have long names the code becomes far more readable. However, beware. Sometimes very long names just irritate you when you have to type them. Also avoid stupid unhelpful comments, such as:

NELES=0 ! set NELES to zero.

When I leartn Fortran first, it was programmed in capital letters. When we punched cards, and often had a limit on the number of cards we could have in a job, then comments were very few. The number of cards stopped being an issue about the time lower case letters were allowed. I still program code in capitals, and comments in lower case. If you have your own system, you will find it makes the comments stand out.

FTN95 has an excellent debugger. The instructions on how to use it are in FTN95.CHM, and the manuals available in the Documentation section of this website - some of it going back to when the compiler was FTN77 not 95. There is no substitute for having a go, and seeing where you come up with a problem. No doubt someone will help through this forum if you have a specific problem - general queries are much more difficult to answer.

Eddie

As regards question 1, that is a question about programming environment not the FORTRAN 90 programming language. (Unless you meant 'Is there a way within the language to indicate that all the lines between <here> and <here> are to be parsed as consecutive comment lines - in which case, the answer is no).

Presumably since you are here, you are using Salford software, so if you are also using the Plato IDE for your programming, there is a menu item (fairly unintuitively hidden) ... select a bunch of lines then choose Edit-Advanced-Comment Selection to comment all of them. Not much quicker than adding ! to each line manually unless its a big bunch, though 😃

Andy

Now, I do not want to pass X to my subroutine A.I presume X is a global variable , so it should be visible to my subroutine A even if it is not passed as an argument. Right?

Wrong; All variables in Fortran are by default only local. This is an important difference from some other languages. To make variables available globally, COMMON or MODULE structures are used, with MODULE the preferred approach. Ian's answer identifies ways to use COMMON that are available but not preferred. To transfer variables to SUBROUTINE or FUNCTION, you can also use an argument list. There are other ways, but again they are not preferred. Eddie’s answer has also indicated a style of coding. A regular style or layout of the code also assists in writing code which is readable and also helps minimise errors or bugs. As it may imply a programming style is individual and varies between programmers, but a consistent style helps speed up programme development.

Some of my preferred rules are:

• Variable names that identify what they are used for
• Use DO loops where possible, to give a structure.
• Indent DO loops and IF – END IF structures
• Declare all variables and use IMPLICIT NONE to help with spelling errors in variable names

Use a Subroutine or Function to define a basic operation of the calculation. I try to limit a subroutine to about 1 page. This was 60 lines when we had printers, but is now about 40 lines for 1 screen. I find when it is longer, if I split it into smaller subroutines, then the management of the calculation via the subroutine calls assists in documenting the calculation approach. I also find I can refine the calculation performed in each subroutine, making the program more robust or flexible.

Others are bound to disagree with my list, but a consistent approach helps, especially when you come back to the code 6 months later to change the approach slightly or now that you have a different data input.

Good luck,

John

John's comments regarding common / module are correct. As an oldie, I understand the common block approach better and you can do such sneaky things - it is a bit more raw, but modules are perhaps the way forward, keeping common blocks in reserve for the lower level fiddles which may prove necessary.

Keeping subroutines and functions short it also good, but I must admit that I have a few!!! which do not comply with John's excellent recommendations. Short routines are helped by use of the 'include' or 'use' statements.

Ian