Computational Physics Modelling

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

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.

You'll sign in first, then come straight back here.

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

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.

You'll sign in first, then come straight back here.

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

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.

You'll sign in first, then come straight back here.