Final Project Launch Worksheet

COMP 536 | Week 1 Planning Guide

This worksheet is a planning guide for the final project. It is here to help you stay on track from the day the project is assigned through the final week of the semester.

It is not a second hidden assignment, a proposal packet, or a new grading rubric. The goal is simpler: make the most important decisions early enough that you do not spend the last week of classes debugging a pipeline you never really scoped.

If you complete this worksheet honestly, you should come away with three things:

1. a clear statement of your scientific problem,
2. a concrete validation plan for the JAX-native Leapfrog simulator,
3. a realistic 3.5-week execution plan.

NoteRecommended use

Use this worksheet during the first few days of the final project. Bring it to office hours, lab, or group work if you want quick feedback on whether your scope is realistic.

NoteCurrent schedule

For Spring 2026, the final project is assigned Saturday, April 18, 2026 and due Wednesday, May 13, 2026 at 11:59 pm PT, which gives you about 3.5 weeks. That is enough time for a strong project, but it is not enough time to keep every part of the pipeline open-ended at once.

ImportantRecommended default lane

If you are not sure how to scope the project, use the course default:

• rebuild your Project 2 N-body simulator in JAX-native Leapfrog form,
• vary the initial virial ratio \(Q_0\) and Plummer scale radius \(a\),
• compute summary statistics such as \(f_{\rm bound}\), \(\sigma_v\), and \(r_h\),
• train an emulator on those outputs,
• use the emulator for parameter recovery on a held-out case.

NoteHelpful readings while you fill this out

If you need help scoping the simulator or emulator parts, keep these pages open while you work:

• JAX Part 3: Physics Applications
• Neural Networks and Scientific Emulation

1. What Problem Are You Solving?

Write a short description of your project in 3 - 5 sentences. This should become the first draft of your README.md overview.

Prompts:

• What physical system are you simulating?
• What are the input parameters?
• What outputs or observables are you predicting?
• What inverse problem are you trying to solve?

Notes:

2. Project 2 \(\to\) JAX Transition Map

The final project builds on Project 2, but it does not ask you to wrap the old code and call it done. Use this table to separate what you are carrying forward conceptually from what you are rebuilding computationally.

Keep from Project 2	Rebuild in JAX-native form	Re-validate in final project
Physical model / equations
State representation
Leapfrog update logic
Diagnostics
Validation cases
Repo or command structure

After filling the table, write one sentence that captures the transition:

My Project 2 \(\to\) JAX rebuild strategy is:

3. Minimum Simulator Validation Gate

Before you move on to emulation, your simulator should already be trustworthy enough to use as a scientific instrument. Write down the exact evidence you plan to produce.

A. One simple validation case with expected qualitative behavior

What system will you use, and what behavior should you see?

B. One quantitative conservation diagnostic

What quantity will you track, and what behavior would count as acceptable?

• total energy:
• center of mass or total momentum:

C. One timestep justification

Which two timestep choices will you compare, and what result would convince you that your production timestep is good enough?

D. One reproducible validation path

What non-interactive command should a grader run to regenerate your validation evidence?

python run.py validate

If your actual command will differ, write it here:

4. Dataset And Observable Plan

The emulator can only learn from the data you generate. Scope this part before you spend time training models.

Parameter design

• Which parameters will vary?
• What ranges will you use?
• How many training runs will you start with?
• How many held-out runs will you reserve for evaluation?

Summary statistics or observables

List the outputs your emulator will predict, and give one sentence for why each one is scientifically meaningful.

Small debug dataset

What is your smallest end-to-end dataset that lets you test the full pipeline before scaling up?

5. Emulator And Inference Plan

Keep this section modest. The point is to define a clear baseline, not to promise every advanced idea you might try later.

Emulator baseline

• What model will you start with?
• How will you normalize inputs and outputs?
• What held-out metrics or plots will you use to judge whether the emulator is good enough?

Inference plan

• What parameters will you infer?
• What synthetic or held-out observation will you use?
• What result would count as a successful recovery?

6. Repo Contract And Run Path

A strong final project is reproducible under deadline pressure. Decide now how a reader will find the important entrypoints.

Expected commands

Write the commands you want to support from the repo root:

python run.py --help
python run.py test
python run.py validate
python run.py make-figures

If your actual commands will differ, write them here:

• install:
• test:
• validate:
• data generation:
• training:
• inference:
• figures:

Ownership map

Write one line for where each part of the project lives:

• simulator:
• summary statistics:
• emulator:
• inference:
• diagnostics:
• figures:

7. Three-And-A-Half-Week Execution Plan

A final project usually goes off track when everything stays “in progress” at once. Use this section to force sequencing.

Week 1

Goal: JAX-native simulator rebuild plus minimum validation evidence

What must be done by the end of Week 1?

Week 2

Goal: dataset generation plus baseline emulator

What must be done by the end of Week 2?

Week 3

Goal: emulator evaluation plus inference

What must be done by the end of Week 3?

Final stretch: last 3 - 4 days before the deadline

Goal: report, figures, reproducibility cleanup, and submission polish

What must be done before Wednesday, May 13?

Scope reality check

What will you cut first if you are behind schedule:

• a more advanced emulator architecture,
• a larger training dataset,
• extra figures,
• extra parameter dimensions,
• other optional stretch goals?

8. Risk Check

Answer these honestly. This is often the most useful part of the worksheet.

• What is the biggest technical risk in your current plan?
• What part of the project are you most likely to overscope?
• If you get behind, what is your minimum viable final project that would still be scientifically defensible?

9. Launch Checklist

Before you leave the planning stage, you should be able to say yes to all of these:

• I can explain the inverse problem in plain language.
• I know what from Project 2 I am reusing conceptually and what I am rebuilding in JAX.
• I have named the exact validation evidence I need before emulator training.
• I have a small debug dataset plan before the full data-generation run.
• I know what my baseline emulator and evaluation plots will be.
• I know what commands a grader should run first.
• I have a realistic Week 1 goal that does not depend on every later stage working.
• I know what I will cut first if the project starts to run long.

If one of these boxes is still a “not yet,” that is the place to tighten your scope before writing more code.