Orbital Mechanics Engineer Portfolio in 2026: GMAT, Orekit, and Poliastro Projects

What an orbital mechanics portfolio must prove in 2026

An orbital mechanics engineer portfolio is not a gallery of attractive orbit plots. It is evidence that you can translate a mission question into assumptions, equations, software, validation tests, and an engineering recommendation. Hiring teams want to see whether you understand why a trajectory behaves as it does, not merely whether you can run a mission analysis tool.

The strongest portfolio therefore behaves like a compact engineering record. Each project should state the mission objective, define the dynamical model, identify the data sources, explain the numerical method, present one decision-relevant figure, and discuss the limitations. A recruiter may scan the repository in two minutes, while a flight dynamics engineer may inspect it for an hour. Your presentation has to serve both readers.

A balanced portfolio should demonstrate five different capabilities:

1. Interplanetary mission reconstruction and gravity-assist reasoning.
2. High-fidelity Earth-orbit propagation with realistic perturbations.
3. Low-thrust trajectory design and numerical optimization.
4. Orbit determination with uncertainty estimation.
5. Conjunction assessment and collision-avoidance planning.

This combination is more persuasive than five variations of a Hohmann transfer notebook. It shows that you can work across mission design, spacecraft operations, estimation, and space safety. It also gives interviewers several entry points, from fundamental orbital mechanics to software engineering and numerical analysis.

Tool selection matters because it reveals how you think. GMAT shows that you can build and inspect complete mission sequences. Orekit demonstrates comfort with a production-oriented Java astrodynamics library, explicit frames, force models, events, and time systems. Python projects using poliastro, NumPy, SciPy, Astropy, pandas, and Plotly reveal whether you can create custom analysis workflows rather than relying entirely on a graphical interface.

Do not claim operational accuracy simply because you used professional software. A propagation result is only as credible as its initial state, reference frame, force model, environmental data, integration settings, and validation process. Good candidates expose those choices. Weak candidates hide them behind screenshots.

The five projects in this guide form a coherent portfolio rather than an arbitrary list. Together, they show increasing responsibility: first reproduce a historical trajectory, then model a satellite, design a transfer, estimate an uncertain orbit, and finally recommend a maneuver under operational constraints. That progression aligns closely with the competencies discussed in a practical flight dynamics engineer training guide.

By the end, your GitHub profile should communicate a simple message: you can formulate an astrodynamics problem, implement a defensible solution, test it, and explain what an operator or mission designer should do with the result.

Build every project as a small engineering product

Before starting the individual simulations, create a common project standard. Consistent structure makes your work easier to evaluate and signals that you understand reproducibility. It also prevents your portfolio from becoming a collection of notebooks that only run on your machine.

A useful repository structure is:

project-name/
  README.md
  methodology.md
  environment.yml
  data/
    raw/
    processed/
  src/
  notebooks/
  tests/
  figures/
  results/
  references/
  LICENSE

The README.md is the landing page, not the full technical report. It should contain the mission question, a one-paragraph result, the main figure, setup instructions, and links to the methodology and results. A reviewer should understand the project before opening a notebook.

The methodology note should usually be two to four pages when rendered. Include the equations or model descriptions that materially affect the result. Define the central body, gravitational parameter source, coordinate frames, epoch and time scale, integrator, tolerances, perturbations, spacecraft properties, and optimization objective. If you omit a physical effect, explain why.

Each project should have one primary figure. More plots can live in the results directory, but the primary figure must answer the mission question. Examples include a heliocentric trajectory with labeled encounters, a time history of altitude divergence between force models, or a risk-versus-delta-v trade curve.

Make the software repeatable from the command line. A reviewer should be able to clone the repository, install a pinned environment, and run something similar to:

python -m src.run_case --config configs/baseline.yaml
pytest

Store scenario parameters in YAML, TOML, or JSON rather than scattering constants across notebook cells. Include units in parameter names when a file format cannot enforce dimensional types. Better still, use unit-aware libraries where practical and test that transformations preserve expected dimensions.

A credible project also includes negative results. If an optimizer fails for some initial guesses, show the convergence basin. If atmospheric drag dominates your deployment prediction, quantify the sensitivity to area-to-mass ratio and density uncertainty. If a covariance matrix becomes non-positive-definite, document the numerical repair rather than silently replacing it.

Version control should show meaningful development. Use issue descriptions, feature branches, descriptive commits, and tagged releases. Avoid uploading one giant final commit after the project is complete. A visible engineering history helps employers distinguish real work from a copied tutorial.

These practices apply beyond astrodynamics. The broader principles in this job-ready technology portfolio guide are especially relevant: demonstrate a complete workflow, document decisions, and make results verifiable. In a specialized field, disciplined packaging can be the difference between an interesting repository and a shortlist-ready portfolio.

Project 1: Recreate Cassini's VVEJGA trajectory in GMAT

Reconstructing the Cassini interplanetary cruise is an excellent flagship project because it forces you to combine ephemerides, reference frames, launch conditions, gravity assists, differential correction, and mission-event reporting. The goal is not to reproduce every navigation solution used by the original mission. The goal is to create a defensible approximation of the Venus-Venus-Earth-Jupiter Gravity Assist sequence and explain where your model differs from historical performance.

Cassini launched on October 15, 1997, encountered Venus on April 26, 1998 and June 24, 1999, returned to Earth on August 18, 1999, flew past Jupiter on December 30, 2000, and arrived at Saturn in July 2004. NASA describes this VVEJGA sequence as a way to increase the spacecraft's heliocentric energy while reducing the launch energy required for a direct Saturn transfer. (science.nasa.gov)

Use the current NASA General Mission Analysis Tool software description as your authoritative software reference. NASA lists GMAT as an open-source mission design, optimization, and navigation system that supports low Earth orbit through deep-space missions and can be used through a GUI, scripts, Python, or Java. The R2026 software listing makes GMAT particularly relevant for a portfolio prepared in 2026. (software.nasa.gov)

Start with a heliocentric spacecraft state near the launch epoch. Build a mission sequence containing propagation segments and encounter targets for Venus, Venus, Earth, Jupiter, and Saturn. You can begin with patched-conic reasoning to produce initial guesses, then use GMAT differential correction or optimization tools to refine selected variables.

Potential control variables include:

• Launch asymptote direction and magnitude.
• Time of flight between encounters.
• Small deterministic correction maneuvers.
• B-plane coordinates at each flyby.
• Saturn arrival epoch or arrival hyperbolic excess velocity.

Do not optimize everything at once. First target the initial Venus encounter. Save the converged state, add the second Venus segment, and continue sequentially. Once the full chain is feasible, perform a coupled correction to reduce discontinuities or improve the final arrival condition.

Your primary figure should show the heliocentric trajectory in the ecliptic plane with planetary orbits, encounter points, arrows indicating direction of travel, and a compact event table. Use the same color for each planetary orbit and its label. Avoid a three-dimensional camera angle that makes the geometry harder to interpret.

The event table should report encounter epoch, periapsis altitude, incoming and outgoing hyperbolic excess velocity, turning angle, and any modeled correction maneuver. Compare your epochs against the public mission timeline. Differences should be discussed as model limitations rather than disguised.

A strong methodology note explains whether you used point-mass bodies, a high-order Earth gravity model near departure, solar radiation pressure, relativistic corrections, finite burns, or impulsive maneuvers. It should also distinguish planet-centered B-plane analysis from the heliocentric trajectory view.

This project demonstrates mission sequencing, nonlinear targeting, gravity-assist physics, deep-space coordinate handling, and historical validation. In an interview, be ready to explain why an apparently small change in B-plane targeting can produce a large downstream change at the next encounter. That conversation is often more valuable than achieving an exact visual match to NASA's published trajectory.

Project 2: Simulate small-satellite deployment with Orekit

The second project should move from interplanetary design to operational Earth-orbit dynamics. Model a carrier spacecraft deploying several small satellites into low Earth orbit, then quantify how J2 oblateness and atmospheric drag change their relative geometry. This gives you a natural reason to discuss force models, area-to-mass ratio, integrator settings, frames, event detection, and uncertainty.

Choose a plausible parent orbit, such as a near-circular orbit between 450 and 600 kilometers in altitude. Define three or four deployed spacecraft with small relative separation velocities. Vary the deployment direction among along-track, radial, and cross-track cases, while keeping the impulse magnitude within a clearly stated engineering range selected for the simulation.

Build three propagation configurations:

1. Two-body Keplerian motion.
2. Central gravity plus J2.
3. A higher-fidelity case with J2, atmospheric drag, and optional third-body or solar radiation pressure effects.

Orekit supports analytical propagators, TLE propagation, numerical integration, event detection, frames, and rich force-model configurations. Its numerical propagation architecture can combine gravity and surface forces such as atmospheric drag, provided the spacecraft properties and environmental models are defined. (orekit.org)

The project is not complete when all spacecraft have been propagated. Compute operationally meaningful relative quantities: along-track separation, radial separation, cross-track separation, relative speed, differential nodal drift, and minimum pairwise distance. Report how quickly the simplified two-body prediction becomes misleading.

Your primary figure should display along-track separation over several days for all three force-model configurations. A shaded band can represent uncertainty from drag coefficient, atmospheric density scaling, or deployment impulse error. The visual should make one engineering conclusion obvious, such as when the assumed deployment plan no longer guarantees a minimum separation.

Add event detectors for altitude thresholds, equator crossings, eclipse entry, or minimum separation. Event-driven analysis is more representative of real flight dynamics work than saving a state at every arbitrary time step. It also demonstrates that you understand how to extract mission events from propagation rather than analyzing massive state arrays after the fact.

Validation should include at least two independent checks. First, reduce the force model to two-body dynamics and compare the numerical result with a Keplerian propagator. Second, run a step-size or tolerance convergence study. If halving the maximum integration step changes the reported minimum separation materially, your original configuration was not numerically trustworthy.

Then perform a sensitivity analysis. Change spacecraft mass, drag area, drag coefficient, deployment direction, and deployment velocity error. Rank the inputs by their effect on separation after one, three, and seven days. This turns a propagation demo into a mission-design study.

Document Orekit data dependencies and reference-frame transformations carefully. Explain the distinction between an inertial propagation frame and Earth-fixed coordinates used for ground tracks or atmospheric calculations. Record the time scale associated with every epoch.

This project demonstrates Java engineering, numerical propagation, perturbation modeling, event detection, formation geometry, and sensitivity analysis. It also provides excellent interview material because almost every design choice has a tradeoff: speed versus fidelity, deterministic output versus uncertainty, and simple deployment rules versus operational separation assurance.

Project 3: Design a low-thrust Earth-to-Mars transfer with poliastro

A low-thrust Earth-to-Mars project demonstrates a different class of thinking from an impulsive Lambert transfer. Continuous electric propulsion couples spacecraft mass, thrust direction, flight time, power assumptions, and trajectory geometry. The optimization can be difficult, so success depends on defining a bounded problem rather than promising an unrealistic global optimum.

Begin with a reference impulsive transfer. Select Earth departure and Mars arrival windows, retrieve or load planetary ephemerides, and solve a Lambert problem. Record the departure hyperbolic excess velocity, arrival hyperbolic excess velocity, transfer time, and total impulsive delta-v. This baseline gives you something concrete against which to compare the low-thrust case.

poliastro provides orbit objects, ephemerides, Lambert calculations, numerical propagation, maneuver utilities, and continuous-thrust guidance components. Its API separates convenient high-level objects from lower-level numerical functions, while Astropy quantities provide unit handling. (docs.poliastro.space)

Do not imply that a built-in function automatically solves the complete Earth-to-Mars optimal-control problem. Use poliastro for states, frames, ephemerides, propagation, and visualization, then implement the optimization layer explicitly with SciPy, CasADi, PyGMO, or another documented method. Pin the working package versions because scientific Python APIs and compatibility constraints can change.

A manageable first formulation uses direct transcription. Divide the trajectory into segments and assign thrust direction variables to each segment. Propagate the state and mass through the segments, then minimize a weighted objective such as propellant consumption plus terminal position and velocity error.

Define constraints for:

• Maximum thrust magnitude.
• Initial wet mass and dry mass.
• Specific impulse.
• Departure conditions.
• Mars arrival position and velocity tolerances.
• Maximum flight time.
• Optional Sun-distance or power constraints.

Start with a two-dimensional heliocentric model if necessary, then extend it to three dimensions. A simpler model that converges and is honestly validated is more persuasive than a complex optimizer that returns unexplained numbers.

Your primary figure should combine trajectory geometry with thrust information. One effective design plots the heliocentric path, Earth and Mars positions, and sparsely sampled thrust-direction arrows. Use a companion table for flight time, propellant fraction, terminal errors, and optimizer iterations rather than crowding the figure.

The methodology note must describe nondimensionalization, integration tolerance, optimizer termination criteria, and initial-guess strategy. Low-thrust optimization is sensitive to scaling. If position values are expressed in kilometers while mass fractions are near one, an unscaled objective can lead the optimizer to prioritize the wrong residuals.

Include a convergence study across several initial guesses. Compare a tangential-thrust seed, a Lambert-derived seed, and randomized smooth control profiles. Report successful runs as well as failures. This demonstrates that you understand optimizer behavior rather than treating the first converged answer as unique.

Validation can include forward propagation of the final control history, a mass-accounting check using the rocket equation's continuous form, and comparison with the impulsive baseline. Explain that lower thrust does not automatically mean lower mission cost. Flight time, launch energy, power, thermal constraints, communication geometry, and arrival requirements all matter.

Candidates who want structured practice in trajectory design, orbit determination, and mission analysis can use Refonte Learning's Astrodynamics Specialist Program to develop these skills around portfolio-ready engineering work. Your repository should still stand independently, with transparent equations, executable code, and results that can be challenged.

Project 4: Build a Kalman-filter orbit determination pipeline

Orbit determination is where a portfolio begins to show estimation maturity. Instead of assuming the initial state is perfectly known, you estimate position and velocity from imperfect information, propagate uncertainty, process measurements, and evaluate residuals. The key is to be precise about what the data represents.

Use a time series of public two-line element sets for a stable, well-observed object. A single TLE is not a raw tracking measurement and should not be presented as ground truth. TLE parameters are designed for use with the SGP4 model. For a portfolio exercise, you can propagate historical TLEs to selected epochs and treat the resulting positions as reference pseudo-measurements, while explicitly stating that the experiment does not reproduce independent radar or optical orbit determination.

Create a pipeline with the following stages:

1. Download or store a dated sequence of TLE records.
2. Validate checksums, identifiers, epochs, and chronological order.
3. Propagate each record with SGP4 to a common set of measurement epochs.
4. Transform states into one consistently documented frame.
5. Add controlled measurement noise or derive topocentric range and angle observations from simulated stations.
6. Estimate a Cartesian state with an extended Kalman filter.
7. Compare predictions against held-out TLE-derived states.

Your state can begin with six Cartesian components. A more advanced implementation can augment the state with a drag-related parameter. Define the process-noise covariance rather than selecting an arbitrary diagonal matrix and moving on. Explain which unmodeled accelerations the process noise is intended to absorb.

The prediction model may use two-body dynamics initially, followed by J2 and drag. The measurement model should reflect the generated observation type. If you use range, azimuth, and elevation, derive or document the transformation from inertial spacecraft position to the station's local observation frame. Test angle wrapping at zero and 360 degrees.

Your primary figure should show normalized measurement residuals over time with plus and minus three-sigma bounds. This is more informative than another orbit plot because it exposes filter consistency. Add a small panel showing position error for the filtered solution and an uncorrected propagation baseline.

Evaluate the filter with root-mean-square residuals, innovation statistics, covariance behavior, and prediction error on held-out epochs. If the residual mean is significantly biased, investigate frame errors, time-scale mistakes, propagation-model deficiencies, or measurement-model problems. Do not simply increase the assumed noise until the plot looks acceptable.

Run ablation experiments. Compare extended Kalman filtering against a batch least-squares solution or an unscented Kalman filter. Remove drag, alter process noise, change measurement cadence, and vary the initial covariance. A table showing how those choices affect out-of-sample prediction will make the work substantially more credible.

Use unit tests for parsing, frame transformations, state-transition calculations, covariance symmetry, and positive-semidefinite checks. Add synthetic tests where the true orbit and measurement noise are known. This project naturally connects astrodynamics with the rigorous workflow expected in real-world data science portfolio projects.

The strongest conclusion is not that your estimate matches every TLE. It is that you understand the difference among measurement data, an orbital element product, a propagation model, and truth. That distinction is fundamental in flight dynamics and often separates thoughtful candidates from people who have only reproduced filter equations in a notebook.

Project 5: Create a CubeSat collision-avoidance maneuver planner

A collision-avoidance planner brings together propagation, uncertainty, optimization, operational constraints, and decision-making. It is an ideal final project because the output is not merely a state history. The software must recommend whether to maneuver, when to maneuver, and how to balance risk reduction against mission cost.

Use a synthetic but realistic conjunction scenario for a CubeSat in low Earth orbit. Define the primary spacecraft state and covariance, the secondary object state and covariance, and a predicted time of closest approach. Store the input in a documented CDM-like JSON or YAML schema. Do not label it an official Conjunction Data Message unless it actually conforms to the applicable standard.

The baseline analysis should propagate both objects to the time of closest approach and compute relative position in a local encounter frame. Report radial, in-track, and cross-track components, relative speed, miss distance, and covariance projection. If you implement probability of collision, state the assumptions behind the probability model and handle ill-conditioned covariance matrices explicitly.

Generate candidate maneuvers at several lead times, such as one orbit, six hours, twelve hours, and twenty-four hours before the conjunction. Evaluate impulses in the radial, along-track, and cross-track directions. An along-track maneuver often changes arrival timing efficiently, but your planner should calculate the outcome rather than relying on a slogan.

For each candidate, compute:

• Maneuver delta-v.
• Predicted post-maneuver miss distance.
• Estimated collision probability, if modeled.
• Perigee and apogee changes.
• Ground-contact or mission-geometry effects.
• Propellant cost.
• Recovery maneuver cost.
• Sensitivity to execution error.

Frame the optimizer as a constrained decision problem. Minimize delta-v or operational cost while enforcing a risk threshold, minimum perigee, maneuver lead-time requirement, and propulsion capability. Compare a grid search with a continuous optimizer. A grid search is less elegant but provides a useful sanity check and can expose local minima.

Your primary figure should be a Pareto-style plot of risk metric versus delta-v, with points colored by maneuver lead time and shaped by direction. Highlight the recommended maneuver and at least one rejected option. The caption should explain why the selected point is operationally preferable, not merely mathematically feasible.

Include execution uncertainty. Model errors in impulse magnitude, direction, and burn timing through Monte Carlo sampling or covariance mapping. A maneuver that succeeds only when executed perfectly is not a robust recommendation. Report the percentage of sampled outcomes that satisfy the risk and orbit constraints.

Post-maneuver screening is essential. The planner should repropagate the spacecraft and check whether the maneuver creates a new close approach with the original secondary object at a later time. A more advanced extension can screen against a small synthetic catalog. State clearly that operational collision avoidance requires authoritative tracking data, updated covariances, screening services, organizational rules, and human approval.

This project demonstrates the safety-oriented competencies relevant to an astrodynamics specialist career in 2026. It shows that you can move from physics to a defensible operational recommendation while acknowledging uncertainty and the limits of your simulation.

Validate the physics before polishing the graphics

A portfolio becomes credible through validation. Attractive visualization can make incorrect results look convincing, which is precisely why reviewers look for evidence that you tried to break your own model. Every project should contain a validation plan written before the final result is selected.

Use a hierarchy of checks. Begin with dimensional analysis and invariants, then compare against an analytical solution, another propagator, a published event, or a limiting case. Finally, test numerical sensitivity. No single comparison proves correctness, but several independent checks make hidden mistakes less likely.

For two-body propagation, monitor specific orbital energy and angular momentum. For a model containing conservative perturbations, explain which quantities should remain approximately conserved and which should evolve. With atmospheric drag or thrust, verify that the sign and order of the energy change are physically reasonable.

Frame transformations deserve dedicated tests. A state expressed in an Earth-fixed frame can appear to have a radically different velocity from the same state in an inertial frame. Add round-trip tests that transform a state from frame A to frame B and back. Specify whether velocities include frame rotation effects.

Time handling is equally important. Record UTC, TAI, TT, or TDB explicitly where relevant. Avoid converting every timestamp into an unlabelled Python datetime. Leap seconds, ephemeris time, and Earth orientation data can matter when comparing results across tools.

For numerical propagators, publish a convergence table. Vary absolute tolerance, relative tolerance, integration method, and maximum step. Track a mission-relevant output such as encounter B-plane coordinates, final position, minimum separation, or terminal error. A solver is adequately configured when additional numerical effort no longer changes the engineering conclusion materially.

For optimizers, distinguish feasibility from optimality. A converged status code does not prove that constraints are satisfied or that the result is globally optimal. Recompute constraints independently, run multiple initial guesses, perturb the solution, and compare with a simple baseline.

For estimation projects, validate covariance behavior as well as state error. Confirm symmetry, inspect eigenvalues, and monitor normalized residuals. If you repair a covariance matrix by clipping negative eigenvalues or adding diagonal jitter, log the event and explain why it occurred.

Automated tests should cover more than utility functions. Create scenario-level regression tests with stored tolerances. Examples include a known Keplerian period, a zero-thrust propagation, a zero-deployment case where relative states remain identical, and a collision planner case in which no maneuver should be recommended.

Avoid tolerances so loose that any result passes. At the same time, do not require bit-for-bit equality from floating-point integrations across operating systems. Document whether a tolerance is based on machine precision, integration accuracy, measurement noise, or a mission requirement.

A useful validation matrix has four columns: claim, verification method, acceptance threshold, and result. This compact artifact tells a reviewer exactly what you believe your software can do. It also gives you a disciplined response when an interviewer asks how you know a trajectory or estimate is correct.

Show software engineering, not only astrodynamics equations

Space organizations need analysis that can be maintained, reviewed, rerun, and integrated. Your portfolio should therefore demonstrate ordinary software engineering at an unusually high standard. The more consequential the calculation, the less acceptable an undocumented notebook becomes.

Separate domain logic from presentation. Propagators, measurement models, optimizers, and frame utilities belong in importable modules. Notebooks should orchestrate experiments and explain results, not contain the only working implementation. This lets you test the actual production logic and reuse it in command-line workflows.

Define interfaces around concepts such as state, epoch, frame, force model, observation, covariance, and maneuver. Do not pass anonymous arrays everywhere. If a function receives a six-element vector, its documentation should state the component order, frame, units, and epoch requirements.

Use static typing where it improves clarity. Python type hints, Java interfaces, data classes, and schema validation can catch integration mistakes before a long propagation begins. Unit-aware quantities are particularly valuable in astrodynamics because kilometer-versus-meter and degree-versus-radian errors can produce plausible-looking but invalid results.

Configuration files should be validated before execution. Reject a negative spacecraft mass, a non-normalized maneuver direction, an arrival epoch before departure, or a covariance matrix with the wrong dimensions. Error messages should identify the parameter and expected condition.

Build a small continuous integration workflow. On each commit, install the pinned dependencies, run unit tests, execute fast regression cases, check formatting, and optionally build the documentation. Do not run a two-hour trajectory optimization on every pull request. Keep a reduced deterministic case for continuous integration and run expensive studies through a separate workflow.

Track provenance for every result. Save the Git commit hash, configuration file, dependency lock file, execution timestamp, and data version with the output. If a figure changes after a code update, you should be able to identify why.

Logs should capture solver settings and warnings. Record integration failures, rejected optimizer steps, covariance repairs, missing environmental data, and extrapolation beyond an input product's intended interval. Silent fallbacks are dangerous because they make a failed analysis appear successful.

Include a license and a data-use note. Do not commit restricted ephemerides, proprietary conjunction data, export-controlled material, or employer-owned code. Public portfolio work should use open data, synthetic scenarios, or assets you have explicit permission to redistribute.

Finally, measure performance where it matters. Profile propagation loops, Monte Carlo runs, and repeated coordinate transformations before attempting optimization. If you parallelize a simulation, verify thread-safety and deterministic seeding. Orekit documentation, for example, notes that a single propagator instance should not be called concurrently, although independent propagators can be coordinated for parallel work. (orekit.org)

A hiring team should leave your repository believing that your calculations can survive beyond the demonstration. Clean abstractions, automated tests, data provenance, and honest error handling communicate that maturity more effectively than an unnecessarily elaborate user interface.

Present each project with one figure and one methodology note

Portfolio presentation should reduce the effort required to evaluate your engineering judgment. The ideal project can be understood at three levels: a thirty-second visual scan, a five-minute README review, and a deep technical inspection. Design the repository deliberately for those three reading modes.

At the top of each README, place the project title and a two-sentence mission statement. Follow it with the primary figure and a short result box containing three to five quantitative outputs. For the CubeSat planner, that might include pre-maneuver miss distance, selected lead time, maneuver magnitude, post-maneuver risk metric, and robustness under execution errors.

The primary figure needs a claim-oriented title. Avoid generic titles such as Trajectory Plot or Simulation Results. Prefer titles such as J2 and drag reverse the predicted deployment ordering after four days or A 12-hour lead-time maneuver meets the risk constraint with lower recovery cost.

Every figure should include units, readable labels, a legend that does not obscure data, and a caption that interprets the result. State whether curves represent nominal values, estimates, Monte Carlo percentiles, or reference data. If a plot uses normalized or nondimensional quantities, define them.

Keep visual style consistent across projects. Use the same typography, color hierarchy, line weights, and export dimensions. Save publication-quality SVG or PDF files when possible, plus PNG versions that render directly on GitHub. Check accessibility by avoiding color combinations that become indistinguishable under common color-vision deficiencies.

The methodology note should answer six questions:

1. What engineering question was solved?
2. What assumptions define the scenario?
3. Which equations, models, and software components were used?
4. How was the solution computed?
5. How was it validated?
6. What prevents the result from being used operationally without further work?

End the note with a limitations and next-steps section. Good limitations are specific. Saying that the model could be more accurate is weak. Saying that the drag study uses a simplified density model, fixed drag coefficient, nominal attitude, and no space-weather uncertainty tells a reviewer exactly what should be improved.

Include a short decision log for major modeling choices. Explain why you used numerical propagation instead of SGP4, why you selected a particular state representation, or why a direct transcription method was preferable to a shooting method for the low-thrust project. Engineering decisions are often more revealing than final values.

Create a release for the version featured in your resume. Attach the methodology document, key configuration, figures, and result files. Link the release rather than the moving main branch when submitting an application, so later experimentation does not change the evidence the employer reviews.

This presentation discipline resembles the approach used when building a portfolio during an internship: convert activity into evidence, make your contribution visible, and connect technical output to a real decision. The difference in astrodynamics is that assumptions, frames, time systems, and numerical tolerances require unusually explicit documentation.

Compound your credibility through open-source contributions

A polished personal repository shows what you can build alone. A useful contribution to Orekit or poliastro shows that you can work inside an established scientific software project, follow contribution rules, respond to review, and improve code used by other people. Even a small contribution can compound the value of the five portfolio projects.

Do not begin by proposing a new propagator. Start by using the library seriously enough to discover a genuine documentation gap, reproducible defect, missing test, confusing error, or incomplete example. Search existing issues and discussions before opening a report. A high-quality bug report is itself an engineering artifact.

A useful issue contains:

• The exact software and runtime versions.
• A minimal reproducible example.
• Expected and observed behavior.
• Units, frames, epochs, and test data.
• The full exception or numerical discrepancy.
• Evidence that the behavior persists in a supported version.
• A proposed test or documentation clarification.

Orekit accepts participation through discussions, bug reports, documentation improvements, tutorials, and source-code changes. Its contribution process emphasizes repository workflow, code quality checks, tests, documented changes, and review through merge requests. (orekit.org)

poliastro similarly welcomes issue reports, documentation work, research scripts, tests, bug fixes, and features. Its published contribution guidance directs contributors toward isolated branches, development environments, automated checks, and pull requests. (docs.poliastro.space)

Good first contributions can emerge naturally from your projects. You might improve an example involving perturbation propagation, add a regression test for a unit-related edge case, clarify an event detector's frame assumptions, or contribute a small educational script. Keep the scope narrow enough that reviewers can assess it quickly.

Treat review comments as part of the portfolio. Respond professionally, ask concise questions, update tests, and explain design changes. Do not argue from the fact that your code worked in one notebook. Maintainers care about API stability, maintainability, numerical correctness, documentation, and behavior across supported environments.

Once a contribution is accepted, add a short open-source section to your portfolio homepage. Link the issue and merged change, summarize the problem, and state what you learned. Do not exaggerate a documentation correction into a core-library engineering role. Precision builds more trust than inflated language.

Contributions also expose you to engineering concerns that personal projects can avoid: backward compatibility, licensing, continuous integration, review etiquette, release branches, and diverse user environments. Those lessons transfer directly to professional flight dynamics teams.

If a contribution is not accepted, it can still be valuable when handled well. Document the technical discussion, the reason for rejection, and how you revised your local project. Open source is not a badge-collection exercise. Its portfolio value comes from demonstrating that your work can withstand independent scrutiny.

Turn the five projects into a focused application narrative

Five sophisticated repositories can still produce a weak application if the candidate presents them as unrelated coursework. Your resume, portfolio homepage, and interview responses should connect the projects into one engineering narrative: mission design, propagation, estimation, and operational decision support.

Create a portfolio index with one card per project. Each card should contain the mission question, tool stack, primary figure, one quantitative result, and a link to the tagged release. Order the projects according to the job rather than chronologically.

For an interplanetary mission-design role, lead with Cassini and the low-thrust Earth-to-Mars transfer. For a satellite-operations role, lead with orbit determination, deployment analysis, and collision avoidance. For a software-heavy astrodynamics position, emphasize Orekit, automated testing, API design, and open-source contributions.

Resume bullets should describe actions and engineering outputs. A strong structure is:

• Built a GMAT mission sequence recreating Cassini's VVEJGA encounter order, then validated encounter epochs and analyzed B-plane sensitivity.
• Implemented an Orekit deployment simulator with configurable gravity and drag models, event detection, regression tests, and uncertainty sweeps.
• Developed a constrained low-thrust Earth-to-Mars optimizer with independent forward propagation and multi-start convergence analysis.
• Created an extended Kalman filter pipeline for TLE-derived pseudo-measurements, including innovation diagnostics and held-out prediction tests.
• Designed a CubeSat collision-avoidance trade study covering lead time, delta-v, risk reduction, execution error, and recovery cost.

Replace general claims such as improved accuracy with measured results from your own experiments. Do not fabricate mission-scale impact or imply that a synthetic study protected a real spacecraft. Employers value candidates who state evidence and boundaries accurately.

Prepare a five-minute explanation for each project. Use the sequence of problem, model, implementation, validation, result, and limitation. Then prepare for deeper questions about assumptions. You should be able to derive the major equations, explain the chosen reference frames, discuss solver failure modes, and identify the next fidelity improvement.

A practical build schedule can span roughly sixteen weeks:

1. Weeks 1-3: repository template and Cassini reconstruction.
2. Weeks 4-6: Orekit deployment simulator.
3. Weeks 7-10: low-thrust transfer and optimization experiments.
4. Weeks 11-13: orbit determination pipeline.
5. Weeks 14-15: collision-avoidance planner.
6. Week 16: documentation, releases, portfolio index, and application materials.

Adjust the schedule to your background. Someone new to astrodynamics may need more time for frames, time systems, perturbations, and estimation fundamentals. It is better to publish three deeply validated projects than five partially working demonstrations. The complete five-project sequence should be the destination, not an excuse to rush.

Refonte Learning approaches portfolio development as applied engineering rather than passive content consumption. That means producing artifacts that can be reviewed: scripts, tests, configuration files, figures, methodology notes, and defensible conclusions. The same standard should guide independent candidates, university students, and experienced software engineers transitioning into spaceflight dynamics.

Your final portfolio should not claim that you are already a mission authority. It should prove that you can learn complex tools, reason from first principles, respect uncertainty, and communicate technical decisions. In 2026, that combination is what turns GMAT, Orekit, and poliastro projects from educational exercises into credible evidence for an orbital mechanics engineering role.