next up previous
Next: About this document ...

Worksheet 3 - PHY201, Fall 2006
Due Friday Sept. 29th(two weeks), 5pm
Physics 201 home

I am in Europe at the moment and won't return in time for this week's lab(sorry). My grad. student Jiwu Liu will open the Lab. 1-3pm Thursday as usual. He does not know too much fortran however, though he is a first rate c++ programmer and can help with questions about structuring your code. Please try the worksheet anyway. It is due in two weeks so if you need some help with your coding please stop by my office (BPS4260) or email me (duxbury@pa.msu.edu).

As programs get larger it is very important to break them up into pieces which are more manageable and which are reusable. Object oriented programming (OOP) and OOP languages such as python are designed to facilitate this.

Fortran has three subunits which are available for this purpose: functions, subroutines and modules. Modules are the most recent addition to the language, and are intended to replicate the utility of classes in c++. They succeed, to a certain extent. In this worksheet you will use subroutines to break up your code. When you write your first Monte Carlo code (in three weeks) you will start to appreciate the utility of breaking your code into pieces. You must also start putting carefully worded comments into your code. One of the biggest problems with both amateur and professional code is the absence of good comments and good documentation. Another really important principle is that you should try to write code as simply as possible, so no unnecessary clever tricks please. If you need to use a complex data structure you must clarify it by writing plenty of comments so that what you are doing is understandable to someone who wishes to extend your code, for example you!!

Note that the fastest codes are f77 codes with all code in one large main program, which are of course impossible to understand. To preserve efficiency in more modular code it is important to make sure the number of calls to functions and subroutines do not slow your code down too much. Often the speed of a code comes down to the "inner loop" which is the deepest loop in the code. Make sure that this loop does not include calls to functions or subroutines.

Estimating how the computational time and memory requirements grow with the size of the problem is essential to designing good code. For example the size of the problem instance in Problem 2 of this week's worksheet is N, the number of charges. In problem 2, you need to estimate how the computational time and memory requirements of your fortran code grow with N.

PROBLEM 1
Modify the two programs you wrote for worksheet 2 last week so that all of the do loops are in subroutines (read section 9 of the handout).

PROBLEM 2.
Write a fortran program to generate a set of N point charges equally spaced on the perimeter of a unit circle. Assign these charges random values on the interval [0,0.000001] Coulomb. Write a fortran subroutine to find the electric field at the origin of your co-ordinate system. Place all of the numerical calculations in functions or subroutines. Estimate how the computational time and memory requirements of your code grow with N. Do you think that there are better ways to write your code so that the memory or computational time required is reduced?


 

Phil Duxbury
2001-09-10