Skip to content
pg_orbit

From GMAT to SQL

GMAT (General Mission Analysis Tool) is NASA’s open-source mission design software. It handles everything from preliminary trajectory design to full mission planning with low-thrust propulsion, gravity assists, and multi-body optimization. It’s powerful, free, and built for professional mission designers.

pg_orbit is not a mission design tool. It solves one specific problem from GMAT’s domain — Lambert transfers between planets — and makes it available as a SQL function. This page is about that narrow overlap, and why doing Lambert analysis in SQL is sometimes a better fit than launching a full mission design environment.

The Lambert problem

Section titled “The Lambert problem”

Given two positions in space and a time of flight, find the orbit that connects them. This is the starting point for interplanetary trajectory design: “If I leave Earth on this date and arrive at Mars on that date, what does the transfer orbit look like?”

The solution gives you departure C3 (the energy needed to escape Earth’s gravity), arrival C3 (the energy you arrive with at the target), and the transfer orbit parameters. A pork chop plot is a grid of these solutions across a range of departure and arrival dates — the visual tool mission designers use to identify launch windows.

Setting up a Lambert transfer

Section titled “Setting up a Lambert transfer”

GMAT uses a scripting language with a GUI. A minimal Lambert-style analysis (technically a “targeting” problem in GMAT) requires understanding several concepts specific to the tool.

% GMAT script for Earth-Mars transfer targeting
% This is simplified — real GMAT scripts are longer


Create Spacecraft sc;
sc.DateFormat = UTCGregorian;
sc.Epoch = '01 Oct 2028 00:00:00.000';
sc.CoordinateSystem = EarthMJ2000Eq;
sc.DisplayStateType = Cartesian;


Create ForceModel DeepSpace;
DeepSpace.CentralBody = Sun;
DeepSpace.PointMasses = {Sun, Earth, Mars};


Create Propagator DeepSpaceProp;
DeepSpaceProp.FM = DeepSpace;
DeepSpaceProp.Type = PrinceDormand78;
DeepSpaceProp.InitialStepSize = 86400;


Create ImpulsiveBurn TOI;
TOI.CoordinateSystem = EarthMJ2000Eq;


Create ImpulsiveBurn MOI;
MOI.CoordinateSystem = MarsMJ2000Eq;


Create DifferentialCorrector DC;


Create OrbitView SolarSystemView;
SolarSystemView.Add = {sc, Earth, Mars, Sun};


BeginMissionSequence;
Target DC;
  Vary DC(TOI.Element1 = 3.0, {Perturbation = 0.01, ...});
  Vary DC(TOI.Element2 = 0.0, {Perturbation = 0.01, ...});
  Vary DC(TOI.Element3 = 0.5, {Perturbation = 0.01, ...});
  Maneuver TOI(sc);
  Propagate DeepSpaceProp(sc) {sc.Mars.Periapsis};
  Achieve DC(sc.Mars.RMAG = 3500, {Tolerance = 0.1});
  Achieve DC(sc.ElapsedDays = 258, {Tolerance = 0.1});
EndTarget;

This is the compressed version. The GMAT tutorial for interplanetary transfers runs about 50 pages. You configure:

  • Spacecraft objects with initial state vectors
  • Force models with point masses and perturbations
  • Propagators with numerical integration settings
  • Impulsive burn objects
  • A differential corrector (the targeting engine)
  • Visualization objects

Then you write a targeting sequence that varies the burn parameters until the spacecraft reaches the desired conditions at arrival.

For a single transfer, this gives you a precise, multi-body solution with accurate planetary perturbations. That’s genuinely valuable for mission design.

For a survey across hundreds of departure/arrival date combinations to find the optimal launch window? You’d need to script a loop over the targeting sequence, handle convergence failures, and manage output parsing.

Pork chop plots

Section titled “Pork chop plots”

This is where the SQL approach really differentiates itself. A pork chop plot surveys transfer energy across a grid of departure and arrival dates. In mission design, this is how you find launch windows.

GMAT doesn’t have a built-in pork chop plot generator. You would:

  1. Write a GMAT script with parameterized departure/arrival epochs
  2. Create an outer loop (in GMAT script or an external driver — Python, MATLAB) that iterates over your date grid
  3. For each combination, run the targeting sequence
  4. Handle convergence failures (some date combinations don’t produce valid solutions with the chosen initial guess)
  5. Collect output from GMAT’s report files
  6. Parse and aggregate into a matrix
  7. Plot externally (GMAT’s plotting is limited for contour-type visualization)

This is doable — mission design teams do it — but it’s a multi-hour workflow for setup and execution, and convergence issues require manual attention.

Alternatively, most teams use a dedicated Lambert solver in Python or MATLAB (not GMAT) for pork chop plots, and only bring GMAT in for detailed trajectory refinement once the launch window is identified.

Multi-planet survey

Section titled “Multi-planet survey”

Which planets have favorable transfer windows from Earth in a given year? This kind of broad survey is natural in SQL but tedious in GMAT.

-- Survey all inner/outer planet transfers from Earth, 2028-2030
-- Which targets have the lowest departure C3 in each year?
SELECT target_id,
       CASE target_id
         WHEN 1 THEN 'Mercury' WHEN 2 THEN 'Venus'
         WHEN 4 THEN 'Mars'    WHEN 5 THEN 'Jupiter'
         WHEN 6 THEN 'Saturn'
       END AS target,
       dep::date AS best_departure,
       arr::date AS best_arrival,
       round(min_c3::numeric, 2) AS min_c3_km2s2,
       round(tof::numeric, 0) AS flight_days
FROM (
  SELECT target_id, dep, arr,
         c3_departure AS min_c3,
         tof_days AS tof,
         ROW_NUMBER() OVER (
           PARTITION BY target_id
           ORDER BY c3_departure
         ) AS rn
  FROM generate_series(1, 6) AS target_id,
       generate_series(
         '2028-01-01'::timestamptz,
         '2030-12-01'::timestamptz,
         interval '10 days'
       ) AS dep,
       generate_series(
         '2028-06-01'::timestamptz,
         '2033-01-01'::timestamptz,
         interval '10 days'
       ) AS arr,
  LATERAL lambert_transfer(3, target_id, dep, arr) AS xfer
  WHERE target_id != 3            -- Not Earth-to-Earth
    AND tof_days BETWEEN 60 AND 1500
    AND c3_departure < 100
) sub
WHERE rn = 1
ORDER BY min_c3;

This scans a wide grid and finds the single best (lowest C3) departure/arrival combination for each target planet. It’s a brute-force approach — not how a mission designer would work, but useful for exploration and screening.

Where GMAT wins

Section titled “Where GMAT wins”

Multi-body dynamics. GMAT propagates trajectories with full N-body gravitational perturbations — Sun, planets, moons, solar radiation pressure, atmospheric drag. pg_orbit’s Lambert solver is strictly two-body (Sun + spacecraft).

Low-thrust trajectories. Electric propulsion missions (ion engines, Hall thrusters) require continuous thrust modeling. GMAT handles this; pg_orbit does not.

Gravity assists. Flyby trajectories — using a planet’s gravity to change direction and speed — are central to many interplanetary missions. GMAT models these with full patched-conic or N-body dynamics. pg_orbit solves point-to-point transfers only.

Mission sequence optimization. GMAT’s differential corrector and optimizer can target complex mission constraints: orbital insertion parameters, flyby altitudes, fuel budgets. pg_orbit returns raw transfer parameters without optimization.

Attitude modeling. GMAT tracks spacecraft orientation — important for solar panel pointing, antenna alignment, and sensor geometry. pg_orbit has no concept of spacecraft attitude.

Visualization. GMAT includes 3D trajectory visualization. pg_orbit returns numbers.

Where pg_orbit wins

Section titled “Where pg_orbit wins”

Speed of iteration. Changing a date range or adding a constraint is editing a SQL query. No restarting a GUI, no waiting for script compilation, no managing convergence parameters.

Batch computation. 22,500 Lambert solves in 8.3 seconds, parallelized across cores automatically. GMAT’s targeting loop would take orders of magnitude longer for the same grid.

Integration with data. If your satellite catalog, contact schedules, or mission database lives in PostgreSQL, Lambert results join directly with those tables. No file export/import cycle.

Accessibility. GMAT has a steep learning curve — the tutorial for a basic interplanetary transfer is a 50-page document. pg_orbit’s Lambert solver requires knowing one SQL function and its six output columns.

The intended workflow

Section titled “The intended workflow”

pg_orbit’s Lambert solver fits into a specific phase of mission planning:

  1. Screen with pg_orbit. Generate a pork chop plot across a broad date range. Identify the departure/arrival windows with favorable C3 values. This takes minutes, not hours.

  2. Refine with GMAT. Take the promising date ranges from step 1 and set up detailed trajectory design in GMAT. Add perturbations, model the departure and arrival spirals, check flyby opportunities.

  3. Iterate. If the refined trajectory shifts the window, go back to pg_orbit to explore the neighborhood in SQL. Faster iteration between broad surveys and detailed analysis.