Physics 580 Computational Physics Fall 2010

GRADES

The grading scale is as follows: : A = 3.8-4.0   A- = 3.4-3.7   B+ = 3.1-3.3   B = 2.8-3.0    B- = 2.4-2.7   C+ = 2.1-2.3   C  = 1.8-2.0  C- = 1.7  D+ = 1.1-1.3  D = 0.8-1.0   D- = 0.4-0.7  F = < 0.4

Your grade in the course will be based upon 6-8 projects. There is no other homework or exams. Each project will graded based upon the following criteria:

Function: does program run and produce correct output?

Usability: is program easy to use? Are input requirements and output format easy to understand?

Readability: is program easy to read and understand? Is it well-commented? Is it broken up into manageable subroutines? Is each subroutine well-documented?

Efficiency: Does program run efficiently? Is the coding clunky or unnecessarily complicated?

Each project must compile with a “standard” compiler (e.g. gfortran or GNU f77 or g77 or Intel ifort compiler). If it does not, your project will be marked down by 50-100%, depending on how much I have to do to make it work. If I cannot make it work with a reasonable amount of effort, you will get zero credit. This is especially true for students who submit programs in C; they must compile easily under the GNU C compiler.

Each completed project must be e-mailed to me (cjohnson@sciences.sdsu.edu) as a tarred, gzipped file (I’ll explain how to do this in class), with:

the original code; sample input (including input files if needed); sample output. In some cases I will ask for some brief analysis, which can be only a few paragraphs.

Some projects will have an "advanced" part. The basic part will be worth 75%, i.e., a B, while the advanced part will add 25%.

Late projects: Late projects will be docked 25% for each day late, starting immediately after the due date and time. Submit your projects early; cries of failed computer disks and down internet connections will fall on deaf ears.

From time to time I may choose outstanding examples and “publish” it on the class web page as an exemplar of good coding, particularly in readability.

Second chance:  For the first few projects I will institute a 'second chance' option. If you turn in a project 3 days early, I will see if there are any problems with the project and give you feed back and allow you to resubmit the project within 3 additional days.

WORKING TOGETHER AND PLAGIARISM

All the work you submit must be your own. On occasion I will provide you with external code (say a diagonlization routine) and that you may use without forfeiting points.

You are not to copy lines of code from each other. It is usually very obvious when someone has cut and pasted code. Every programmer has a unique style, and always different choices of naming variables. If I suspect students are pasting lines of code from each other, I will take severe steps to eliminate this practice.

On the other hand, it can be useful to work with a "coding buddy." (Note: you must each turn in independent work.) If you get stuck, you may look at someone else’s code to see how he or she solved the problem. During the semester we’ll talk about debugging strategies. Looking at code is actually seldom less useful than printing out intermediate results. If you “borrow” a friend’s code, use it to print out intermediate steps and to compare to yours. That will help you to find your bug without having to copy directly.

Also, I strongly recommend having a friend from class compile and run your code; this will have ensure the user interface is understandable. Also, someone else will have different assumptions than you and will often quickly note a problem.