Physics 580  Computational Physics                                                                  Fall 2017

 

GRADES

 

The grading scale is as follows:  A = 3.8-4.0   A- = 3.5-3.7   B+ = 3.2-3.4   B = 2.9-3.1    B- = 2.6-2.8   C+ = 2.3-2.5   C  = 2.0-2.2  C- = 1.7-1.9  D+ = 1.4-1.6  D = 1.1-1.3   D- = 0.8-1.0  F < 0.7

 

Your grade in the course will be based upon 6 individual and 2 group 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 @ mail . 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.

 

Feedback: For the first three projects, I will send you, as needed, detailed feedback on your program so that you may improve it (and your grade).  NOTE: This is not a license to submit an incomplete project. If you submit a project without graphs, you will not get credit for submitting a 'final' graph. If your code is not working, your final project will reflect that fact. The purpose of feedback is to give you guidance on how the code should interact with the user and to improve your plots, not give you more time to submit them


Second chance:  For the final 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 for individual projects 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, with 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. I have caught, and reported for cheating, students who have directly copied in this manner.

 

On the other hand, it can be useful to work with a "coding buddy." (Note: you must each turn in independent work.) Exchange codes. Have the other person compile and run your code. This will help ensure the user interface is understandable. Also, someone else will have different assumptions than you and will often quickly note a problem. It is acceptable, even encouraged, for you and your buddy to compare output to make sure they give acceptable the same results. And 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.  I strongly recommend this strategy, particularly if you are a novice programmer.

 

For group projects: the same standards apply. In addition you will jointly provide a brief written and oral presentations, including data and graphs on performance. The written presentation must document the contributions of each member of the group.  If you feel someone is not contribution, please contact me directly.