Due Dates

Project Report: Dec. 15 before noon, push to repo and turn in a hardcopy to Tia.

Project Presentation: Dec. 17, at 2-5pm and 7-10pm, in 104 Sci Center. Talk slides need to be uploaded, and link added to the (presentation google doc) by 1pm.

Project Code: Dec. 18

Project Demo: By during finals week. Sign up for a demo slot on the demo google doc (to access you need to be logged into your swarthmore account).

Overview

The final part of your course project consists of:

  1. An oral project presentation

    You will deliver a 30 minute presentation of your final project during one of the two final exam slots for our class.

  2. A written project report

    You will write a 10-13 page final report that describes your project (using the latex template in your Project repo). It should be similar in style and organization to the research papers that we read this semester. This is your opportunity to describe in detail what problem you were solving, how you solved it, how you tested your solution, what your results show, difficulties you encountered along the way, what you would have liked to have done (or done differently), and what you learned from your project. See Project Presentation and Written Report for details and requirements for these two parts.

  3. A project demo, and submition of your project code.

The written report and oral presentation are the main parts on which your final project grade will be determined. You will also submit all your project code and give me a demo of your project. However, your grade is almost exclusively determined by your written report and oral presentation. This models the real research world where the research paper is the primary, and usually only, mechanism through which your work is evaluated, and where written conference proceedings and conference presentations are the main mechanism through which others learn about your work. As a result, you should spend a significant amount of effort making sure that you have a complete, and well-written final report and presentation; don’t do a fabulous project and then fail to present it well.

Written Report

Due: Dec. 15 before noon

Detailed Requirements

Prepare a final written report that describes your project following the guidelines for your project Types, and following the writing style guidelines in Style Guidelines.

Your report should be 10-13 pages long using the latex template provided to you in your Project repo in FinalReport/. Your report must be at least 10 pages and may not be more than 13 pages long (including references). Optional, additional appendices do not count towards the total length.

You may add additional appendices that exceed this length, but they should not contain main content of your paper; they must be true appendix content such as complete longer examples or extra figures (the main figures and graphs should be in the body of your 10-13 page report).

Latex

You must write your paper in latex using the template for it in the FinalReport subdirectory of your Project repo:

Project/FinalReport:
Makefile  README.md  finalreport.bib  finalreport.tex

The README.md file has information about these files and some links to resources.

You may want to start with your proposal.bib file as your finalreport.bib. You can copy it to your finalreport.bib file like this:

$ cd ~/cs87/Project/FinalReport
$ cp ../ProjectProposal/proposal.bib finalreport.bib

As you work on your report, you should compile and build it periodically to test your .bib entries and that it builds correctly (also periodically commit to your repo at various stages so you can recover any lost or deleted content). Make sure to do a make clean before building to ensure that your latest changes successfully built a .pdf file, and check latex errors for undefined references that

$ make clean
$ make

You can scp your finalreport.pdf from the cs account your home machine to view:

# from your home machine:
$ scp you@cs.swarthmore.edu:./cs87/Project/FinalReport/finalreport.pdf .

or you can email it to yourself using gmail or by running mail on our system, specifying finalreport.pdf as an attachment. For example (and just pick the email address you want to send it to…​I’m showing to your swatmail):

# from a cs machine:
$ echo "hi" | mail -s "report" you@swarthmore.edu -A finalreport.pdf

Paper Organization

You should have the following main sections in your paper (and you are welcome to add additional sections, and subsections as you need them):

  1. Abstract The abstract is a brief summary of your work. It should be written to make the reader want to read the rest of your paper. Briefly state the basic contents and conclusions of your paper: the problem you are solving, why the reader should care about this problem, your unique solution and/or implementation, and the main results and and contributions of your work.

  2. Introduction The introduction is the big picture of your work: what, why, and how. It includes a definition of the problem you are solving, a high-level description of your solution including any novel techniques and results you provide, and a summary of the main results of your paper. In addition, motivates the problem you are solving (why should a reader find your work important), and describes your contribution to the area (this may not be applicable to your project).

    The first paragraph of the introduction should contain all of this information in a very high-level. Subsequent paragraphs should discuss in more detail the problem you are solving, your solution, and your results and conclusions. .. Statement of Problem Being Solved .. Motivation .. Problem Solution .. Results and Conclusions

  3. Related Work This is an essential part of a research paper; discussing related work is a good way to put your work in context with other similar work, and to provide a way for you to compare/ contrast your work to other’s work.

    You should use feedback on the annotated bibliography from your project proposal to structure this section; it should be written as a re-write of your annotated bibliography in a single Related Work section.

  4. One or more sections describing your Solution

    • Details of the problem you are solving.

    • Details of your solution and the project’s implementation. Even though you may have spent an enormous amount of time writing code, this should not include a listing of any code you wrote. Only if your project is about developing an algorithm or a new language, may code examples be appropriate here.

    • Discussion of how your solution solves the problem.

  5. Experimental Results demonstrating/proving your solution

    • Explain the tests you performed (and why)

    • Explain how you gathered the data and details of how your experiments were run (any system/environment set up)

    • Present your results. Choose quality over quantity; the reader will not be impressed with pages and pages of graphs and tables, instead s/he wants to be convinced that your results show something interesting and that your experiments support your conclusions.

    • Discuss your results Explain/interpret your results (possibly compare your results to related work). Do not just present data and leave it up to the reader to infer what the data show and why they are interesting.

  6. Conclusions & Future Directions for your work Conclude with the main ideas and results of your work. Discuss ways in which your project could be extended…​what’s next? what are the interesting problems and questions that resulted from your work?

  7. A brief meta-discussion of your project Include two paragraphs in this section:

    1. Discussion of what you found to be the most difficult and least difficult parts of your project.

    2. In what ways did your implementation vary from your proposal and why?

  8. References At the end of your paper is a Reference section. You must cite each paper that you have referenced…​your work is related to some prior work.

Style Guidelines

  • Write in a top-down style. First present the the high-level issues, then expand them. This applies to the overall organization of your paper as well as the organization of sub-sections and individual paragraphs.

  • Conclude each sub-section, section, and entire paper. Each chunk of your paper whether it be a paragraph, a sub-section, a section, or the entire paper should have a conclusion.

    Each section and sub-section of your paper should be organized as: high-level important points first, details second, summarize high-level points last.

    The introductory paragraph to a section should be written as follow:

    • 1st sentence(s): main idea of section or sub-section

    • middle sentences: expansion of the big ideas of this sub-section, or section.

    • concluding sentence(s)

  • Use active 3rd person: We present, we show, we demonstrate…​

  • Define terms, and always define them before using them.

  • Use figures. Use diagrams to help explain system design, and graphs or tables for presenting results. If your project has a GUI component, then your paper should have some screen dumps of your interface (look at the man page for xwd). You should have a figure showing the high-level design of your implementation.

More detailed writing advice and guidelines can be found here: CS Research and Writing Guide

Draft Feedback

I encourage you to get feedback from a WA on a draft or detailed outline of the Introduction section of your report. See this link for more details: WA Feedback on Introduction

Submit

Due before noon on Dec. 15 before noon

  • First, check that your report builds correctly. In your FinalReport subdirectory, do a make clean and then a make to build finalreport.pdf. Check that your .pdf is correct (no missing references or missing figures), and fix .bib entries an other errors before submitting.

    $ make clean
$ make

    You can scp your finalreport.pdf to your home machine to veiw, or you can email it to yourself by running mail on a cs lab machine:

    # scp from your home machine:
home$ scp you@cs.swarthmore.edu:./cs87/Project/FinalReport/finalreport.pdf .

# mail from a cs machine:
#    Enter a line at the command line, then `return` for `cc:`,
#    then `CNTRL-D` to end the mail message:
cs$ mail -s "project report" you@swarthmore.edu -A finalreport.pdf

# or just echo something as the message body:
cs$ echo "hello" | mail -s "project report" you@swarthmore.edu -A finalreport.pdf

  • Then, do a make clean, and add, commit, and push your finalreport.tex and finalreport.bib files, and any other files necessary to build your report .pdf to your repo (like figures and graph files).

    $ make clean
$ make
$ git add finalreport.tex finalreport.bib
$ git commit "final report done"
$ git push

Project Presentation

Due: Dec. 17, at 2-5pm and 7-10pm
(upload talk slides and add link to them to presentation google doc by by 1pm).

You will give a 30 minute presentation of your work in a 40 minute time slot. Plan for 30 minutes of presentation with 5 minutes of questions.

Your scheduled time is available in Presentation Schedule.

Add a .pdf of your talk slides to the presentation google doc prior to by 1pm on Dec. 17. You may additionally add .pptx (using MacOS fonts) and/or a link to a google doc of your slides if you want to present using either of those formats instead of a pdf. However, you should make sure to also upload a .pdf regardless of if you plan to deliver your talk from this format.

Talk Organization

Your talk should include the following:

  • Introduction to your project, including motivation, problem statement, and a clear statement of question your project is addressing and the parallel and distributed focus.

  • Description of the main algorithm/system you implemented/tested. Include figures and examples.

  • Clear description of the parallel or distributed parts/focus of your work, its parallel/distributed goals.

  • Description of experiments run (and why/what hypotheses).

  • Clear presentation of results, and explanation of what they show.

  • Conclusions, Future directions (what is, or would be, next?).

Your talk should also have a logical narrative flow to it, so think about structuring your presentation in a logical way. Striving for a top-down approach will help with this. Using lots of figures and diagrams will help explain your project. Simplify, at least at first. And make it clear where the parallel/distributed focus is in your project. Make sure to define terms you use, and explain algorithms in pseudo code.

See my Oral Presentation Guide for more detailed information on organizing, slide design, presenting, and preparing for an oral presentation. There are also links to other oral presentation advice.

Also, use these CS87 final presentation rubrics to help you structure your talk and determine good slide content.

Presentation Schedule

Due by 1pm on Dec. 17 uploaded a .pdf version of your talk slides on our system and add a link to them to presentation google doc. You may additionally upload .pptx or links to google doc presentation too. See Upload Slides for more details.

You are required to attend the entire session in which your talk is scheduled, and I encourage you to attend both sessions. You will be graded on feedback you provide to other presenters in your session. You are not required to attend both sessions, but if you do, you will receive a bonus 1% towards your final grade. You are welcome to swap sessions with another group. Just let me know the change in presentation schedule if you do.

Table 1. CS87 Fall 2021 Project Presentation Schedule
Dec. 17: 2-5pm, 104 Sci Center Dec. 17: 7-10pm, 104 Sci Center

2:00

Max and Theo

Distributed Fast Multipole Method with GPU Acceleration

7:00

Aron, Emily, Theo

Parallelizing Minmax Tree Algorithm for Game Playing

2:40

Luca and Ian

SwatCoin

7:40

Jesse and Matt

Deletion on Peer-to-Peer Social Networks

3:20

George and Owen

Training a Neural Network in Parallel

8:20

Beluchi, Ghazi, Marshall

Parallel Sorting

4:00

Alice, Katie, Sojin, Tillie

Parallelizing the RNA Secondary Structure Problem

9:00

Tarang and Tai

Factoring Large Prime Numbers in Parallel

Upload Slides

Create a .pdf version of your presentation talk slides and scp them into your public_html subdirectory on the CS system, set permissions so that they are world readable, and add a link to them from the presentation google doc. Make sure you upload a pdf version before by 1pm on Dec. 17.

  1. From your home machine, copy the pdf version of your final presentation slides (e.g. final.pdf) into your public_html subdirectory on the CS system:

     $ scp final.pdf you@cs.swarthmore.edu:./public_html/.

    See the details about setting up your public_html directory on the CS system from the webpage directions from Paper1 assignment.

  2. On the CS machine, set permissions so that this file is world readable:

     $ cd ~/public_html
 $ chmod 644 final.pdf
 $ ls -l
   -rw-r--r-- ...  final.pdf

  3. On the Final Presentation google doc add a link to your talk slides:

    1. Insert → Insert Link

    2. Enter the url to your talk slides and name the link something (I have an example off this page you can follow). The url will be something like this: https://www.cs.swarthmore.edu/~you/final.pdf

      Test out the link from the google doc page after you add it to make sure you download your talk slides .pdf from the link you added to the google doc.

Project Code

Due: Dec. 18 push to your repo before 11:59pm

You should be periodically adding and pushing your project code to your Project repo, but I’m giving an extra day after the presentations for any final code clean-up.

You should push to your Project repo (in the source subdirectory) all your project code, Makefile, run scripts, etc. Make sure to include a file named README.final with the information described below. Specifically, the source/ subdirectory of your Project repo should include:

  1. Everything I need to build and run your project

    • source code

    • run scripts

    • Makefile

    • etc.

    The only exception is do not include large input or output files in your Project repo. Instead, tell me where these are (e.g., in /scrach/username/subdirectoryname/ or on a specific CS machine’s /local/subdirname/).

  2. A README.final file that explains how to build and run your project. Give me example command lines for running. It should take no more than my running make to build, but if that is not true, then also tell me how to build your project. Also, give me any information I need to set up a run environment (again this would be a good thing to include in your Makefile), and any information I need to use any run scripts you have. If your project only runs on XSEDE resources, then give me much more detailed run instructions.

Final Version of your Code

Make sure that the final version of your project code that push includes code that is:

  • well commented

  • attributes the authors (you), and, IMPORTANTLY, if you used some code from other sources in your code, make sure that you cite that source in a comment around that code.

       /* this function is from Jo Schmoe of (list org or paper or url) */

    If you are using full libraries from other sources, those usually have a top-level comment with the author’s name and organization, and often a copyright statement. If not, add a top-level comment like the above to the file saying where it came from.

    This should be done for larger portions of code you used from other sources. This does not apply to code you wrote where you may have looked for some examples of how to use a particular library or structure something similar to what you were doing. For example, looking at some examples of calls to MPI or other library code, looking at examples of cuda and applying to your solution, are fine, and you do not need to cite these examples that helped you figure out how to write your code.

    If you implemented an algorithm based on its description from a paper, you don’t need to cite that in a code comment (however, it is a nice thing to do as a reminder of from where it came). If a paper had a full code solution that you copy and pasted into your code, then you do need to cite that code in a comment.

  • compiles and runs (do a make, a test that it runs, then a make clean before submitting).

Project Demo

Due: during finals week

Sign up for a demo slot on the demo google doc.

During final exam period, your project group will give me a 30 minute demo of your project. You should sign-up for a demo slot on this google doc (link was emailed to the class with some more information about the demo).

It is up to you to decide what you are going to demo. Before we meet, decide what you are going to show me, come up with a simple demo script, and run through it several times to make sure that there are no glitches during the demo. This is your chance to show off all your hard work; you want to convince me that you did something interesting and that you did a substantial amount of work.

Handy Resources