High-fidelity runs
What you will accomplish
A propagation you can defend in a design review, with the force terms you enabled stated and justified.
The important part is not enabling more physics. It is knowing which terms require an input you may not have, because a high-fidelity run fed a guess is expensive and wrong rather than merely wrong.
Prerequisites
- A constellation.
- Propagation fidelity for the model ladder.
The ladder
# Point-mass Earth only.
orbitforge simulate --constellation ph1.json \
--duration-hours 24 --step-seconds 300 --model two-body
# Secular J2.
orbitforge simulate --constellation ph1.json \
--duration-hours 24 --step-seconds 300 --model j2
# Full numerical.
orbitforge simulate --constellation ph1.json \
--duration-hours 24 --step-seconds 300 \
--model numerical --gravity j4 \
--drag-cdam 0.02 --srp-cram 0.02 --third-body sun,moonSimulated 60 satellites over 24.0 h at 300 s steps (289 samples each) using two_body.
Simulated 60 satellites over 24.0 h at 300 s steps (289 samples each) using j2.
Simulated 60 satellites over 24.0 h at 300 s steps (289 samples each) using numerical (zonal4+drag+srp+sun+moon, dp54).Note what the third summary prints: numerical (zonal4+drag+srp+sun+moon, dp54). The line records exactly which terms were active and which integrator
ran.
That string is the provenance of the result. Copy it into whatever document quotes the numbers; “we used the numerical model” is not a reproducible statement, and this is.
The 60-satellite, 24-hour run above completed in well under a second of wall clock on a laptop, parallelized across cores. Fidelity is rarely the thing that makes a run slow; grid resolution in coverage analysis is.
Each term demands an input
A high-fidelity propagator fed a guessed coefficient is not more accurate than a low-fidelity one. It is more expensive and equally wrong.
Drag and solar radiation pressure are opt-in precisely because each needs a number that describes your actual spacecraft.
| Term | Flag | Needs | If you do not have it |
|---|---|---|---|
| Zonal gravity | --gravity j4 | Nothing | Always enable; it is free and always correct |
| Drag | --drag-cdam | Cd times A over m, m^2/kg | Leave it off and say so |
| Solar radiation pressure | --srp-cram | Cr times A over m, m^2/kg | Leave it off and say so |
| Third bodies | --third-body sun,moon | Nothing | Always reasonable to enable |
Leaving a term off and stating the omission is honest. Enabling it with an invented coefficient produces a number that looks authoritative and is not, and nobody downstream can tell the difference.
Choosing the gravity field
| Setting | Use |
|---|---|
two-body | Intuition only |
j2 | The dominant departure from a sphere |
j4 | Sensible default for a numerical run |
egm96:16x16 | When you need the full field, at real cost |
J2 is by far the largest term. Going from j2 to j4 is cheap and worth taking;
going to a high-degree spherical harmonic field costs substantial time and buys
little for constellation-scale questions.
Atmosphere model
--drag-cdam 0.02 --atmosphere harris-priesterexponential is a single-scale-height profile with no time variation.
harris-priester adds a diurnal bulge, so drag varies as the satellite passes
between day and night sides.
Neither models solar activity, which is the dominant source of density uncertainty. Atmospheric density is uncertain by tens of percent and varies strongly across the solar cycle, so a drag-dominated result is a range, not a value.
A common practice is to run at expected and at elevated density and size for the worse case.
When the extra fidelity actually matters
| Question | Model that answers it |
|---|---|
| Does the geometry look roughly right? | two-body |
| Where will the planes be in three weeks? | j2 at minimum |
| What is the station-keeping budget? | numerical with a real ballistic coefficient |
| Where is this cataloged object? | sgp4, and nothing else |
| Reproduce a delivered trajectory | ephemeris, within the table span |
The middle row is where most design work sits, and it is the row that most often
gets two-body by default.
Checking convergence
Numerical integration has its own error, separate from model error. Halve the step and confirm the result does not move:
orbitforge simulate --constellation ph1.json \
--duration-hours 24 --step-seconds 150 \
--model numerical --gravity j4 --third-body sun,moonIf it does move, the integrator tolerance was doing more work than the physics. In practice, for typical tolerances, model error and initial-state error dominate integration error by a wide margin, so the answer is usually stable and the check is cheap.
What to record with the result
- The model string the run printed, verbatim.
- Every coefficient you supplied, with its units.
- Any term you deliberately left off, and why.
- The window, step, and start epoch.
That list is what makes the number reproducible six months later, which is the real standard for a design review.
Next steps
simulatereference for the full force-model flag set.- Accuracy and limitations for where error actually comes from.
main (pre-release)