PHY210: Fortran for the Physical Sciences
Project Guidelines

Gustavus Adolphus College
January Term 2002

Each student is required to complete a Fortran programming project of his or her own design. Although the project counts as 25% of the final course grade, there is a parallel requirement that all students submit a project satisfying minimum reporting requirements in order to receive a passing grade in the course. This sheet provides some suggestions for choosing an appropriate project and summarizes the requirements for reporting, documentation, language content, and testing.

I. Due Dates

A written Project Proposal is due on Thursday, January 17, 2002. This proposal should include brief (roughly 2-3 paragraphs) summary of the problem to be studied, the methods (such as numerical techniques) needed to solve the problem, and the desired outcome (such as tables or graphs of results).

The completed project reports are due no later than 4:00 PM on Friday, February 1. No programs or pieces thereof will be accepted after that time. It is highly recommended that you schedule a formal meeting with the instructor during both the 3rd and 4th week of the semester to discuss progress on the project.

II. Choosing a Project

Once the essentials of the Fortran language are understood, an almost limitless range of interesting and useful programs can be designed. Naturally, the more quantitative science you know, the greater the number of potential applications that will be accessible to you. The programming exercises in our textbook are fairly realistic, but tend to emphasize the narrower use of the language, at least in the first half of the book. A few general types of problems from the following subjects may start your thinking.

A. Physics

B. Mathematics

C. Chemistry

Students are expected to discuss their plans for project programs with the instructors at a scheduled meeting in the second week of the course and must submit a detailed typewritten project description by the end of the second week. The proposal should have adequate detail to make it clear to the instructors that the project has been given significant consideration (such as references to important sources or algorithms). It is important not to pick either too trivial or too ambitious a topic. Simply finding a formula in a book and running some values through it would represent a minimal sort of project (and one unlikely to impress your instructor). You should be familiar with and interested in the general topic that supplies your project. We have good references in the library that may suggest something to you, but do not be tempted to copy a published program. It is permissible to use a published subroutine to handle, a difficult task within your program, as long as that is not the whole point of your project program, and as long as you attribute it. In this context, we bring the following references to your attention:

Numerical Recipes: The Art of Scientific Computing (FORTRAN Version), 2nd Edition, by W.H. Press, et al., Cambridge University Press (1992).

Numerical Recipes: Example Book (FORTRAN), by W.T. Vetterling et al., Cambridge University Press (1985).

Both of these are available from the instructors. Numerical Recipes is also available online at:


III. Project Report

Each project report must include the following:

  1. User documentation, separate from the source listing. This user's manual must explain the program's purpose, scope, and the computer environment in which it is to be used. It must describe the algorithm(s) that are employed in any calculations or logical decision making. It must precisely describe the required inputs and the tests performed to validate those inputs. It must also specify internal error testing methods. The manual should specify the form and content of the outputs, whether tabular or graphical.
  2. Complete and documented source listing with all modules and subprograms clearly identified. The comments should be sufficiently detailed that a person not familiar with Fortran could follow the general flow of the logic and identify the function of each module or smaller unit. For example, two students might write the following very different comments for the same statements or blocks.
  3.           Student A:
              * Select and use the smallest non-zero divisor from array D
              * Check for negative slope in derivative calculation
              * Read three coefficients of the quadratic equation from keyboard
              * Write error number and discriminant if b**2-4.*a*c is negative
              Student F:  (Note the subtle use of student letters!)
              * Check D and divide
              * Is S neg?
              * Input data
              * Print if error
  4. Normal execution report. This is a complete record of a run or a series of runs with all input and output quantities, graphs and files (if any) in hardcopy form. Again, this report must be sufficiently well presented that a person unfamiliar with the workings of your program could understand it.
  5. Abnormal execution report. To the extent possible you must exercise the input validation and other internal error testing features of the program. Restrict yourself to testing for reasonable blunders and pathological cases. One can go overboard here. It is permissible to make handwritten notes adjacent to this output to explain how the error condition was precipitated. For example, you might write on the printout "Input chosen so values of B**2-4*A*C was negative."
  6. Final program flowchart written on a modular (rather than statement) level.
  7. Concluding statement summarizing any peculiarities, uncorrected bugs and interesting results from your program. Suggest natural extensions or areas for improvement in your work.

IV. Technical Requirements

Although different applications will emphasize different Fortran capabilities, each program is expected to make efficient use of the language. Redundant tests and unnecessary arithmetic conversion should be avoided. All quantities must be properly initialized without relying on the compiler or interpreter to do it. The preferred forms of instructions should be used where there is an option. Avoid statement numbers in program control wherever possible. In particular, each program must include:

Electronic Copy:

Updated: 2-JAN-02 by Thomas Huber, Physics Department, Gustavus Adolphus College.