Workload
There will be regular assignments and exercises. Post orals students are not required to do all assignments completely. If you want to be exempted from an assignment, please see me when the assignment is given. I emphasize coding and numerical experiments, mostly in C++ and python. One of my goals for the class is to develop you as a programmer and expert in scientific computing.
Collaboration, code sharing, web resources
As an advanced class, the rules on code sharing and collaboration are looser that they would be in lower level classes. Students are allowed to collaborate on assignments, to work in groups, and to share code. Collaborating groups of 2 to 4 students are allowed to submit a single copy of an assignment. Code sharing is allowed between indviduals or groups that are not collaborating. Whenever you hand in an assignment, you must make clear what code you shared and with whom. You are allowed to use web resources, but you are not allowed to download code from the web to hand in, with the exception of graphics. I expect collaborating groups to accomplish more than individuals on the assignments. This may mean exploring related issues not explicitly required by the assignment. You may be able to find answers to non-computational exercises on the web. You are not permitted to download them. I reserve the right to ask any student to explain their work or the work of their collaborating group. A student who is unable to do this may lose points on the assignment.
Coding standards
Every good scientific programmer adheres to a set of professional coding standards. These standards are hotly debated, particularly after hours, and vary from person to person. Part of becomming a good scientific computing person is training yourself to follow a set of principles. Here are some suggestions.
- Everything should be scripted rather than done by hand. This includes post-processing and plotting. If you find a bug in your code and want to make new plots, you do not want to spend time creating plots manually that are almost the same as the ones you are replacing.
- Plots should be drawn with careful sizing, labeled axes, legends, and titles with information about the run. The plot should explain itself so you don't have to remember. It is easy to adjust and add features to plots if they are scripted. If you want to compare two curves, put them in the same plot. A .pdf file generally has better resolution than a .png or .jpeg, and is clearer when printed.
- Code should be easy to read. This means: lots of informative comments (e.g., not ... x = y // set x equal to y). You should have a use naming conventions (caps or underscores to separate words, as in max_val or MaxVal or maxVal, not just maxval), consistent indention and curley brace rules (always two spaces, always 3 spaces, curley on the same line, curley on the next line, whatever), white space for allignment as you see fit, white space (blank lines) between blocks of code. Whatever your conventions are, stick to them.
- A code must be structured so that it can be verified and validated. This means putting functionality in procedures that can be validated separately. Write procedures that are general enough to be able to solve test problems for validation as well as the real problem you are interested in. Develop a validation strategy before you start coding. Create testing routines you can "make" to test individual procedures.
- Get to know software development and productivity tools. Learn the UNIX make system. Use a debugger to step through codes (this is less useful in Monte Carlo than in other parts of scientific computing).
Using posted code
Some computing assignments come with posted code. The code is a combination of C++, python, and a makefile. You are required to read the comments at the top of the code before using it. The code is in the form of a "tarball", which is a collection of files collected using the UNIX "tar" command.
Assignments and code
| Assignment | Code, sample output, instructions | Due date |
|---|---|---|
|
Assignment1.pdf |
Week1.tar Week1.pdf Unpack: in a new directory, type: tar -xvf Week1.tar Build and test: type: make fTest Check: compare the figure to Week1.pdf |
February 19 |
|
Assignment2.pdf |
no programming this week | February 26 |
|
Assignment3.pdf |
Week2.tar Week2Output Unpack: in a new directory, type: tar -xvf Week2.tar Build and test: type: make fTest Check: compare the figure to Week2Output |
March 26 |