FRAC-10 Script LanguageFeature Spec and Test Procedures

FRAC
-
10 Script Language

Feature Spec and Test Procedures

Lead: Joel

Developer: Linda

Tester: Tom


Explore

Known Bugs

Failing Tests

Other Findings

Requirements

FRAC
-
2

FRAC
-
10 (new)

Interface/Functional Spe
c

Overview

Script Structure

Initialization

Mission Sequence

Basic Synta
x

Source Text

Line Termination

White Space

Comments

File Paths

Data Types

Literals

Integers

Real Numbers

Strings

Booleans

Enumerated Values

References

Resources

Resource Types

Naming Rules

Shadowing

Compound Types

Arrays of Literals

Arrays of References

Conversion

Keywords

Expressions

Relational Operators

Logical Operators

Logical Expressions

Statements

Statement Structure

The Create Statement

I
nitialization Statements

Command Statements

Compound Statements

Processing

Interpretation

Execution

Processing Errors

Test Procedures

Assumptions

Existing Tests

Recommended Additional Tests

Nominal Tests

Edge/Corner/Stress

Unique Validation

Unique Mode Tests

Unique GUI Tests


Explore

This section is final as of 11/08/2012. It is no longer being updated.

Known Bugs


JIRA ID

Summary

Rec.

GMT
-
356

GUI Is in Unstable State When Invalid Script is Loaded

P1

GMT
-
719

Pause and stop command

Fixed?

GMT
-
806

Add interpolation capability to report functionality

Improve
ment

GMT
-
1391

Some Variable Names Cause Problems When Configuring Resources

P2

GMT
-
1399

Math characters cannot
exist in strings in command mode

P1

GMT
-
1521

Numeric Values Surrounded by Single Quotes

P3

GMT
-
1559

Script editor pops up when building from resource tree

Improve
ment

GMT
-
1566

Some lines prefixed by "function" are ingored

Verify

GMT
-
2528

Empty Brackets Behavior Confusing

P1

GMT
-
2958

Create in command mode is warning, not error (and causes crash)

Verify

GMT
-
2801

Turn off command mode for selected objects

P1

GMT
-
3037

Multiple different error messages (some with developer messages) are
writing out for one error.

P3

GMT
-
3160

Space between minus sign and value in assignment mode won't parse

P1


Failing Tests

There are no failing tests as of 10/17/2012.

Other Findi
ngs


JIRA ID

Summary

Rec.

GMT
-
3233

GMAT prints “GMAT” prefix before every script line

倱

dMq
-
㌲㌴

dMAq
灲楮t猠獥mi捯c潮 獵ffix aft敲 敶敲e 獣si灴 li湥

倱

dMq
-
㌳㈹

䱯gi捡c klq

fmpr潶敭敮e

dMq
-
㌳㌰

Allow 灡r敮
t桥獥猠楮 l潧i捡c 數灲敳獩潮s

fmpr潶敭敮e


Requirements

FRAC
-
2


ID

Requirements

FRAC
-
2.1

The system must configure and execute a mission sequence through a
graphical user interface (GUI) described in FRAC
-
4.

FRAC
-
2.2

The system must configure and
execute a mission sequence through a
predefined scripting language defined in FRAC
-
10.

FRAC
-
2.3

The system shall be available in both console and GUI form.

FRAC
-
2.4.0

The console version shall have all of the capability of the GUI version with
the
following exceptions:

FRAC
-
2.4.1

1)

XY Plots

FRAC
-
2.4.2

2)

Orbit View

FRAC
-
2.4.3

3)

GUI Interface

FRAC
-
2.4.4

4)

Ground Track Plot

FRAC
-
2.5

The system shall optionally show the script snippet for Resources and
Commands configured via the GUI.

FRAC
-
2.6.0

The system shall allow the user to specify the following data file locations

FRAC
-
2.6.1

1)

Report files

FRAC
-
2.6.2

2)

Tracking data files

FRAC
-
2.6.3

3)

Log file

FRAC
-
2.6.4

4)

GMAT functions

FRAC
-
2.6.5

5)

MATLAB functions

FRAC
-
2.6.6

6)

DE405 ephemeris file

FRAC
-
2.6.7

7)

Leap second file

FRAC
-
2.6.8

8)

Earth orientation file

FRAC
-
2.6.9

9)

Nutation data file

FRAC
-
2.6.10

10) Planetary potential files.

FRAC
-
2.6.11

11) SPK ephemeris files

FRAC
-
2.7

The system
shall allow the user to provide an external plug
-
in for a user
-
defined resource or command.


FRAC
-
10 (new)


To Reviewers: These requirements are written based on what the user needs from the language.
Implementation and design details (name of commands,
specific characters, etc.) are not listed
as requirements.


ID

Requirements

FRAC
-
10.1

The system shall support a text
-
based script language that allows for the
configuration and execution of a mission sequence.

FRAC
-
10.2

The script language shall
support the creation and configuration of any
resource defined by FRR
-
1
–
㐲4

䙒AC
-
㄰.P

q桥 獣sipt l慮g畡g攠獨sll 獵s灯rt t桥 捯cfig畲uti潮 慮搠數散eti潮 of 慮y
捯浭慮d 摥fi湥d 批 䙒C
-
N
–
㈴O

䙒AC
-
㄰.㐮4

q桥 獣sipt l慮g畡g攠獨sll 摥fi湥 tw漠o潤敳 of 潰敲慴io
渺

䙒AC
-
㄰.㐮4

ㄮN f湩ti慬iz慴楯測ni渠n桩捨⁲敳eur捥c 慲a 捲敡t敤 慮搠楮iti慬iz敤

䙒AC
-
㄰.㐮4

㈮O Mi獳s潮 C潮tr潬 p敱略湣nI i渠n桩捨⁴桥 獥qu敮捥f 捯mm慮摳 i猠
摥fi湥搠for t桥 mi獳s潮

䙒AC
-
㄰.R

q桥 獣sipt l慮g畡g攠獨sll 扥 捯m灯獥s of 捨cra捴敲猠
from t桥 T
-
扩t rp
-
ApCff 捨cr慣瑥r 獥s.

䙒AC
-
㄰.S

q桥 獣sipt l慮g畡g攠獨sll 獵s灯rt fr敥
-
form 捯mm敮t献

䙒AC
-
㄰.㜮T

q桥 獣sipt l慮g畡g攠獨sll 獵s灯rt t桥 f潬l潷i湧 lit敲慬 摡ta ty灥猺

䙒AC
-
㄰.㜮T

ㄮN o敡l 湵m扥r

䙒AC
-
㄰.㜮T

㈮O ptri湧

䙒AC
-
㄰.㜮T

P
. B潯l敡n

䙒AC
-
㄰.㜮T

㐮4 Arr慹猠of liter慬s

䙒AC
-
㄰.㜮T

㔮R Arr慹猠of r敳eur捥r fi敬搠refer敮捥c

䙒AC
-
㄰.U

q桥 獣sipt l慮g畡g攠獨sll req畩re t桥 捲敡ti潮 of 慬l 湯n
-
摥f慵lt re獯sr捥c
扥f潲o 畳u.

??

The script language shall be defined such
that it can be parsed by MATLAB
without error.


Interface/Functional Spec


Open Issue: We need to clarify what “{}” means when used with resources. See
dMq
-
㈵㈸
.


For Reviewers: I’m borrowing from other language specifications as examples:
C
Ⱐ
C⬫
Ⱐ
䌣
Ⱐ
a
Ⱐ
䝯
Ⱐ
䩡ga
Ⱐ
䩡g慓捲i灴
Ⱐ
lbj散瑩ee
-
C
Ⱐ
merl
Ⱐ
偈m
Ⱐ
myt桯n
Ⱐ
o畢y
Ⱐ
pni
Ⱐ
si獵sl B慳ac


Overview

The GMAT script language

Script Structure

A GMAT script is a text file consisting of valid script syntax elements, such as initialization
statements, Mission Sequence commands, and comments. These syntax elements are described
lat
er in this specification.


At the highest level, a GMAT script is made up of two sections: Initialization and the Mission
Sequence. These sections each contain statements, but they have different rules about which
sorts of statements are valid. The
BeginMi
ssionSequence

command defines the beginning of the
Mission Sequence section.



Initialization

The first section in a script file, referred to as Initialization, is responsible for creating resources and
setting their initial state. The Initialization
section can contain the following types of statements:

●

resource creation statements (the
Create

statement)

●

initialization statements


Only literal assignments are allowed in this section; no execution of commands or evaluation of
parameters is done. In the

GUI, the Initialization section maps directly to the Resources tree. All
resources created, and all fields set, in this section appear as resources in the GUI when the script
is loaded.

Mission Sequence

The Mission Sequence section contains the Mission Se
quence, or the list of GMAT commands that
are executed sequentially when the mission is run. The Mission Sequence section can contain the
following types of statements:

●

command statements


The Mission Sequence begins at the first instance of the
BeginMissi
onSequence

command;
therefore, this must be the first command statement in the script file. For backwards compatibility, if
the
BeginMissionSequence

command is missing, the Mission Sequence begins with the first
command encountered.


In the GUI, the Missio
n Sequence section maps directly to the Mission tree. Each statement in the
script (with the exception of the
BeginScript
/
EndScript

compound command) is displayed as a
single element in the tree.

Basic Syntax

Source Text

A GMAT script consists of a single
file containing characters from the 7
-
bit US
-
ASCII character set.
The script language is case
-
sensitive, so this line creates four different Variable resources:

Create Variable x X y Y


The script language is made up of lines. A line can be:

●

empty

●

a commen
t (see Comments, below)

●

a statement (see Statements)

Statement lines can be split over multiple physical lines with the continuation marker (“
...
”).

Line Termination


For GUI tester: We need to make sure the script editor preserves line endings through
different
kinds of edits. Does the script editor try to preserve mixed endings, or does it make them all
consistent? This section is written as if mixed endings are supported.


Script lines are terminated by any of the following ASCII character sequences:

●

line feed (hex:
0A
)

●

carriage return (hex:
0D
)

●

carriage return followed by line feed (hex:
0D0A
)

White Space

White space can appear above or below any line, before or after any statement within a line, and
many other places in a script. The following
characters are recognized as white space:

●

space (hex:
20
)

●

horizontal tab (hex:
09
)

Comments

Comments begin with the percent symbol (“
%
”, hex:
25
) and extend to the end of the line. There is
no multi
-
line or embedded comment in the script language.

File Pat
hs

Several resource types have fields that accept file paths as input. The general syntax of such
paths is common to the language, but some specific behavior is specified by each resource.


Forward slashes and backslashes can be used interchangeably within

GMAT, and can be mixed in
a single path. The following three paths are considered identical:

data/planetary_ephem/spk/de421.bsp

data
\
planetary_ephem
\
spk
\
de421.bsp

data
\
planetary_ephem/spk
\
de421.bsp


Absolute paths are passed to the underlying operating sy
stem as
-
is, aside from normalizing the
slashes.


Relative paths are considered relative to a location defined by each resource type separately, and
usually defined in the GMAT startup file. For details, see the reference documentation for each
resource typ
e.


File paths are written as string literals (see the String Literal section under Data Types). Quotes
are mandatory if the path contains spaces, but are optional otherwise.

Data Types

Literals

Integers

Integers are written as a sequence of literal digits
, with no decimal. Preceding zeros are allowed,
but scientific notation is not.

Real Numbers

Real numbers can be written in any of the following formats:

●

12

(whole number)

●

12.5

(decimal)

●

1.25e1

or
1.25e
-
1

(scientific notation)


In all formats, the base can

contain preceding or trailing zeros. In scientific notation, the exponent
can be prepended by a sign (
+

or
-
) and can contain preceding zeros, but cannot contain a
decimal. The exponent delimiter is case
-
insensitive (e.g. ‘
e
’ or ‘
E
’).

Strings

String liter
als are delimited by single
-
quote characters (“
'
”, hex: 27).


All language
-
supported characters are allowed in strings, with the exceptions below. There are no
escape characters or character substitute sequences (such as “
\
n
” for line feed).


In
Initialization, the following characters are not allowed in string literals:

●

some non
-
printable characters (NUL, SUB) (hex: 00, 1A)

●

line termination characters (LF, CR) (hex: 0A, 0D)

●

percent character (“
%
”) (hex: 25)


In the Mission Sequence, the following

characters are not allowed in string literals:

●

some non
-
printable characters (NUL, SUB) (hex: 00, 1A)

●

line termination characters (LF, CR) (hex: 0A, 0D)

●

percent character (“
%
”) (hex: 25)

●

brackets (“
(
“, “
)
”, “
[
“, “
]
”, “
{
“, “
}
”) (hex: 28, 29, 5B, 5D, 7B, 7D
)

●

semicolon (“
;
”) (hex: 3B)


Quotes are generally optional, but are mandatory in Initialization if the string contains whitespace,
any script language symbols, or any GMAT
-
recognized elements (e.g. keywords, resource
names). They are mandatory in the Missi
on Sequence in the same instances, and additionally if
the string contains mathematical operators and certain non
-
printable characters. We recommend
quoting all string literals.

Booleans

The following boolean values are supported:

●

true

(alias:
on
)

●

false

(a
lias:
off
)


Boolean literals are case
-
insensitive.

Enumerated Values

Many resource fields accept enumerated values. For example,
Spacecraft
.DateFormat

accepts
one of 10 values (
A1ModJulian
,
A1Gregorian
, etc.). Enumerated values are written as string
litera
ls. Quotes are always optional, as none contain spaces or special characters.

References

References to resources and resource parameters are indicated by the name of the resource or
resource parameter. References are written as string literals. Quotes are
always optional, as
resource names and parameters cannot contain spaces or special characters.

Resources

Resource Types

Resources in GMAT are instances of a base resource type that are given user
-
defined names and
store data independently of other resource
s of the same type. Resource types include
Spacecraft
,
GroundStation
, and
Variable
. They cannot be used directly; they must first be
instantiated with the
Create

statement. For example:

Create Spacecraft aSat


In the example,
Spacecraft

is the resource type and
aSat

is the resource. This is similar to the
concept of classes and objects in object
-
oriented programming, where GMAT’s resource types are
analogous to classes and its resources are analogous to objects.

Naming Rules

Resources mu
st be named according to these rules:

●

Name must be made up of ASCII letters, numbers, or the underscore character (“
_
”). This
corresponds to hex values 30
–
39, 41
–
5A, 5F, and 61
–
7A.

●

Name must begin with a letter (
A
–
Z

or
a
–
z
, hex: 41
–
5A or 61
–
7A)

●

Name cannot

be a reserved keyword or command name

Shadowing

When the same name is used for multiple purposes in a script, the shadowing rules apply to
determine how a reference to the name is interpreted.


Resource names must be unique within a script. If a script at
tempts to create multiple resources
that have the same case
-
sensitive name, the first
Create

statement in the script with that name is
executed and all subsequent ones are ignored. The conflict is noted in a warning message.


Command names and keywords are

reserved. They cannot be used as resource names. See the
Keywords section for a list of keywords.


Built
-
in function names (like
sin

or
cos
) can be used as resource names with one exception: a
reference to, for example, “
sin(1)
” on the right
-
hand side of
an equal sign will be interpreted as a
call to the
sin

built
-
in function, not element 1 of an
Array

resource named
sin
. The same is true
for the other built
-
in functions.


Resource type names (like “
Spacecraft
”) can be used as resource names. In such an in
stance,
the conflict is resolved by the context. For example:

Create Spacecraft Spacecraft

Create Spacecraft aSat


In the example, GMAT knows by context that in the second
Create

statement, the argument
“
Spacecraft
” refers to the resource type, not the
resource instance created in the first statement.

Compound Types

Arrays of Literals

Arrays of literals are accepted as input by some resources. Arrays of booleans, integers, and real
numbers are surrounded by square brackets (“
[
“ and “
]
”, hex: 5B and 5D).
Arrays of strings are
surrounded by curly brackets (“
{
“ and “
}
”, hex: 7B and 7D). In all cases, the values are separated
by whitespace or commas. Only one
-
dimensional arrays of literals are supported. See the following
examples.

anOrbitView.DrawObject = [t
rue true] % boolean array

anOrbitView.OrbitColor = [255 32768] % integer array

anOrbitView.ViewPointVector = [3e4, 1.2,
-
14] % real array

aSpacecraft.OrbitSpiceKernelName = {'file1.bsp', 'file2.bsp'} % string array


Arrays of R
eferences

Some resources accept arrays of references to other resources or resource fields. These
reference arrays are surrounded by curly brackets (“
{
“ and “
}
”, hex: 7B and 7D) and the values are
separated by whitespace or commas. Only one
-
dimensional arr
ays of references are supported.
The values can optionally be surrounded by single quotes. See the following example.

aForceModel.PointMasses = {'Luna', Mars} % array of resource references

aReport.Add = {Sat1.X, 'Sat1.Y', Sat1.Z} % array of paramete
r references


Conversion

In contexts that accept a real number, integer literals (those with no fractional value) are
automatically converted to the equivalent floating
-
point value upon execution.


There is no built
-
in conversion between string values and

numeric values, though such a
conversion may be implemented by individual commands.

Keywords

The script language recognized these reserved keywords:

●

Create

●

GMAT

●

function


In addition, all command names are reserved, including commands created by active pl
ugins.

Expressions

The only types of expressions common to multiple commands are logical expressions, which are
used by the
If
/
Else

and
While

commands. They are documented here instead of in both
command references.

Relational Operators

The following relat
ional operators are supported in logical expressions:


<

Less than

<=

Less than or equal to

>

Greater than

>=

Greater than or equal to

==

Equal to

~=

Not equal to


The relational operators are scalar operators; they do not operate on Array resources
(only
individual elements).


Each relational operator operates on the values of its arguments, not on their identity. Consider the
example:


Create Variable x y

x = 5

y = 5


BeginMissionSequence


If x == y


% body

EndIf


In the example, the equality operator is true because both
x

and
y

have the same value, even
though they are separate resources.

Logical Operators

The following logical operators are supported in logical expressions:


&

Logical AND (short
-
circuit operator)

|

Logical OR


The logical AND operator exhibits short
-
circuit behavior. That is, if the left
-
hand side of the
operator evaluates to false, the right
-
hand side is not evaluated, though it is still parsed for
syntactic validity.

Logical Expressions

Logical expressions are composed of relational expressions combined with logical operators.


Relational expressions must contain one relational operator and two valid arguments. Literal
boolean values are not supported, and numeric values are not interpret
ed as truth or falsehood.
See the following examples:


1 == 5 % false

1 ~= 5 % true

true % error

1 % error

A % where "A" is an Array resource; error

1 == 5 <= 3 % error


Logical expressions must

contain at least one relational expression. Multiple relational expressions
are combined using logical operators. All relational expressions are evaluated first, from left to
right, then the full logical expression is evaluated from left to right, though
the short
-
circuit AND
operator (“
&
”) may terminate the full evaluation. Parentheses are not allowed. See the following
examples:


1 == 1 % true

2 ~= 4 | 3 == 3 % true

8 >= 3 & 3 < 4 % true

2 < 4 & 1 > 3 | 5 == 5 % tru
e

2 < 4 & (1 > 3 | 5 == 5) % error

1 & 1 % error

true | false % error


Statements

Statement Structure

Script statements consist of (in order):

1

Optional
GMAT

prefix

2

Valid statement syntax (with optional line continuation)

3

Optional semicolon

4

Line termination sequence


Any statement in the script may be prefixed by the characters “
GMAT
“. This prefix is optional and
has no effect, but is supported for backward compatibility.


A statement can be split over multiple physical li
nes by using the line continuation marker, three
sequential period characters (“
...
”, hex: 2E2E2E), before each line break within the statement.


Any statement may be terminated with a semicolon character (“
;
”, hex: 3B). The semicolon is
optional and has n
o effect, but is supported for backward compatibility. Multiple statements cannot
be combined on a line.


White space may occur before or after a statement, or between any of the components listed
above. It is also generally allowed anywhere inside of a st
atement, and any exceptions are noted
in the documentation specific to that statement.

The
Create

Statement

The
Create

statement is a special statement that creates resources and assigns them names. It is
only valid in the Initialization section of the scr
ipt. It has the following components:

1

Create

keyword

2

Resource type

3

Resource name(s)


The Create keyword indicates the start of the statement. It is followed by the resource type, which
indicates the type of resource to create. This is followed by a resourc
e name, a user
-
defined name
that is then used to refer to that particular resource. This name must follow the resource naming
rules, listed previously.


The only exception to this syntax is when creating an Array resource, in which case the dimension
of th
e resource must also be specified.


Multiple resource names are allowed, in which case multiple resources of the same type will be
created. Multiple names are separated by white space or by commas (“
,
”, hex: 2C).


See the following examples:


Create Spacec
raft aSat % creates a resource named "aSat" of type
Spacecraft

Create ForceModel aFM

Create Propagator aProp

Create Variable x y % creates two Variable resources: "x" and "y"

Create String s1, s2 % creates two String resources: "s1" and "s2"

Create Array A[2,2] % creates a 2x2 Array resource named "A"


Initialization Statements

Initialization statements are special statements that assign initial values to resource fields. They
are only valid in the Initialization section of the script,
and generally take the following form:


resource
.
field

=

value


Some fields, like those on ForceModel resources, have a multiple
-
dotted form:


ForceModel
.GravityField.
PrimaryBody
.Degree =
value


All initialization statements are composed of the following

elements:

1

Resource name

2

Period character (“
.
”, hex: 2E)

3

Field name, potentially in multiple
-
dotted form

4

Equal character (“
=
”, hex: 3D)

5

Initial field value


The resource name must refer to a resource created previously in same script.


The field name must
refer to a valid field that exists for the associated resource type. Parameters
cannot be set with an initialization statement, though it is valid to set a dual
-
mode field (one that
can also be a parameter). Fields and parameters are listed in the document
ation for each resource
type.


All values are taken literally; no evaluation is performed. Therefore, numeric and string values must
be specified as literals, and resource names and parameters are stored as references. See the
following example:


Create Sp
acecraft aSat

Create XYPlot aPlot

Create Variable x y z


x = 7100 % valid

aSat.X = 7100 % valid

aSat.X = 7100 + 2 % error (mathematical expression)


aSat.X = x % error (field accepts literal, and vari
able


% evaluation does not occur)

aPlot.XVariable = x % valid (field accepts reference to Variable x)

aPlot.YVariables = {y, z} % valid (field accepts array of references to


% Variables y and z
)


Fields that have no assigned value in the Initialization section of the script remain at their default
values, as specified in the documentation for each resource type.

Command Statements

Command statements invoke GMAT commands. They must appear in the

Mission Sequence
section of the script. One special command,
BeginMissionSequence
, initiates the Mission
Sequence.


Command statements are displayed by the GUI as individual line items in the Mission tree. The
only exception is the
BeginScript
/
EndScript

compound command; this is displayed as a single
ScriptEvent

item by the GUI.


Command statements are composed of the following elements:

1

Command name (except Assignment commands)

2

Optional label

3

Command arguments


The command name is the name of the comman
d being invoked (e.g.
Propagate

or
BeginFiniteBurn
). The command name is mandatory with one exception: the Assignment
command is indicated by its structure (“
LHS

=
RHS
”) instead of its name.


A command label is an optional string literal that can be added
immediately after the command
name. This label is used by the GUI to “name” the statement in the Mission tree, and is intended
for a short text description to aid the user. It must be single
-
quoted, whether or not it contains
spaces. The command label may
contain any ASCII character except certain non
-
printable
characters (NUL, SUB), line termination characters (LF, CR), the percent sign (“
%
”), and the single
quote (“
‘
“). If the command label is omitted, the Mission tree statement is given a default label
m
ade up of the command name and an ID number. For example, if the third
Propagate

command
in the script is unlabeled, it will be given the default label “Propagate3”.


The command arguments control the behavior of the command. The syntax of the arguments is

specified by each command individually, and is documented separately. Some commands, such
as
Stop
, have no arguments.


See the following example:


Propagate 'Prop to periapsis' aProp(aSat) {aSat.Periapsis}


In the example, “
Propagate
” is the command
name, “
'Prop to periapsis'
” is the command
label, and “
aProp(aSat) {aSat.Periapsis}
” is the argument string.

Compound Statements

Compound statements are command statements that control the execution of other command
statements. Compound statements are comp
osed of three elements:

1

Begin statement

2

Body

3

End statement


The begin statement carries the name of the command itself, while the end statement begins with
the string “End”. For example, the
While

command is a compound command composed of two
statements:


While

[
'
label
'
]
arguments


[
body
]

EndWhile


The
If
/
Else

compound command is composed of three statements:


If

[
'
label
'
]
arguments


[
body
]

Else


[
body
]

EndIf


The body of a compound command may consist of independent command statements, possibly
including other compound statements. Certain compound commands may limit the commands that
can be present in the body, while other commands may only be contained within
certain compound
commands. These limitations are documented separately for each command.

Processing

GMAT processes a script in two phases: interpretation and execution. This section gives an
overview of the processing sequence; low
-
level details are docume
nted in Chapter 17 of the
GMAT Architectural Specification.

Interpretation

GMAT interprets a script in two stages: a parsing stage and a validation stage.

In the parsing stage, GMAT reads and interprets each line of the script sequentially. As it interpret
s
a line, it checks it for syntactic correctness and performs any initialization needed by the line. For
example, if the line being interpreted is a
Create

statement, the related resource is created. If
GMAT encounters an initialization line, it assigns th
e appropriate value to the indicated resource
field. And if it encounters a command statement, it creates the command structure and interprets
its arguments. All language, resource initialization, and command syntax errors are caught during
this parsing st
age.


In the validation stage, GMAT checks that all references between resources are valid. For
example, if the script indicates that a
Spacecraft

resource should be defined in relation to a
specific
CoordinateSystem

resource, the reference is validated du
ring this stage. The validation
checks that all referenced resources exist and are of the correct type.


The two
-
stage interpretation method affects the order of statements in the script. For example,
Create

statements must appear in the script above any i
nitialization statements that reference the
resource being created. But because validation is performed separately, the
Create

statement for
a
CoordinateSystem

resource can appear in the script below an initialization line that references
this resource. Se
e the following examples:


Create Spacecraft aSat


% This is valid; the aSat resource has been created by the line above.

aSat.DateFormat = TAIGregorian


% This is invalid; the aReport resource has not yet been created.

aReport.Filename = 'report.txt'

Create ReportFile aReport


Create XYPlot aPlot


% This is valid; the reference to aSat is validated

% after all resources are created.

aPlot.XVariable = aSat.A1ModJulian


Create Spacecraft aSat


Once both stages have completed, the script has been loaded into GMAT. In the GUI, if any, the
Resources tree is populated with the resources created in the Initialization section of the script,
and the Mission tree is populated with the command statements

in the Mission Sequence.


The interpretation phase is also sometimes called the “build” phase or the “load” phase.

Execution

When a mission is run, GMAT first builds interconnections between resources, then performs
command execution. In this phase, all c
ommands in the Mission Sequence are executed
sequentially, in the order of definition in the script. When a command statement is executed, its
arguments are fully processed by the command, and any remaining errors are reported. Examples
of execution
-
phase
errors include mismatched data types, out
-
of
-
bounds array references, and
divide
-
by
-
zero errors.

Processing Errors

If GMAT encounters an error during the interpretation stage (parsing or validation), the mission is
not loaded. Instead, GMAT reverts to a mi
nimum mission consisting of:

●

SolarSystem

●

Default
CoordinateSystem

resources:
EarthMJ2000Eq
,
EarthMJ2000Ec
,
EarthFixed
,
EarthICRF


If an error is encountered during the execution stage (linking or command execution), execution of
the mission stops at the
point of the error.

Test Procedures

Assumptions

(None)

Existing Tests


Priority

Status

Summary










Recommended Additional Tests

Nominal Tests

All test names begin with the prefix “
ScriptLanguage_
”.

Status

Name

Summary

✓

ScriptSections_*

Script sections/modes: missing initialization? missing
mission sequence? empty script?

✓

CaseSensitivity

Case sensitivity

✓

LineTermination_*

Line termination characters

✓

WhiteSpace_*

Whitespace: tabs, spaces, mixture

✓

RandomWhiteSpace_*

Random
whitespace throughout the script

✓

Comments_*

Comments in all allowed locations

✓

DataTypes_Real

Real numbers in different modes in different formats

✓

DataTypes_Real

Scientific notation variations

✓

DataTypes_String

String literals in different
formats, with/without quotes, all
allowed embedded chars

✓

DataTypes_Boolean

All allowed boolean values, case
-
insensitivity

✓

DataTypes_Enumeration

Enumerated value formats (with/without quotes, etc.)

✓

ResourceNames

Lots of variations on valid resource

naming

✓

ResourceShadowing

Valid shadowing tests (same name as a resource type,
same name as a function, same name as a built
-
in
function)

✓

NoPrefixSuffix_*
,
PrefixOnly_*
,

PrefixSuffix_*
,
SuffixOnly_*

GMAT prefix and semicolon postfix on multiple
commands

✓

LineContinuation_*

Line continuation

✓

LiteralArrays

Arrays of literals with different literal types, spacing,
commas/spaces/tabs

✓

ReferenceArrays

Arrays of references for each resource type, same test
types as arrays of literals. Need to tr
y this for each
resource type.

✓

DataTypes_Integer

Valid integers values

✓

WhiteSpace_*

Whitespace inside different statements

✓

Create

Create statement with single and multiple, with whitespace
and commas

✓

CommandLabels

All commands with labels,
valid labels

✓

InitOrder_*

Script line order in initialization; create before access,
references independent of create order

✓

FilePaths

File path strings

✓

DataTypes_Reference

Resource and parameter references



Edge/Corner/Stress


Priority

Status

Summary











Unique Validation


Status

Name

Summary

✓

CommandsInInit_*

Command statements in initialization

✓

CreateInMs

Create statement in the mission sequence

✓

InitNonLiteral_*

Non
-
literal assignments in initialization

✓

CaseSensitivity_*

Case sensitivity

✓

NonASCIIChars_*

Characters outside the 7
-
bit US
-
ASCII set

✓

DisallowedChars_*

Disallowed characters

✓

MultStatementsOnOne
Line_*

Missing line termination characters

✓

InvalidWhiteSpace_*

Whitespace in disallowed places (inside literals,
inside keywords, etc.)

✓

InvalidComments_*

invalid comments (multi
-
line, embedded, other chars,
terminated by different EOL chars)

✓

InvalidRealLiterals
_*

Disallowed real literals (spaces, letters,
multiple
decimals, exponent decimals, wrong scientific
notation letters)

✓

DataTypes_String_*

Invalid string literals (wrong quotes, mismatched
quotes, escape sequences, EOL chars, missing
quotes with spaces, comment chars)

✓

DataTypes_Boolean_*

Invalid
boolean values

✓

InvalidDataTypes_*

Literals in disallowed locations, or of wrong type (real
instead of boolean, etc.)

✓

ReferenceToResource
Type_*

Use resource type directly (instead of using an
instance)

✓

InvalidNames_*

Invalid resource names

✓

InvalidNames_*

Name conflicts (same name as a reserved word)

✓

LineContinuation_*

Invalid line continuation

✓

GmatPrefix_*

Invalid “GMAT “ prefix

✓

Semicolons_*

Invalid semicolons and multiple statements per line

✓

Create_*

Invalid Create statements
(nonexistent parts,
nonexistent resource types, invalid delimiters, etc.)

✓

InitStatement_*

Invalid initialization statements (nonexistent
resources, nonexistent fields, invalid syntax)

✓

DataTypes_LiteralAr
rays_*

Mixed arrays of literals, arrays of
wrong type, wrong
brackets, wrong delimiter, etc.

✓

DataTypes_Reference
Array_*

Invalid arrays of resources for each resource type,
wrong brackets, with/without brackets, etc. Need to
try this for each resource type.

✓

DataTypes_Integer_*

Invalid integer
literals (scientific notation, with
decimal, etc.)

✓

Reserved_*

Case
-
insensitive reserved keywords

✓

CommandLabels_*

Invalid command labels (wrong quotes, wrong place,
invalid characters)

✓

SetBeforeCreate_*

Set field before Create

✓

FilePaths_*

Invalid file path strings

✓

Reference_*

Invalid reference syntax (wrong quotes, nonexistent
reference, etc.)


Unique Mode Tests


Priority

Status

Summary











Unique GUI Tests

These are tests that are unique to the GUI interface for this feature
that are not covered by the
standard GUI test template and procedures.


Priority

Status

Summary