1. Due Date

Project Report: May 8 before 11:59pm (EST)

Project Presentation: May 13: 10:30am - 12:30pm or 2pm - 5pm, talks slides upload to presentation google doc by 9 am.

Project Code: May 14 (for Type 1 projects)

Project Demo: optional (for Type 1 projects)

2. Overview: Report and Presentation

The final part of your course project consists of an oral presentation and written report.

The written report and oral presentation are the main parts on which your final project grade will be determined.

You will deliver a 30 minute presentation on your final project during one of the two final exam slots for our class. And you will write a 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 Section 3 and Section 4 for details and requirements for these two parts.

Groups that do a Type 1 project, will also submit all your project code and I encourage you to 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. Therefore, 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.

Finally, I invite project Type 1 groups to give me a demo of their projects.

3. Project Presentation

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

Your scheduled time is available in Section 5.2.

Add a .pdf of your talk slides to the presentation google doc prior to 9 am on May 13. 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 or not.

3.1. Organization

A Type 1 Project 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?).

A Type 2 Project talk should include the following:

  • Introduction to your project, including motivation, problem statement, and a clear statement of the breadth and depth of your investigation and the parallel and distributed focus.

  • Description of the breadth main problem/algorithm/system you investigated. Include any definitions and algorithms necessary to understand the depth. Include a list of main foci for evaluating the depth part of your work (i.e. what were the main directions and why)

  • Description of the depth parts of your work.

  • Clear presentation of evaluation of the work your investigated.

  • Conclusions, (future or other directions for this work, if applicable).

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.

4. Detailed Requirements for Project Written Report

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

Type 1 project reports should be 8-12 pages long

Type 2 project reports should be 10-15 pages long.

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).

4.1. Latex and remote access to pdf

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 veiw:

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

or you can email it to yourself 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

4.2. Type 1 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.

4.3. Type 2 Paper Organization

  1. Introduction The introduction is the big picture of the topic you are covering, and the blueprint of what your report includes: the what, the why/motivation, the important issues/problems, and the how/solutions. It includes a definition of the topic you are investigating, a high-level description of the big ideas of the topic, the big motivations for the area, and main problems. It should also include a high-level description of the depth areas of your report, and the what, why of them. In addition, the introduction motivates the topic you are investigating (what will a reader learn your report), and describes the main conclusions of your study. Finally, it should be clear what the parallel and distributed main focus is of your report in your introduction.

    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 investigated .. Motivation .. Areas of depth foci .. Conclusions

  2. Related Work This is an essential part of a research paper. Discuss related work in general, and also related work specific to your foci areas. Think about a thematic presentation of this 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.

    This will be a larger part of your paper than a typical research paper.

  3. Breadth and name this something more meaningful to your specific topic

    • Details of the general problem area

    • Overview of solutions, systems, approaches, themes important

    • If you are presenting an algorithm (is pseudo code), a subsection on the sequential algorithm may be good here (or in the introduction).

    • Introduction to Details of your areas of depth and why

    • Introduction to common themes for evaluation depth foci if applicable

  4. Depth and name this something more meaningful to your specific topic

    One or more sections on the depth areas. There should be obvious depth of coverage here.

  5. Your Evaluation and name this something more meaningful to your specific topic

    In this part, provide an evaluation of your depth areas. If you have a common theme for evaluation, this is the place to put it. If, however, each depth area is evaluated independently, then your evaluation of each approach/system/etc. can be presented at the end of each Depth section above (make it a subsection or obvious in some way).

  6. Conclusions & Future Directions/Investigation of this Topic Conclude with the main ideas and results of your investigation. Discuss ways in which your project could be further investigated or evaluated…​what’s next? what are the interesting problems and questions that you did not get to?

  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 report 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.

4.4. Writing 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

4.5. Report Introduction Draft Feedback

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

5. Submission Details

5.1. Project Report

Due before noon on May 8

  • 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

5.2. Project Presentation Schedule

Due May 13

Before 9 am on May 13: uploaded a .pdf version of your talk slides on our system and add a link to them to goolge doc. You may additionally upload .pptx or links to google doc presentation too. See Section 5.3 for more details.

You are required to attend all presentations. You will give feedback on each group’s presentation. Your feedback is part of your 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 Spring 2020 Project Presentation Schedule
May 13: 10:30am - 12:30pm May 13: 2pm - 5pm

.

.

2:00

Jonathan, Danielle

"Green Data Centers"

10:30

Zach, Gus, Brendan

"Parallelizing the N-Body Problem"

2:40

Sam, Keon, Ford

"Reduct: Deduplicated Distributed File System"

11:10

Lamia, Christina

"Analysis of Grid Computing Systems"

3:20

Richard, Mickey, Kevin

"Widening the Sieve"

11:50

Kyra, Kat

"Bitcoin and Blockchain"

4:00

Minh, Haochen, Ayaka

"Parallel Approaches to the Travelling Salesman Problem"

5.3. Where and How to 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 goolge doc. Make sure you upload a pdf version before 9 am on May 13.

  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.

5.4. Project Code

Due: May 14 before 11:59pm

For Type 1 projects.

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.

The source subdirectory of your Project repo should include:

  • Everything I need to build and run your project

  • 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.

5.5. Project Demo

For Type 1 project groups, I encourage you to demo your project to me. It is not required that you do so, but it is your chance to show off all your hard work to me and talk through anything you’d like to show me about your code or experiments.

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 to make sure that it demonstrates what you want to show me.

Email me if you would like to set up a 30 minute time to demo your project to me.