Milestone map
Milestone map
3 milestones
Specify system and derive equations to implement
1–2 weeks
Select a specific physical system and the numerical method appropriate for modelling it, then derive the governing equations you will implement. Computational physics modelling is the primary route — no physical laboratory is required. Choose a system with known analytical solutions or published results so that M2 validation is possible: 1D heat equation, planetary orbital mechanics, damped harmonic oscillator, 2D Ising model, Lotka-Volterra predator-prey dynamics, or similar well-characterised systems.
Proof required
Submit a written system specification (the physical system, the governing equation(s) in mathematical form, the boundary conditions, and the initial conditions), your chosen numerical method with a justification for why it is appropriate for this system, and the theoretical derivation showing how the governing equations are discretised for numerical implementation.
What gets checked
- Governing equations are written in standard mathematical notation — not described in words but expressed as differential or integral equations with defined variables and parameters
- Method justification addresses the specific properties of the system that influence the choice — not 'Runge-Kutta is good for ODEs' but why RK4 specifically is appropriate given the stiffness, time scale, and accuracy requirements of this system
- Discretisation derivation shows each step from the continuous equation to the numerical approximation — not just the final finite-difference formula
Common mistakes
- Choosing a system without a known reference solution — validation in M2 requires something to compare against; without a reference, the model cannot be verified
- Selecting a numerical method without understanding its stability properties — a method that is unstable for the chosen time step size will produce nonsensical results regardless of implementation correctness
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Ask the submitter to explain the stability condition for their chosen numerical method — a physicist who genuinely understands their method can explain what happens when the time step is too large.
- Ask why they chose this system as their model rather than an alternative — confirms the choice was deliberate and informed.
- Ask them to derive one step of the discretisation from the governing equation on paper during the review — confirms genuine mathematical understanding.
Implement model and validate against reference
2–4 weeks
Write the working computational implementation, run the model, and validate the output against known analytical solutions or published results. Validation is the core scientific act at this milestone: a computational model that produces outputs without comparison to a known result has not been verified. For every system, identify the limiting case where an analytical solution exists and confirm the model converges to it.
Proof required
Submit your code (Python, Julia, or equivalent — with comments explaining each section's purpose), the output figures showing the modelled system behaviour, and a validation comparison showing the agreement between your numerical results and the reference analytical or published result, with the error quantified.
What gets checked
- Code is submitted and runs without errors — not described or pseudocoded
- Validation comparison shows a quantified agreement measure — not 'the result looks similar' but the specific error metric (relative error, RMS deviation, or convergence rate)
- At least one parameter study is shown — varying a physical parameter to demonstrate qualitatively different behaviour (e.g., overdamped vs underdamped oscillator, stable vs unstable orbital)
Common mistakes
- Submitting figures without submitting the code — the code is the scientific artifact; figures alone are not reproducible results
- Not performing validation — a model that has not been compared to a reference may contain implementation errors that produce wrong results even when they look physically plausible
Resources
Foundationstart here
What a verifier looks for
- Ask the submitter to run the code in front of you and point to the validation comparison in the output — confirms the code produces the submitted figures.
- Ask what error metric they chose for validation and why — 'it looks right' is not a validation; they should name a specific measure.
- Ask what happens to the model behaviour when a specific physical parameter is changed — tests whether they understand the physics the model is implementing.
Write report and present with Q&A
1–2 weeks to write and schedule review
Complete a computational physics report communicating the model, its validation, and the physical insights gained from parameter studies. Present to a physicist or computational scientist for a Q&A that probes numerical method choices, validation rigour, and physical interpretation of results.
Proof required
Submit your complete computational physics report (2500–4000 words: introduction with physical context, methods including the governing equations and numerical method, results with validation and parameter study figures, discussion of physical insights, and conclusion) plus a Q&A record showing specific technical challenges from the reviewer and your responses. The reviewer must be named and their physics or computational science background stated.
What gets checked
- Methods section provides enough detail that the model could be re-implemented from the report alone — includes governing equations, discretisation scheme, time step, spatial resolution, and any convergence tests performed
- Discussion section identifies physical insights that went beyond the initial motivation — what was learned from the parameter study that was not obvious before running the model
- Q&A record shows at least two technical challenges and substantive responses
Common mistakes
- A methods section that describes the code structure rather than the physics and mathematics — the report must communicate the model at the level of equations and physical reasoning, not line-by-line code description
- A reviewer with only programming experience and no physics training — the Q&A must challenge the physical interpretation and numerical method validity, which requires physics domain knowledge
Resources
Depthgo deeper
What a verifier looks for
- Ask the submitter to explain their convergence test — did they check that reducing the time step or grid spacing does not change the results?
- Ask what the single most important physical insight from the parameter study was — confirms the model was used for genuine scientific exploration, not just demonstrating it runs.
- Verify the reviewer has physics or computational science experience — a general programmer cannot probe the physical validity of the model.