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
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο