The -O3 option maximizes your exposure to compiler bugs. Choosing the -O options sometimes lets the compiler avoid trouble in regions where a forced maximum optimization might be a bad idea.
If I change a value of a variable defined in a MODULE in one Subroutine, is it changed when I use it in another.
Yes. Look at and execute module.f .
Do the declarations of REAL and INTEGER have to come after the COMMON statement?
How do you use a BLOCKDATA (where you put it, etc)?
Use it like a subroutine, but instead of starting with a "SUBROUTINE" statement, start with a "BLOCKDATA" statement. End it with an "END", but don't bother with the "RETURN". You can put it anywhere in the program after the "END" of another subprogram. Take a look at the use of BLOCKDATA in fall.f.
Why would you use BLOCKDATA?
When doing scientific and engineering calculations, there are lots of constants that you may need. The values of Pi, g, Plank's constant are simple ones. Often there are hundreds to thousands of constants that feed into Equations of State and calculations of physical properties like fluid viscosities, conductivities, and so on. These really are constants. Numbers that are needed for calculations, but that you do not want to calculate yourself. Generally, once imbedded in a code you won't change them for many years (or the rest of your life). To save computer time you want to preload the values of the constants with a DATA statement.
You will need many of these constants in several subroutines, so you may choose to transmit them with a COMMON. At this point Fortran backs you into a corner and forces you to create a BLOCKDATA subroutine for DATA statements defining values for any variables in COMMON blocks. For example, if I am going to give access to the values for Pi and g in:
and I want to define the values with a DATA statement, then I have to include:
What is a MODULE?
A module is a place where you reserve memory for variables with specific names. When the compiler processes the module statement it sets aside memory for the variables listed within the module. When you include a USE statement for a given module in a subprogram, the compiler looks at the list of variable names defined in the MODULE, and any time it sees a variable with one of these names in the subprogram (or main program if appropriate), it uses the memory location reserved by the MODULE rather than associating a new one for the variable. This lets several (or many) subprograms agree that a variable name really refers to the same memory location, and all pick up changes made by any one subprogram without information going through the argument lists.
When using COMMON blocks or MODULES where is the best place to put them?
I like to locate MODULES before the "PROGRAM" card of the main program (see module.f ). However, you can place the MODULE program unit after the END statement of the main program or any subprogram. Note that there is no flexibility in the position of the USE statement. USE statements must immediately follow the PROGRAM, SUBROUTINE, or FUNCTION statements. COMMON blocks are always contained within the program units where they are needed, grouped near the top with other non-executable statements.
How do you use outside files that contain code in a program, and how is it brought in?
We have covered two ways. The first is appropriate when the outside files contain full subprograms. Then the file names must end with ".f", and you just list them on the compile line:
f77 main.f sub1.f sub2.f func.f
The compiler simply reads each file in turn and adds its contribution to the final executable file.
When the file just contains a segment of code, like a COMMON statement, you need to use an INCLUDE statement in your program, to tell the compiler to bring the contents of a file in for processing. What happens is that the compiler processes your statements in the original file until it hits and INCLUDE, then opens the listed file and processes everything in it. Once done with the INCLUDED file the compiler returns to processing the next line in your original file. If the file "more-code" contains the lines:
Will give it a try. Most of the review sheet is just a combination of the first two reviews.
Usually, but not always. If the function to be integrated has some rapid changes and you don't use enough sampling points, then the quadratic fit in Simpson's method may give some strange results.