Final Project 4: final submission

Deadline

December 13, 2026

Page last modified

October 17, 2026



Minor changes to this document may still be made. We’re sharing it now to give you an idea of what to expect.


Overview

The final submission of your Final Project is due on Sunday, December 13th, and is worth 15 points.

Directions and grading

Submission expectations

  • Deadline: Sunday Dec 13th at 11:59 pm.
  • Submission: Submit your assignment by tagging @kstarr791 and @jelmerp in a new Issue in your GitHub repo.
TipQuestions and advice

Don’t hesitate to contact the instructors with questions about, for example:

  • Specific expectations for the Final Project that are unclear to you
  • Whether you are on the right track with adjustments we suggested after your progress report or presentation
  • Advice on how to code or organize aspects of your project

We’re happy to answer questions by email or during office hours.

WarningLate submissions

Late submission may be accommodated depending on circumstances, but to request it, you must contact both instructors by Wednesday, December 9th. For late submissions without advance notice, 3 points will be subtracted for each day the submission is late.

Academic integrity

Use of generative AI Tools is permitted.
Open-book research for the assignment is permitted.
Getting help on the assignment is not permitted, except from the instructors.
Collaborating, or completing the assignment with others, is not permitted.
Copying or reusing previous work is not permitted, except as described on the general info page.
APA Citations and/or formatting for this assignment are not required.

Rubric

Category Points Earn all points if your project (examples given)…
Project organization 2
  • Has a clear and appropriate directory structure
  • Has informative and appropriate directory and file names
  • Does not mix data, scripts, and results in individual directories
Project background and documentation 2
  • Has a clear description of its background and goals
  • Has a clear description of how different scripts are used to achieve these goals
  • Where appropriate, indicates what is still a work in progress (and optionally, future directions)
  • Properly uses Markdown files for documentation, including a top-level README.md that renders well on your GitHub repo’s front page
Project reproducibility 3
  • Has a protocol that includes all steps in the workflow, which anybody with access to your repository, the raw data files, and OSC should be able to rerun
  • Has information for the instructors (or any other reader of the project!) about where at OSC (within PAS3493) to find the raw data files, and other details needed to rerun the analyses
  • With the above pieces of information, allows the instructors to successfully rerun all scripts in your project
  • Uses containers (preferred) and/or OSC modules to run external software (Conda environments are also fine). R packages can simply be installed as we did in class.
Code quality 4
  • Has code that demonstrates an understanding of topics covered in the course
  • Uses tools and commands that are (by and large) appropriate to accomplish its goals
  • Includes both shell scripts and R scripts or Quarto documents
  • Uses extensive comments within scripts to document what is being done and why
  • Uses no absolute paths in scripts (your protocol may contain some, for example to point to the raw data)
  • Uses scripts that accept arguments where appropriate and minimize “hard-coding” of potentially variable things like input/output dirs, file names, and some software settings. Any hard-coded variables/constants that are present are clearly set at the top of scripts.
  • Has individual scripts that are not overly long and don’t do multiple unrelated things
  • Has no or only clearly annotated lines that are “commented out” in scripts
  • Uses shell scripts with proper set settings, and similar good practices as taught in the course
Slurm batch jobs 2
  • Has one or more scripts that are run as Slurm batch jobs at OSC
  • Uses appropriate sbatch options
  • Appropriately manages Slurm log files
Version control 2
  • Has Git commit messages that are informative
  • Has (at least reasonably) appropriate commits, e.g. individual Git commits don’t contain multiple completely unrelated edits
  • Has a single .gitignore file to make Git ignore files like large raw data files, and in most cases, results files

Detailed steps

The rubric above lists what we will look for. Before you submit, we recommend that you take the following steps:

  1. Test whether your project can be rerun, since we will try to do so when grading. Clone your GitHub repository into a new directory at OSC (e.g., /fs/ess/PAS3493/people/$USER/FP_test), and follow your own protocol from the top, including rendering your Quarto document(s). This is a quick way to find files you forgot to commit, absolute paths, and steps missing from your protocol. You don’t need to wait for long-running steps to finish: once a step has started successfully, you can cancel it with scancel. Afterwards, remove the test directory.

  2. Go through the rubric item by item, and check your project against it.

  3. Describe your genAI use in a short section of your README (or in your submission notes, see below): which genAI tools you used, and for what (for example, “Claude Code wrote a first draft of scripts/trim.sh, which I then edited”, or “I didn’t use genAI”). A few sentences are enough.

  4. Optionally, add submission notes for the instructors, either in a separate file (e.g., doc/submission-notes.md) or in a section of your README. For example, you may want to:

    • Give additional instructions for rerunning your project
    • Point out files in the repository that we should ignore
    • Indicate which files or parts of files were pre-existing (see the general info page)
  5. Push your final version to GitHub, and submit by tagging @kstarr791 and @jelmerp in a new Issue in your repo.

Good luck!!

Back to top