Gmat Api
Gmat Api
net/publication/344074686
CITATIONS READS
0 2,450
2 authors, including:
Darrel Conway
Thinking Systems, Inc.
17 PUBLICATIONS 58 CITATIONS
SEE PROFILE
All content following this page was uploaded by Darrel Conway on 03 September 2020.
Darrel J. Conway*
John McGreevy†
* Senior Scientist and CEO, Thinking Systems, Inc., 437 W Thurber Rd, Suite 6, Tucson, AZ 85705.
†
Aerospace Engineer, Emergent Space Technologies, Inc., 7901 Sandy Spring Road, Suite 511, Laurel, MD 20707.
1
INTRODUCTION
NASA’s General Mission Analysis Tool (GMAT) is a mature astrodynamics tool used for mission
analysis and design, planning, and operations.1 The GMAT system contains components used to
plan and optimize maneuvers, perform orbit estimation, and generate output used to monitor space-
craft on orbit. The GMAT code base contains all of the elements needed to support these capabilities
either from a graphical user interface (GUI) or from a text based console application. GMAT users
can add custom capabilities through a plug-in system designed to allow extension of GMAT for new
mission needs. Recent improvements to the system extend this plug-in system to include additions
to the GMAT GUI.
GMAT’s capabilities are fully contained and accessible through the GMAT GUI and console
front ends. Users of the system began asking for access to GMAT’s tested components from exter-
nal tools several years ago. In response, the GMAT team prototyped approaches to address these
user requests, resulting in a ”C-Interface” plugin with extremely limited capabilities and a study
of available tools that could be used to make GMAT’s components accessible to other systems.2
The recommendations of the latter study were then used to build a replacement for the C-Interface
code in the Orbit Determination Toolbox (ODTBX) project at GSFC, validating the recommended
approach.3 These early efforts to make an Application Programming Interface (API) provided a
set of preliminary requirements and potential implementation options for a system API. The API
study and subsequent ODTBX experiment identified the Simplified Wrapper and Interface Gen-
erator (SWIG)4 as a toolset that could generate the desired API functions from the GMAT code
base.
In late 2018 work on a production GMAT API started with the goals of providing access to most
of the core GMAT system for users working in MATLAB and Python, with the eventual goal of
making these components available both as a toolkit and as an avenue for interoperability between
GMAT and other astrodynamics tools. The R2020a release of GMAT5 includes this capability in
beta form, along with user documentation and sample use cases for the system. In this paper, we
describe this work and use existing examples to illustrate current functionality of the GMAT API.
We conclude by describing the ongoing development of the system.
Design Goals
GMAT’s API user base includes mission analysts working at NASA GSFC and their contractors.
These users are familiar with GMAT and have had exposure to the earlier GMAT API prototypes.
Given this user experience, the API developers surveyed this user community at the start of the
API development process in order to identify the most useful feature set for early builds of the
API, and to identify the target API platforms and features. The resulting feature set was broken
into four categories: style of usage (identified through use cases), application frameworks used to
call the API, ease of use features, and near term needs. The high level requirements identified are
summarized below.
– GMAT API users need to be able to load a script, edit scripted parameters, run the script
using the edited data, and retrieve the resulting data.
– Mission analysts need an easy-to-use toolbox of validated astrodynamics components.
2
– Programmers and ”power users” need the ability to interact at a detailed level with
objects built from GMAT classes
• The GMAT API can be called from the following tools and application frameworks
– Python
– Java
– MATLAB
– C++
– API users need to be able to use the API without detailed knowledge of GMAT code
– The API must be documented to simplify use
– The API must have online access to help, including interactive access to the available
object settings
• The initial builds of the GMAT API will satisfy the following near term needs
– The API will provide access to GMAT’s time system, coordinate system, and state rep-
resentation conversion utilities
– The API will provide access to GMAT’s dynamics modeling and propagation compo-
nents
* GMAT Dynamics models must be accessible
* Propagation should be available for GMAT’s propagators
– Measurement models must be accessible from GMAT’s Estimation Plugin
The R2020a release of GMAT includes a build of the GMAT API that satisfies all of these re-
quirements. The API included in GMAT R2020a is considered beta quality while testing continues
on the system.
API Development
Working from the results of the earlier API exploration and the identified needs of the user com-
munity at GSFC, we began implementation of the SWIG based GMAT API in the fourth quarter
of 2018. The resulting API supports general purpose exposure of the core GMAT system, demon-
strated through a use case that provides the following functions and features:
• Component access
3
• Script manipulation and use
• Interactive help
The goal of the API development is to meet the needs of identified users. In support of this goal,
the development team scheduled periodic demonstrations of the system. The core functionality
identified above was demonstrated in May 2019 and refined over the course of the year. The system,
including more than 80 pages of user documentation and example implementations of the use case
features, was ready for release in October 2019 and was included in the next formal GMAT release,
GMAT R2020a. The remainder of this paper focuses on the contents of this release.
Funding for the GMAT API is provided by the NASA Engineering and Safety Center as part of
an effort to make several NASA tools operate together. Now that the core API feature set is in place,
the development team is using the API to help the GMAT system work with other NASA developed
tools, including the Monte system from JPL. We provide a brief description of that work as well.
COMPONENT ACCESS
GMAT is built on an object model documented at a high level in its Architectural Specification6
and in detail in files generated using the Doxygen7 documentation generation tool. The code is
written in standard C++. The wrappers for the GMAT code use SWIG to generate the Python and
Java interface files used by the API. Direct low level access to GMAT’s objects can be made through
these interfaces by experts in the system. That access was used for the early API experiments
described above.
One goal of the GMAT API project is to simplify the learning curve for access to GMAT’s ca-
pabilities. With that goal in mind, the development team added API specific functions to simplify
system configuration, and customized select portions of the SWIG wrapper code to make the system
easier to use. Table 1 lists some of these functions.
The team also added new elements to the GMAT code that simplify user access to GMAT’s
components, and to the settings on those components.
Running Interactively
GMAT runs scripts in a two-step process. The first step parses a script file and translates the file
into a set of individual objects that are stored in an in-memory database of objects and a linked list
of actions defining a mission time line. When the user tells GMAT to run the script, the second step
4
Table 2. GMAT Class Extensions for the API
Method Purpose
Help Retrieves help for an object
SetField Sets a field on an object
GetField Retrieves the setting for a field as a string
GetNumber Retrieves the value of a numerical field‘
is applied: the objects from the configuration database are copied into a local sandbox, and the steps
defined in the mission time line are applied sequentially to the copied objects.
API users that work with the GMAT components have a different work flow. They construct
objects from their native application framework and then manipulate those objects directly. This
work flow can be scripted in the framework’s language. Two examples of that process – propagation
and measurement modeling – are described below. Users can also run the GMAT API in console
applications provided by the application framework. This approach lets a user explore GMAT’s
capabilities interactively and try actions to see what happens while writing a more scripted piece of
analysis.
As an example, consider a user that needs the Earth-fixed representation of a mean-of-J2000 state.
Using the API, the user can execute the steps shown in Listing 1.
This session shows the basic steps a user follows for the conversion in the Python interpreter.
After launching the interpreter and loading the GMAT API, the user enters the epoch and inertial
state data, and sets up a container for the fixed state. Next they create the coordinate systems
and converter necessary for the coordinate transformation. The call to initialize the system connects
these objects to underlying GMAT components, including the Earth object needed for the coordinate
system computations. Finally, the converter is called to perform the coordinate system conversion,
5
and the result is displayed to the user.
The GMAT API provides direct access to GMAT force modeling and propagation for MATLAB
and Python users. Working in interactive mode, a user can experiment with force model configura-
tion directly and view the results using the help system. For example, the configuration of a force
model to use a 4x4 Earth geopotential can be built interactively, as shown in listing 2.
GravityField EarthGrav
Degree Integer 4
Order Integer 4
StmLimit Integer 100
PotentialFile Filename JGM2.cof
TideFile Filename
TideModel String None
>>> fm.AddForce(earthgrav)
Once the user has their force model configuration determined, the API calls needed can be placed
in a script file that can then be imported for further use. The integrator configuration shown in
Listing 3 uses such a configuration, imported from the file BasicFM.py.
In GMAT, a numerical propagator consists of a force model and integrator collected together in
a Propagator container. The Propagator collects together all of the pieces needed for propagation:
a spacecraft, force model, and integrator, and manages the connections between these pieces. Then
when the components are initialized, the links between these pieces are set. For propagation, a fur-
ther initialization is performed using the PrepareInternals method, which sets up internal structures
and the state vector used in propagation. The listing shows the full configuration needed.
6
# Build the propagation container
pdprop = gmat.Construct("Propagator","PDProp")
The code shown here is part of the GMAT R2020a release. The force model configuration
is in the Ex R2020a BasicFM.py file in the api folder, and the propagation is demonstrated in
Ex R2020a PropagationStep.py. Matching MATLAB .m files are also included in the release pack-
age.
Part of GMAT’s capabilities as an orbit determination tool includes the ability to simulate mea-
surements. The types of measurements GMAT supports, as of R2020a, include range, range rate,
and angle types. GMAT also provides the ability to add various corrections to the simulated mea-
surement values, including corrections due to light-time delays, ionospheric and tropospheric de-
lays, and relativistic effects, among others. The ability to simulate measurements with or without
these corrections is exposed in the API.
Ex R2020a RangeMeasurement.m is an example MATLAB API script contained in the R2020a
release where range and range rate measurements are configured completely through the GMAT
API, then are calculated for a ground station station and spacecraft pair. The range measurement
obtained from GMAT is then validated with the two way range calculated in MATLAB from the po-
sition vectors of the ground station and the spacecraft. The script also provides the syntax for adding
either ionosphere or troposphere delay modeling on the ground station, or corrections for light-time
delay and the effects of general relativity on the signal, though these are either commented out or
not enabled by default in the example script. Figure 1 shows this example running in MATLAB.
While the above mentioned example constructs all the resources using the API, it is also possible
to instead configure some or all of the resources in a GMAT script. If set up that way, the GMAT
script is loaded and initialized through the API, which allows an API user to use a preexisting script
they may already have that they want to reuse through the API.
7
Figure 1. Calculating Range in MATLAB
GMAT is a script based application. Users configure the system using a custom scripting lan-
guage, or using panels on GMAT’s graphical user interface that interact with underlying objects
through GMAT’s script interfaces. When GMAT loads a script, the application builds a database
of objects in memory that match the scripted settings. Running the script takes these pristine ob-
jects, makes copies of them, and then performs operations on these copies, generating output files
and other analysis data based on the instructions in the user’s script. The GMAT application tracks
progress through the system in a log file that records the status of the run as it progresses.
Users familiar with GMAT’s scripting language requested that the API provide the ability to
load GMAT scripts, change input settings, and run the script with the changed values. The script
manipulation capabilities are provided through a few API specific commands, along with the object
access capabilities described above. The GMAT log file location is also provided through an API
call.
A user that wants to run a script in the API and then view the results needs to access the object
used in the run rather than the original object built from the script. The API provides a function
specific to that feature of GMAT runs using another API function, GetRuntimeObject().
The script manipulation capabilities are best illustrated through a few examples. The Python
listing below shows a very basic application of the script access functions in the GMAT API.
8
gmat.RunScript()
The script identified here, “ToLuna.script,” is a basic launch-coast-burn script that starts with a
spacecraft in a low-Earth parking orbit from a launch vehicle. The spacecraft propagates (coasts)
for a set time, applies an impulsive maneuver (burn), and then propagates to one of three conditions:
apogee, perilune, or eight days of propagation. The first stopping condition encountered stops the
propagation.
This Python scripting performs the same function as running the script in GMAT, and then writes
the resulting spacecraft-Moon separation distance to the terminal running the script:
$ python3 RunToLuna.py
228234.63471634657
This example shows the basic approach to running GMAT scripts using the API.
The API’s script driving capabilities enable a variety of run time capabilities ranging from pa-
rameter scans through Monte-Carlo analysis.
The three variables for the scan are the launch insertion state epoch, controlled with the StartEpoch
variable, the coast time, controlled using the LeoTime variable, and the maneuver delta-V, set with
the Element1 field on the TOI maneuver object. The lunar encounter distance is evaluated at the end
of the last propagation. The API can be used to scan through various values of these three settings,
and the best case values stored for display and later use. The pertinent portion of the API driving
9
code for this scan is shown in listing 6.
for i in range(10) :
for j in range(20) :
for k in range(25) :
StartEpoch = k / 2.0
start.SetRealParameter("Value", StartEpoch / 24.0)
Time.SetRealParameter("Value", 1500.0 + i * 100.0)
burn.SetRealParameter("Element1", 3.0 + j * 0.01)
The full parameter scan uses the settings in this listing to scan through the three search parame-
ters, reporting the resulting parameter values and lunar encounter distance whenever the encounter
distance is smaller than the previous closest approach value. Once the scan has completed, the
script writes the results and generates a GMAT script that, when run, has the best case solution in
the script. The output from the run (abbreviated for the purposes of this paper) shows the scans as
they find the closest lunar approach:
$ python3 Ex_R2020a_FindTheMoon.py
The GMAT R2020a release package includes the GMAT script and drivers described here, in the
api folder of the build. The script is the file Ex R2020a ToLuna.script, the Python driver for the
parametric scan is Ex R2020a FindTheMoon.py. The release also includes a matching MATLAB
driver, Ex R2020a FindTheMoon.m.
The API can also be used to perform a Monte-Carlo analysis based on an existing GMAT script.
After first using the API to load a GMAT script into GMAT’s sandbox, the API can then be used
to modify specific values in the sandbox according to the desired probability distribution(s), and
then the API can run the modified mission in GMAT. Because the modified mission is still being
executed by GMAT, the API is still running a fully-featured GMAT mission, including any targeters,
10
optimizers, and reporting tools in the script, including resources and commands that have not yet
been exposed through the API.
MonteCarloAPI.m8 is an example in MATLAB of the GMAT API being used to perform a Monte-
Carlo simulation on a single finite burn in low earth orbit. The parameters that are varied in this
example are the initial epoch and duration of the burn, along with its magnitude. First, a GMAT
script, MonteCarloAPI.script, with the nominal maneuver is configured. This GMAT script prepares
the spacecraft, the force model and propagator, the maneuver properties, and the output report file.
The nominal mission sequence is also defined in the script, consisting of propagation to the start of
the maneuver, during the maneuver, and for a period of time after the maneuver.
Figure 2. MATLAB Script Using the GMAT API for Monte-Carlo Analysis
Through the API, the above mentioned parameters for the maneuver are modified. For each
iteration, the start time and duration of the burn are set through GMAT variables named Start-
Time and BurnTime, respectively, and the thrust magnitude is set through the ’C1’ field on Chem-
icalThruster1. The values used to set these fields come from random sampling using MATLAB’s
random number generator. The file name the ReportFile writes to is also set through the API, using
a uniquely numbered file name for each iteration. Finally, the modified script is run through the
RunMission() function, where GMAT executes the script with the values for the current iteration,
and the output files are generated according to the GMAT script. Figure 2 shows the portion of the
MATLAB script responsible for setting these values and running the GMAT script through the API.
The output files can them be analyzed after the run is complete, either with another utility, or loaded
back into MATLAB, and analyzed in the same script that operated the GMAT API.
11
TUTORIAL DEVELOPMENT
The GMAT API lends itself to the creation of tutorials and walkthrough demonstrations using
the Python Jupyter notebook system. Figure 3 shows one of the notebooks included in the GMAT
release. This notebook lets a user walk through the process of configuring and running the propa-
gation setup described earlier. A second notebook in the release shows how states are managed in
GMAT, a topic that confused some users.
The spacecraft panel in the GMAT GUI provides a framework accessing GMAT capabilities for
conversions and data manipulation, but the process of using that capability is somewhat cumber-
some, requiring that a user launch GMAT and understand how to access those features of the sys-
12
tem. The API provides a mechanism for producing a more lightweight, customized user interface
into GMAT’s code. One example is shown in Figure 4.
The time conversion GUI9 shown in the figure is written in PyQt. It was built to facilitate com-
parisons of epochs for some testing performed by a GMAT developer that needed a quick way to
examine reported epochs.
nt = numel(t);
for tIndex=1:nt
% Get derivatives
fm.GetDerivatives(x(:,tIndex), t(tIndex), 1); % Calculate derivatives
13
deriv = fm.GetDerivativeArray(); % Get calculated derivatives
xDot(:,tIndex) = deriv(1:6);
ACKNOWLEDGMENTS
The GMAT Application Programming Interface development work is funded through the NASA
Engineering and Safety Center. Goddard Space Flight Center manages the work. The authors are
grateful for the support of these organizations.
REFERENCES
[1] The GMAT Development Team, GMAT Wiki, 2020. https://gmat.atlassian.net/wiki.
[2] D. J. Conway, “GMAT API Tradeoff Study,” 2012.
[3] D. J. Conway, “GMAT API Consultation Support,” 2016.
[4] The SWIG Development Team, SWIG-4.0 Documentation, 2019. http://www.swig.org/.
[5] The GMAT Development Team, GMAT: The General Mission Analysis Tool, 2020. https://
sourceforge.net/projects/gmat/.
[6] The GMAT Development Team, General Mission Analysis Tool (GMAT) Architectural Specification,
2020.
[7] D. van Heesch, Doxygen, 2020. https://www.doxygen.nl/.
[8] J. McGreevy, “GMAT API Monte Carlo Example,” Available upon request, 2020.
[9] D. J. Conway, “GMAT API Time Conversion Tool,” Available for download: www.thinksysinc.
com/gmatapi/EpochConverter.zip, 2020.
[10] The ODTBX Development Team, ODTBX: The Orbit Determination Toolbox, 2020. https://
sourceforge.net/projects/odtbx/.
14