Course Projects

Purpose: The central aim of this course is to give you experience in 1) doing research, implementation, and experimentation, in parallel computing, and 2) writing conference style papers.

Description: In groups of 1 or 2  students will complete a major course project on an approved topic. These projects can focus on parallel algorithms, systems, or applications or a mix of these issues. The larger the group the higher the expectations!   Each project consists of 3 deliverables:

1. Project Proposal: A project proposal in the form of an email sent to me. The email should list the following:
   • Project title
   • List of Students
   • A paragraph describing the problem to be addressed
   • A bibliography of 3-5 important related papers.
2. Project presentation: A short style presentation of your work lasting 15 minutes with 5 additional minutes for questions.
3. Final paper: A final paper describing your research in the form of a 10-15 page "conference style" paper. The paper may also contain a set of appendices of arbitrary length that will be read at the instructors discretion. In these appendices you may include code, test data, and any other supporting material.

Evaluation: This is a research project, not an assignment!  Not all projects will succeed in the sense that they produce positive results (e.g. Wow this technique works really well!) some will produce negative results (e.g. Bummer, the technique is not very good because...). That is OK, in fact it is the very nature of research.  Research is about taking risks and having fun tackling a problem where the solution is unknown.  Note that, a project that produces only negative results can get an A+, while a project that produces positive results can get a C+. It is not the result that matters so much, but rather the process and the resulting paper!  In marking these projects I will be asking the following types of questions:

1. Is the topic interesting scientifically?
2. Is it well motivated? Is it clear why we should care?
3. Is the expected contribution well described?
4. Is the problem addressed well described? 
5. Has the project team surveyed, summarized, synthesized,  and understood the relevant literature?
6. Is the project team's approach to solving the problem sound, interesting, creative, and well focused?
7. Was the "experiment" well executed or the algorithm well designed?
8. Did the group ask the right questions about the results? How complete and interesting is the analysis? How good are the conclusions?
9. How well did the group describe their work?
10. How professional is the final paper?

Note that no where in this list of question was the actual result mentioned!

Your final mark on the project will be based on your final paper, your presentation, and your review of approximately three other papers.

A Note On Group Projects: In any group projects there is the challenge of how to evaluate each group members contribution. In general, I assume that each member contributed in an approximately equal manner. If this is NOT the case and you feel that the workload distribution in your group was VERY unfair you may submit to me an email detailing you view of exactly who contributed what to your project. I will then attempt to interpret the situation, talk to the parties involved and make a judgment. In my experience this is rarely a problem but if it is one it should be addressed.

A List of Typical Feedback: Below is a list of comments I find myself writing on papers time and time again.  Before submitting your work please read this list and if the comment applies to your work try and fix it!

The Introduction

• Be more precise
• Don't make such statements without backing it up with references to the literature
• Too fast. This is the introduction - expand this description
• Explain why you are doing this. What do you hope to find out? How will you know if you have succeeded?
• Why should this problem be parallelized?
• What is the expected contribution of this research?
• What are your aims?
• What will you evaluate?
• What is your target architecture?
• At the end of the intro it is important to describe to the reader the structure of the rest of the paper.

The Literature Survey

• A literature review is a synthesis of related work not just a list!
• Group related work together!
• What is the contribution of paper [ref]?

The Main Body

• Use a proper algorithm style
• Carefully describe the computational model you are using.
• How is this work different from the work in [ref]?
• What is new in this algorithm?
• Be careful to describe both the input and output of each algorithm
• Be careful to spell out clearly any assumption/restriction that you assume. Motivate why these assumptions/restrictions are reasonable.
• Define all terms and variables before you use them.
• You need to develop a consistent notation
• Is your algorithm correct?
• What is the complexity of your algorithm?

The Benchmarking

• The experimental setup must be described in enough detail that someone else could replicate your experiments.
• You must always explain such super linear results!
• Explain why the curve has that shape!
• Is this Speedup or Relative Speedup?
• Label the axis carefully! What units is time in?
• How was time measured?
• Always put time on the y-axis.
• A graph that can't be read is worth nothing!
• How does the nature of the input data effect your program?
• What are reasonable test sets?
• What is the question that this test is trying to answer?

Writing Style

• Think carefully about the flow and structure of your paper!
• Don't use colloquial English. Be more formal in your writing.
• When you write "In Figure xx" or "Section yy", Figure and Section (and all other proper names) must be capitalized.
• Use a spell checker!
• Be careful not to plagiarize even a single sentence.
• Please proof read your documents carefully before handing them in.
• Before each algorithm it is important to first informally sketch the main idea.

Latex

• ``This is how to do double quotes in LaTex''
• Why is all this blank space here?
• When you write "Let $N$ be the number of items..." always put such variables in $ $.