Advanced mathematics & numerical methods
This module marks a decisive step: mathematics is no longer a collection of formulas to plug numbers into, but a language for building, testing and criticizing models. A trajectory, navigation filter, thermal budget or reliability estimate rapidly becomes a multi-variable problem whose quantities evolve with time. The objective is not to train a pure mathematician, but to develop the habits needed to understand what engineering software is computing and to recognize a physically absurd result.
Mastery objectives
- explain concepts with units and assumptions
- redo a simple calculation by hand before using a tool
- identify at least one failure mode or model limitation
- connect the discipline to a complete Mars architecture
1. Vectors and matrices: organize several quantities at once
A vector groups components that belong to one state: position x, y, z; velocity vx, vy, vz; or sensor errors. A matrix describes how several quantities combine. In space problems it can change reference frames, propagate covariance or linearize a system. Dimensional compatibility comes first: a 3×3 matrix can only multiply a compatible object. Writing dimensions before computing prevents many mistakes.
Engineering habit. For “vectors and matrices: organize several quantities at once”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
2. Derivatives and gradients: measure the rate of change
A derivative answers the question ‘how much does the output change when the input changes slightly?’ Velocity is the derivative of position, acceleration the derivative of velocity, and a gradient collects several partial derivatives. In design these ideas become sensitivity analysis: if mass rises by one percent, which mission variable reacts most strongly? A gradient helps rank parameters instead of changing everything blindly.
Engineering habit. For “derivatives and gradients: measure the rate of change”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
3. Differential equations: represent systems that evolve
Many physical laws connect a quantity to its derivative. The equation dv/dt=a says velocity evolves according to acceleration. For a tank, dm/dt can represent an outgoing mass flow; for a battery, dE/dt connects stored energy, generation and demand. A differential equation is therefore an evolution rule, not an abstract decoration. Initial and boundary conditions are as important as the equation itself.
Engineering habit. For “differential equations: represent systems that evolve”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
4. Numerical integration: move in small steps without fooling yourself
When an exact solution does not exist or is impractical, numerical integration advances time step by step. Euler is simple but can accumulate substantial error; Runge–Kutta samples several slopes during a step and generally improves accuracy. Time step is an engineering choice: too large hides dynamics, too small wastes computation. Convergence is checked by repeating the calculation with a finer step.
Engineering habit. For “numerical integration: move in small steps without fooling yourself”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
5. Interpolation, fitting and imperfect data
Measurements do not always arrive exactly when a model needs them. Interpolation estimates a value between samples. Fitting searches for model parameters that best explain a set of observations. Interpolation must be distinguished from extrapolation: predicting outside the measured range is much riskier. A smooth curve is never proof that the model is correct.
Engineering habit. For “interpolation, fitting and imperfect data”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
6. Probability, covariance and uncertainty propagation
A mission does not have a perfectly known position or an exactly constant consumption rate. Uncertainty is therefore represented using quantities such as standard deviations and covariances. Positive covariance means two errors tend to move together; negative covariance means they tend to move in opposite directions. Propagation asks how input uncertainty transforms into output dispersion.
Engineering habit. For “probability, covariance and uncertainty propagation”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
7. Monte Carlo: repeat the scenario to see a distribution
A Monte Carlo simulation randomly samples inputs from defined distributions and runs the model many times. The result is a distribution rather than one answer: median, percentiles and tails. This is powerful for nonlinear systems, but it cannot rescue a bad physical model. Unrealistic input distributions simply produce statistically precise nonsense.
Engineering habit. For “monte carlo: repeat the scenario to see a distribution”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
8. Numerical conditioning and plausibility checks
A calculation can be mathematically defined yet numerically fragile. Subtracting nearly equal numbers or inverting an ill-conditioned matrix can amplify rounding errors. Engineers monitor orders of magnitude, units, residuals and stability. A durable rule remains: before trusting many decimal places, estimate the answer by hand and ask whether its sign and scale make physical sense.
Engineering habit. For “numerical conditioning and plausibility checks”, write the inputs, outputs, units and validity range first. Then build one nominal and one degraded case. This two-case approach prevents a correct equation from being mistaken for an operationally robust Mars architecture.
Worked example step by step
The work method is always the same: state what every symbol represents, convert all units into a coherent system, perform the operation, then translate the result into a sentence. Finally perform an order-of-magnitude check. If the answer changes by a factor of one thousand because millimetres were treated as metres, the conversion must be visible in the calculation.
Progressive exercise
- Choose a simple case and list every input with units.
- Compute the nominal result without margin.
- Vary the most uncertain parameter by ±20% and compare.
- Inject one credible failure and explain which indicator detects it.
- Decide whether the system continues, degrades or stops.
Reasoned solution
A good solution is not only the final number. It shows conversions, why the equation applies, sensitivity and the resulting decision. If different plausible assumptions lead to the same operational decision, the design is relatively robust to that uncertainty. If a small variation reverses the decision, the parameter becomes a priority for measurement or margin.
Validation mini-project
Build a two-to-four-page engineering note applying this course to one Mars subsystem. Include need, assumptions, functional sketch, hand calculation, second calculation or simulation, uncertainties, injected failure, decision criteria and three primary references. The goal is a chain of evidence that another reader can reproduce.
Common errors to detect
- mixing units or frames without explicit conversion;
- presenting calculated values as measured data;
- ignoring a model’s validity range;
- confusing numerical precision with physical accuracy;
- sizing only the nominal case with no margin or degraded mode.