GALLOP Version 4.5 User’s Guide - Purdue Engineering€¦ · Before you can use GALLOP, you need...

GALLOP Version 4.5

User’s Guide

T. Troy McConaghySchool of Aeronautics and Astronautics

Purdue UniversityWest Lafayette, Indiana

September 3, 2005

Contents

1 Introduction 91.1 What is GALLOP? . . . . . . . . . . . . . . . . . . . . . . . . 91.2 A Bit of the History of GALLOP . . . . . . . . . . . . . . . . 91.3 Software Related to GALLOP . . . . . . . . . . . . . . . . . . 10

2 Setting Up to use GALLOP 132.1 Making Your GALLOP Directory . . . . . . . . . . . . . . . . 132.2 Modifying Your .cshrc and/or .login Files . . . . . . . . . . . . 14

3 A First Example 173.1 Let’s go to Ceres! . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 The Process of Using GALLOP . . . . . . . . . . . . . . . . . 173.3 Getting the Canned Input Files . . . . . . . . . . . . . . . . . 183.4 Running GALLOP . . . . . . . . . . . . . . . . . . . . . . . . 193.5 Running GLOOK . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 The Optimizer Specs File 25

5 The GALLOP Input File 295.1 Parameters in the GALLOP Input File . . . . . . . . . . . . . 31

5.1.1 beta(1) through beta(4)

(Solar Array Time Degradation Model Parameters) . . 325.1.2 bodname(i)

(Name of the ith Body on the Mission) . . . . . . . . . 325.1.3 bodtype(i)

(Type of the ith Body on the Mission) . . . . . . . . . 335.1.4 cm(1) through cm(5)

(Engine Mass Flow Rate Model Parameters) . . . . . . 33

3

4 CONTENTS

5.1.5 ct(1) through ct(5)

(Engine Thrust Model Parameters) . . . . . . . . . . . 345.1.6 dutycyc

(Engine Duty Cycle) . . . . . . . . . . . . . . . . . . . 345.1.7 dvmag epsilon

(Fudge Factor Used when Calculating ∆v Magnitude) . 355.1.8 dvparam

(Internal Parameterization of the ∆v Vectors) . . . . . 355.1.9 enc type(i)

(Encounter Type at Intermediate Body i) . . . . . . . 365.1.10 inf flag

(String Used to Represent Infinity) . . . . . . . . . . . 365.1.11 kt

(Tankage Factor) . . . . . . . . . . . . . . . . . . . . . 375.1.12 legtofbds(i)

(Bounds on the TOF of leg i) . . . . . . . . . . . . . . 375.1.13 mass drop(i)

(Mass Drop at Intermediate Body i) . . . . . . . . . . 385.1.14 minstaytim(i)

(Minimum Stay Time at Intermediate Body i) . . . . . 385.1.15 nsegbp(i)

(Number of Segments Before the Breakpoint on Leg i) 395.1.16 nsegleg(i)

(Number of Segments on Leg i) . . . . . . . . . . . . . 395.1.17 numbodies

(Number of Bodies on the Mission) . . . . . . . . . . . 405.1.18 optimizer

(Name of the Optimizer to Use) . . . . . . . . . . . . . 405.1.19 p0

(Reference Solar Array Power) . . . . . . . . . . . . . . 405.1.20 pmax and pmin

(Minimum-Needed and Maximum-AllowedEngine Power) . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.21 r cutoff

(Radius above which Power Equals Zero) . . . . . . . . 415.1.22 r max

(Radius above which Solar Array RelativeEfficiency is Constant) . . . . . . . . . . . . . . . . . . 41

CONTENTS 5

5.1.23 r tilt

(Radius below which Solar Array RelativePower is Constant) . . . . . . . . . . . . . . . . . . . . 42

5.1.24 sa(1) through sa(5)

(Solar Array Relative Efficiency Model Parameters) . . 425.1.25 scp

(Power Used by Spacecraft) . . . . . . . . . . . . . . . 435.1.26 solfile

(Name of Solution File) . . . . . . . . . . . . . . . . . 435.1.27 tofbounds

(Bounds on the Mission TOF) . . . . . . . . . . . . . . 435.1.28 trajtype

(Trajectory Type: rendezvous or flyby) . . . . . . . . . 445.2 Optimization Variables in the GALLOP Input File . . . . . . 44

5.2.1 The ∆v Vectors on the Segments . . . . . . . . . . . . 475.2.2 The Julian Dates at the Bodies . . . . . . . . . . . . . 495.2.3 The Launch v∞ . . . . . . . . . . . . . . . . . . . . . . 495.2.4 The Incoming Velocities at the Bodies . . . . . . . . . 505.2.5 The Spacecraft Mass at the Bodies . . . . . . . . . . . 505.2.6 Flyby Altitude at the Flyby Bodies . . . . . . . . . . . 515.2.7 B-plane Angle of Flyby at the Flyby Bodies . . . . . . 51

5.3 Optimization Variable Transformations . . . . . . . . . . . . . 545.3.1 The ∆v Magnitude Transformation . . . . . . . . . . . 545.3.2 The Angle Transformations . . . . . . . . . . . . . . . 555.3.3 The Cartesian ∆v Transformations . . . . . . . . . . . 555.3.4 The Julian Dates Transformations . . . . . . . . . . . . 565.3.5 The Launch v∞ Magnitude Transformation . . . . . . 565.3.6 The Transformation of the Velocities at the

Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.3.7 The Spacecraft Mass Transformation . . . . . . . . . . 575.3.8 The Flyby Altitude Transformations . . . . . . . . . . 57

5.4 Translating AUTO3 Files intoGALLOP Input Files . . . . . . . . . . . . . . . . . . . . . . . 57

5.5 The GALLOP Wizard (GWIZ) . . . . . . . . . . . . . . . . . 59

6 Using Multiple Engines 636.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2 Multiple-Engine Input Parameters . . . . . . . . . . . . . . . . 65

6 CONTENTS

6.2.1 numengines

(Number of engines operable) . . . . . . . . . . . . . . 65

6.2.2 alloc rules

(Heuristic power-allocation rules) . . . . . . . . . . . . 66

6.2.3 e truthfactor

(Engines truthfactor) . . . . . . . . . . . . . . . . . . . 67

6.2.4 e sharpness

(Sharpness of the engine thrust and mass-flow ratefunctions) . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.3 Testing the Engines . . . . . . . . . . . . . . . . . . . . . . . . 69

6.4 Guidelines when Using Multiple Engines . . . . . . . . . . . . 72

7 The GALLOP Output Files 75

7.1 The GALLOP Solution File . . . . . . . . . . . . . . . . . . . 75

7.2 The Solution Plotting Information File . . . . . . . . . . . . . 75

7.3 Other Output Files . . . . . . . . . . . . . . . . . . . . . . . . 76

8 Some Notes on Using GALLOP 77

8.1 Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.2 Using Analytic Ephemeris Data . . . . . . . . . . . . . . . . . 78

8.3 Finding a Feasible Trajectory . . . . . . . . . . . . . . . . . . 78

8.4 Nuclear Electric Propulsion (NEP) Missions . . . . . . . . . . 79

9 Common Errors and Problems 81

9.1 GALLOP Finished without Stating an EXIT Condition . . . . 81

9.2 EXIT -- the superbasics limit is too

small . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

9.3 Core Dumped . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

A The Power Model 83

B The Engine Model 85

C Launch Vehicles 89

C.1 The Launch Vehicle Model . . . . . . . . . . . . . . . . . . . . 89

C.2 Launch Vehicles Available in GALLOP . . . . . . . . . . . . . 95

CONTENTS 7

D Example Session with the GALLOP Wizard 103

Bibliography

8 CONTENTS

Chapter 1

Introduction

1.1 What is GALLOP?

GALLOP stands for “Gravity-Assist Low-thrust Local Optimization Pro-gram.” It is a computer program to optimize low-thrust spacecraft trajecto-ries. The trajectories may include gravity-assist maneuvers and/or interme-diate rendezvouses.1 Power is assumed to come from either solar arrays orsome constant-power source (like a nuclear reactor).

1.2 A Bit of the History of GALLOP

In the late 1990’s, a decision was made at the Jet Propulsion Laboratory(JPL) to develop some new low-thrust trajectory optimization software. LikeJPL’s CATO software, the new software would use a direct method to solvethe optimization problem. (JPL’s SEPTOP software uses an indirect method.)

Jon Sims and Steve Flanagan wrote some prototype optimization soft-ware named CLSEP, which stands for “CATO-like Solar-Electric Propul-sion.” Some of their results are described in Ref. [1]. Functional require-ments for the new software were worked out and put in a design document.The new software was to be known as Houdini.

Around the same time, Anastassios Petropoulos was working on his PhDat Purdue University. He was creating the software STOUR-LTGA, whichmakes broad searches in the set of low-thrust gravity-assist trajectories. Once

1Yes, rendezvouses is a real word.

9

10 CHAPTER 1. INTRODUCTION

STOUR-LTGA finds a good trajectory, it must be optimized by some othersoftware.

When Troy McConaghy came to Purdue University in 2000, Anastassiosneeded some software to optimize trajectories found with STOUR-LTGA.Jon Sims sent a copy of CLSEP to Purdue, and Troy started working withit. Troy ended up rewriting most of CLSEP and the new software becameknown as GALLOP. The capabilities of CLSEP and GALLOP differ in theirdetails but the underlying trajectory model is the same in both programs.GALLOP has been used to optimize a number of interesting trajectories,many of which have been published (see Refs. [2]–[6]).

In late 2002, Troy sent a copy of GALLOP to JPL. Ed Rinderle and PaulFinlayson (at JPL) then used that as a starting point for the software thatthey call MALTO, which stands for “Mission Analysis Low Thrust Optimiza-tion.”

1.3 Software Related to GALLOP

GALLOP is written in Fortran 90 and uses many functions from other li-braries. These libraries include the MASL vector library (written at JPL),the MASL SPICE library (also JPL), and the NPOPT library (optimizationcode written at Stanford Business Software, Inc.).

One of the motivations for writing GALLOP was to optimize trajectoriesthat had been found using STOUR-LTGA (the low-thrust version of STOUR,written by Anastassios Petropoulos). Paul Precoda wrote a Matlab tool toanalyze the thousands of candidate solutions produced by STOUR-LTGA. Ithelps the user pick out a trajectory to be optimized by GALLOP and evencreates the GALLOP input file. This program, named SIT (for STOUR-LTGA Interactive Toolkit) is discussed further in section 5.4.

Another way to generate input files for GALLOP is to use the GAL-LOP Wizard, also known as GWIZ (pronounced JEE-whiz). The GALLOPWizard asks you a series of questions and uses the answers to generate aGALLOP input file. GWIZ is discussed further in section 5.5.

There are also some Matlab functions that were written to make usingGALLOP a more pleasant experience:

• M0 calculates the mass that a given launch vehicle can inject into Earthorbit with a given v∞. M0 is discussed further in Appendix C.

1.3. SOFTWARE RELATED TO GALLOP 11

• GLOOK (pronounced GEE-look) helps interpret trajectories that havebeen optimized by GALLOP. GLOOK can make lots of useful plots.The name GLOOK comes from the words “GALLOP” and “ LOOK”because it is a tool to give you a “look” at the solution found by GAL-LOP. GLOOK can also be used to create a new GALLOP input filebased on the current solution.

12 CHAPTER 1. INTRODUCTION

Chapter 2

Setting Up to use GALLOP

Before you can use GALLOP, you need to do a bit of setup. This doesn’ttake long, though, and once you’re done setup, you won’t ever need to do itagain.

2.1 Making Your GALLOP Directory

The first thing you should do is make yourself a GALLOP directory some-where in your personal directory structure on the Engineering ComputerNetwork (ECN).

For example, after logging into your ECN account, you could create asubdirectory of your home directory by entering1:

> cd

> mkdir GALLOP

where > is your UNIX prompt (yours may be different). This creates a newsubdirectory of your home directory named GALLOP. This subdirectory willbe referred to as “your GALLOP directory” in the remainder of this User’sGuide.

1I am being very explicit here on purpose. If you are a UNIX guru, then feel free toskim.

13

14 CHAPTER 2. SETTING UP TO USE GALLOP

2.2 Modifying Your .cshrc and/or .login Files

Whenever you open a terminal window in UNIX, a ’shell program’ (like sh,ksh, csh, or tcsh) is started. Currently, most students on ECN use tcsh.This is the program that gives you an interface to UNIX.

The first thing tcsh does is execute the file .tcshrc in your home direc-tory. If there is no .tcshrc file (which is the case for me), then tcsh executesthe file .cshrc. It then executes the .login file in your home directory. Onlythen does it give you your usual UNIX prompt.

GALLOP needs some environment variables to be defined in order torun properly. You could define them manually at the UNIX prompt everytime you want to run GALLOP, but it is a lot more convenient to put theirdefinitions in your .cshrc or your .login file. That way, they get definedautomatically every time you log in and open a terminal window.

Below are the GALLOP-pertinent lines that I have in my .cshrc file. (Idon’t currently have any GALLOP-pertinent lines in my .login file.) Youmight already have some of these lines in your .cshrc file or your .login

file. If so, that’s fine—just leave them where they are2. Note that the linesbeginning with a # are comment lines.

In your .cshrc file

setenv AAE508 /home/roger/a/aae508/usr

setenv FONT_FILE "$AAE508/lib/font-file"

set path=($path $AAE508/bin)

setenv MASLPATH /home/roger/a/masl

setenv PATH "$PATH : $MASLPATH"

set path=($path $MASLPATH/bin)

##########################################

# To force GALLOP to use analytic #

# ephemerides, unsetenv MAS_LOAD_POINT. #

# (Note: analytic ephemerides are not #

# available for asteroids or comets.) #

##########################################

2I will assume that you are familiar with a text editor like Emacs or vi.

2.2. MODIFYING YOUR .CSHRC AND/OR .LOGIN FILES 15

setenv MAS_LOAD_POINT /home/roger/a/masl

#unsetenv MAS_LOAD_POINT

####################################

# To ensure GALLOP opens de202.bsp #

# EPHEMERIS1 must be set to it. #

####################################

#setenv EPHEMERIS1 "$MASLPATH/data/de202.bsp"

unsetenv EPHEMERIS1

###################################

# GALLOP Launch Vehicle Data Path #

###################################

setenv LVPATH "$AAE508/lib/gallop/lv"

Remember to save your modified .cshrc and .login files before you closethem. You may want to log out and log back in to make sure that yourchanges take effect.

16 CHAPTER 2. SETTING UP TO USE GALLOP

Chapter 3

A First Example

3.1 Let’s go to Ceres!

In order to help get new users up an running (galloping?) quickly, Chapter 3goes step-by-step through an example of using GALLOP. We will optimize alow-thrust trajectory to the asteroid Ceres via a gravity-assist maneuver atMars.

3.2 The Process of Using GALLOP

There are lots of different ways to use GALLOP, but the most commonprocess follows these four steps:

1. Create a GALLOP input file.

2. Create an optimizer specs file.

3. Run GALLOP to optimize the trajectory.

4. Interpret the solution using GLOOK.

The GALLOP input file and the optimizer specs file are inputs to GAL-LOP. GALLOP generates a solution file and a solution plotting informationfile.1 The solution file and the solution plotting information file are used asinputs to the GLOOK program. GLOOK can create a trajectory summary

1Some optimizers also generate another file, but it can safely be ignored

17

18 CHAPTER 3. A FIRST EXAMPLE

file and all sorts of stunning graphics files. The typical flow of files throughGALLOP and GLOOK is illustrated in Figure 3.1. As you can see, there arelots of files to keep track of, so it is helpful to have an image like Figure 3.1in mind.

GLOOKGALLOP

solutionGALLOP

input file

Optimizerspecs

file

GALLOP

file

plottingSolution

fileinformation

Graphics

files

Figure 3.1: The typical flow of files when using GALLOP

In this chapter, we will be using a canned input file and a canned optimizerspecs file. Later on, you could use them as templates for new files.

3.3 Getting the Canned Input Files

The first thing you need to do is set up your account to use GALLOP.Chapter 2 describes how to do the setup. If you haven’t already done it,then go do it now and come back to this section when you’re done.

Log in to your ECN account and go to your GALLOP directory. Copy thefiles EMC_inp1 and NPOPT_specs1 from $AAE508/lib/gallop/ to your GAL-LOP directory. For example, if your GALLOP directory is named ~/GALLOP,then you would enter:

> cd

> cd GALLOP

> cp $AAE508/lib/gallop/EMC_inp1 .

> cp $AAE508/lib/gallop/NPOPT_specs1 .

EMC_inp1 is a GALLOP input file for an Earth-Mars-Ceres (EMC) ren-dezvous trajectory. GALLOP input files are described in Chapter 5.

3.4. RUNNING GALLOP 19

NPOPT_specs1 is an optimizer specs file. Optimizer specs files are de-scribed in Chapter 4.

Let’s see what happens when we give those files to GALLOP.

3.4 Running GALLOP

Assuming that you are in your GALLOP directory, all you need to do to runGALLOP is enter:

> cat NPOPT_specs1 | gallop i=EMC_inp1

and watch the optimizer run. It should run for about five seconds. Youshould see it reporting after each major iteration and once it is finished, youshould see reams of information reported about the solution.

Three new files will also be created:

1. The solution file EMC_inp1_sol

2. The solution plotting information file EMC_inp1_sol.plt

3. The NPOPT (optimizer) summary file fort.11

You can look inside those files if you like. I’ll describe them in moredetail later. First, let’s use GLOOK to interpret the trajectory that you justoptimized.

3.5 Running GLOOK

GLOOK is a Matlab script, so you need to launch Matlab before you canrun it (just type matlab at the UNIX prompt).2 Once you have the Matlabprompt (>> ) in front of you, you need to add GLOOK’s directory to theMatlab path. Just enter:

>> addpath /home/roger/a/aae508/usr/lib/gallop

Assuming you are still in your GALLOP directory, you can use GLOOKto read the optimized trajectory solution by entering:

2Matlab is a registered trademark of the Mathworks, Inc.


>> glook(’EMC_inp1_sol’)

You should get a bunch of messages about ephemeris files being read andclosed. Once that is over, the following menu should come up:

Glook options:

0. Exit.

1. Plot Delta-V Magnitude on each segment.

2. Plot (Delta-V Magnitude)/(segment duration) on each segment.

3. Plot Out-of-plane (DV magnitude)/(segment duration) on each

segment.

4. Plot Theta on each segment.

5. Plot Psi on each segment.

6. Plot 2D s/c trajectory.

7. Plot 3D s/c trajectory.

8. Make a VanderVeen plot.

9. Summarize trajectory characteristics.

10. Plot Specific Energy on each conic arc.

11. Plot the Period on each conic arc.

12. Plot the Inclination on the conic arcs.

13. Plot the Eccentricity on the conic arcs.

14. Modify this solution to create a new GALLOP input file.

15. Plot a Tisserand P-rp graph.

16. Plot a Tisserand E-rp graph.

99. Change some GLOOK parameters.

Select one:

The menu is fairly self-explanatory. Examples of the plots produced byselecting options 7 and 8 are shown in Figures 3.2 and 3.3.

3.5. RUNNING GLOOK 21

−3−2

−10

12

34 −3

−2−1

01

2−1

0

1

y (AU)

The Spacecraft Trajectory

x (AU)

z (A

U)

Figure 3.2: The Plot Produced by Option 7


0 200 400 600 800 10000

0.5

1

1.5

2

2.5

3

Time since launch (days)

Dis

tanc

e fr

om S

un (

AU

)

VanderVeen Plot (Start date: 06−May−2003)

SpacecraftMission bodiesEncounterEARTH−MARS close appr.

Figure 3.3: The Plot Produced by Option 8

3.5. RUNNING GLOOK 23

Since the plots GLOOK makes are Matlab plots, you can save them orexport them to all kinds of graphics formats (EPS, JPEG, TIFF, PNG, etc.).

If you enter 9 (Summarize trajectory characteristics), then the followingsummary information will be displayed (the numerical values may be slightlydifferent — GALLOP is constantly being modified):

Summary of Trajectory Characteristics

Launch body: planet EARTH

Launch date: 06-May-2003 00:00:00

Launch Julian date: 2452765.500000

Launch V-infinity: 1.600300 km/s

Launch mass: 568.000000 kg

Leg #1 (segments 1-20):

Number of segments: 20

Duration of each segment: 13.560000 days

Total leg duration: 271.200000 days = 0.742505 years

Sum of Delta-V magnitudes on leg #1: 2.507974 km/s

Cumulative sum of all Delta-V’s to end of leg #1: 2.507974 km/s

Intermediate body #1: planet MARS

Encounter type: flyby

Arrival date: 01-Feb-2004 04:48:00

Arrival Julian date: 2453036.700000

Flyby altitude: 200.000000 km

Flyby B-plane angle: 80.760308 degrees

S/C V-infinity: 1.9144541072 km/s

Mass before arrival: 526.095255 kg

Mass drop: 0.000000 kg

Mass after departure: 526.095255 kg

Leg #2 (segments 21-40):

Number of segments: 20

Duration of each segment: 43.105000 days

Total leg duration: 862.100000 days = 2.360301 years

Sum of Delta-V magnitudes on leg #2: 5.939271 km/s

Cumulative sum of all Delta-V’s to end of leg #2: 8.447245 km/s


Arrival body: asteroid CERES

Encounter type: rendezvous

Arrival date: 12-Jun-2006 07:12:00

Arrival Julian date: 2453898.800000

Angle between Sun-Earth vector and Sun-ceres vector on the

arrival date = 47.639387 degrees

Arrival V-infinity: 0.0000000000 km/s

NOTE: Since arrival V-infinity is zero and the last

3 segments have a Delta-V of zero, the spacecraft

doesn’t really arrive until after the ’Arrival date’.

The actual arrival date is sometime between

Julian date 2453726.380000 (21-Dec-2005 21:07:12)

and Julian date 2453769.485000 (02-Feb-2006 23:38:24).

Total time of flight (TOF): 1133.300000 days = 3.102806 years

Corrected TOF (to account for delayed departure or premature

arrival):

minimum: 960.880000 days = 2.630746 years

maximum: 1003.985000 days = 2.748761 years

Initial mass: 568.000000 kg

Propellant mass: 132.754047 kg

Sum of mass drops: 0.000000 kg

Final mass: 435.245953 kg

Propellant mass / Initial mass : 0.233722

The other options work similarly. Enter 0 (zero) when you are done.Congratulations! Now you know the main steps to running GALLOP and

GLOOK. In the next chapter, we’ll take a closer look at the GALLOP inputfiles.

Chapter 4

The Optimizer Specs File

The optimizer specs file is used to set parameters that control the optimizer(NPOPT). Here are the contents of the optimizer specs file that you used inChapter 3 (NPOPT_specs1):

BEGIN NPOPT OPTIONS

Feasible exit

Derivative level 3

Iterations limit 100000

Minor iteration limit 1000

Major iteration limit 100

Superbasics limit 2000

Major feasibility tolerance 1.0E-6

Major optimality tolerance 1.0E-6

Function precision 1.0E-10

Major print level 1

END NPOPT OPTIONS

As you can see, there’s not much to it. It begins with the line “BEGINNPOPT OPTIONS” and ends with the line “END NPOPT OPTIONS”.Each line in between sets one optimization parameter. You don’t have to setany optimization parameters — they all have default values.

All of the NPOPT parameters (also known as “options”) are describedin great detail in Chapter 6 of the User’s Guide for SNOPT, which can befound online at the Stanford Business Software Inc. (SBSI) website:

http://www.sbsi-sol-optimize.com/

25

26 CHAPTER 4. THE OPTIMIZER SPECS FILE

(NPOPT is just a wrapper for SNOPT. That is, GALLOP calls NPOPTwhich then calls SNOPT.)

The main optimization parameters that you’ll want to know are summa-rized below. First, some preliminary comments should be made:

• At a very high level of abstraction, NPOPT does a sequence of “majoriterations” to find the optimal solution. Each major iteration involvesdoing a sequence of “minor iterations”.

• When using GALLOP, m is the number of nonlinear constraint func-tions.1

The main parameters that you’ll want to know about are:

Iterations limit

Default = max(10000, 20m)This is the maximum number of minor iterations allowed, summed over allmajor iterations.

Major iteration limit

Default = max(1000,m)This is the maximum number of major iterations allowed.

Minor iteration limit

Default = max(1000, 5m)This is the maximum number of minor iterations allowed inside each majoriteration. Current experience is that the major iterations converge morereliably if the subproblems being solved in the major iterations are allowedto solve accurately. Thus, Minor iteration limit should be a large value.

Note that Iterations limit defines an independent limit on the total

number of minor iterations (summed over all major iterations).

Major feasibility tolerance

Default = 1.0E-6Roughly speaking, this specifies how accurately the nonlinear constraintsshould be satisfied before the optimizer can stop and say it found a ’feasiblesolution’. See the User’s Guide for SNOPT for more details.

1m = (the total number of segments) + 7 × (the total number of legs)

27

Major optimality tolerance

Default = 1.0E-6Roughly speaking, this specifies how close to optimal the solution must bebefore the optimizer can stop and say it found an ’optimal solution’. See theUser’s Guide for SNOPT for more details.

These last two parameters (Major feasibility tolerance and Major optimal-ity tolerance) are the two most important controls that you have on theoptimizer.

In a perfect world, you would like to find an exactly feasible solutionand an exactly optimal solution (at the same time). That would corre-spond to setting the Major feasibility tolerance and the Major optimal-ity tolerance to zero. Of course, this is not a perfect world. The opti-mizer usually can’t find a solution that is exactly feasible and exactly op-timal. So you tell the optimizer how much infeasibility you can tolerate(the Major feasibility tolerance) and how much suboptimality you cantolerate (the Major optimality tolerance).

If you set the Major feasibility tolerance and the Major optimality toler-ance too small, then the optimizer will probably not be able to find a solutionthat meets the criteria.

So how do you pick good values for the Major feasibility tolerance andthe Major optimality tolerance? At first, you just make a good guess like1.0E-6 for both. Then you run GALLOP. You watch as each major iterationgets reported on the screen. Each major iteration will be reported by one lineof text. Below is an example showing the report lines generated for majoriterations 0–12 of a GALLOP run. (I’ve truncated off the last seven columnsbecause they aren’t relevant right now.)

28 CHAPTER 4. THE OPTIMIZER SPECS FILE

Itns Major Minors Step nCon Feasible Optimal

133 0 133 1 2.2E+00 3.5E-02

149 1 16 6.6E-01 2 8.4E-01 3.2E-02

150 2 1 1.0E+00 3 2.5E-01 2.8E-03

156 3 6 1.0E+00 4 5.1E-02 8.0E-03

159 4 3 1.0E+00 5 9.7E-02 5.6E-03

162 5 3 1.0E+00 6 2.4E-02 8.3E-03

165 6 3 1.0E+00 7 1.0E-01 6.2E-03

169 7 4 1.0E+00 8 5.5E-03 4.3E-03

175 8 6 1.0E+00 9 1.2E-02 6.5E-03

178 9 3 1.0E+00 10 4.4E-02 7.2E-04

182 10 4 1.0E+00 11 9.3E-03 8.9E-04

185 11 3 1.0E+00 12 3.1E-03 6.7E-03

187 12 2 1.0E+00 13 2.3E-02 1.0E-02

The ’Feasible’ and ’Optimal’ columns are the ones to watch. As theoptimizer runs, you want the number in the ’Feasible’ column to becomeless than your Major feasibility tolerance and you also want the number inthe ’Optimal’ column to become less than your Major optimality tolerance.Once that happens, the optimization run will end with:

EXIT -- optimal solution found

There are no sweeter words than those! Of course, if you set the Majorfeasibility tolerance or your Major optimality tolerance too large, then theso-called ’optimal solution’ won’t be very good. Ideally, you’d like to findthe smallest tolerances that still result in “EXIT – optimal solution found.”

There are some other optimizer parameters like “Minor feasibility toler-ance” that I sometimes change as well. Refer to the User’s Guide for SNOPT

for a complete listing of all the optimizer parameters that you can set.

Chapter 5

The GALLOP Input File

The GALLOP input file format is designed to be easily read by humans,FORTRAN, Matlab, and Microsoft Excel.1 To accomplish this feat, GAL-LOP input files are plain ASCII text files with input data in six fixed-widthcolumns.

Before you read this section, you might want to print a copy of the GAL-LOP input file you used in Chapter 3 (EMC_inp1). Since GALLOP inputfiles are so wide, The enscript command makes the printout much morereadable. For example, you could enter:

> enscript -d gris358hp -f Courier8 -r EMC_inp1

The above command will print the GALLOP input file EMC_inp1 sidewaysusing an 8-point Courier font (on the printer named gris358hp).

I will assume that you now have a copy of EMC_inp1 in front of you.The six data columns should be quite evident. There are “invisible” spacercolumns between the data columns (i.e. columns that contain only spacesand which do not get read). The purpose of the spacer columns is to makethe GALLOP input file more human-readable. For your reference, the exactwidths of all of the columns are summarized in Table 5.1.

When you modify or make GALLOP input files, you should never putany data in one of the spacer columns.

1Microsoft Excel is a registered trademark of the Microsoft Corporation

29

30 CHAPTER 5. THE GALLOP INPUT FILE

Table 5.1: GALLOP Input File Column Widths

Column widthColumn (characters)

spacer 2VARIABLE NAME 14spacer 1DESCRIPTION 44spacer 1UNITS 9spacer 1LOWER BOUND 19spacer 1VALUE 19spacer 1UPPER BOUND 19

Now let’s look more closely at the GALLOP input file EMC_inp1. GAL-LOP ignores the first two lines so I use them to label the file as a “GAL-LOP FILE” and put headings on the columns. The first two lines shouldhave a percent sign as their first non-whitespace character.

The real inputs start on line three. Each line has information aboutexactly one GALLOP variable. GALLOP uses the string in the VARI-ABLE NAME column to decide what variable to set using that line’s data.This means that the order in which the variables occur is irrelevant. However,GALLOP completely ignores the DESCRIPTION column and the UNITS

column; the purpose of those two columns is to make the file more human-readable. The units on all variables are hardwired into GALLOP (so youcannot change the units by changing the input file). The LOWER BOUND,VALUE, and UPPER BOUND columns are self-explanatory.

There are two types of GALLOP variables: parameters and optimizationvariables. Parameters get set to the values in the input file and remainconstant throughout the run. Optimization variables get initialized to thevalues in the input file, but the optimizer can vary them during the run(to improve the trajectory). The optimization variables all have names of

5.1. PARAMETERS IN THE GALLOP INPUT FILE 31

the form x(i), where i is an integer. The other variables are all parameters.The next two sections describe the parameters and the optimization variablesrespectively.

When entering non-integer numerical values into a GALLOP input file,you should always enter them in scientific notation. For example, you shouldenter the number 1283.4 as 1283.4D+00 or 1283.4E+00 or 1.2834D+03 or1.2834E+03 (but not as 1283.4). You might find that GALLOP won’t com-plain if you enter 1283.4, but that doesn’t mean everything is working OK!

The GALLOP input file ends on the first line with %END in the VARI-ABLE NAME column. The percent sign (%) is necessary. You could putsomething on the lines after the %END line, but GALLOP will just ignore it.

5.1 Parameters in the GALLOP Input File

As described above, parameters get set to the value given in the input fileand then don’t get changed for the remainder of the run.

Some parameters don’t have units. In that case, I just put an asterisk(*) in the corresponding UNITS column (GALLOP never uses the string inthe UNITS column anyway).

Parameters never have lower or upper bounds, so I just put an asterisk(*) in their LOWER BOUND and UPPER BOUND columns.

Now I’ll go through the GALLOP parameters in alphabetical order. Foreach parameter, I give the name, an explanation, the assumed units (if any),and typical values.

There are some optional GALLOP parameters that are not discussedbelow. The optimization variable transformation parameters are discussedin Section 5.3. The GALLOP parameters associated with using multipleengines are described in Chapter 6.

Remember:

When entering non-integer numerical values into a GALLOPinput file, you should always enter them in scientific notation. Forexample, you should enter the number 1283.4 as 1283.4D+00 or1283.4E+00 or 1.2834D+03 or 1.2834E+03 (but not as 1283.4).You might find that GALLOP won’t complain if you enter 1283.4,but that doesn’t mean everything is working OK!


5.1.1 beta(1) through beta(4)

(Solar Array Time Degradation Model Parame-ters)

These coefficients are used when calculating the factor by which the solararrays have degraded due to the passage of time. See Appendix A for detailson how the time degradation factor is calculated.

The coefficients beta(1) through beta(4) do not need to be set in theGALLOP input file. If they are not set, then the default values (below) areassumed. The default values correspond to assuming that there is no timedegradation.

Assumed units: beta(1) is dimensionless, beta(2) is dimensionless, beta(3)has units of sec−1, and beta(4) has units of sec−1

Default values:

beta(1) = 1.0E+0

beta(2) = 0.0E+0

beta(3) = 0.0E+0

beta(4) = 0.0E+0

5.1.2 bodname(i)

(Name of the ith Body on the Mission)

bodname(i) is the name of the ith body on the mission, where i runs from1 to numbodies (numbodies is also a GALLOP parameter). bodname(1) isthe launch body and bodname(numbodies) is the final body on the mission.

For the ith body, bodname(i) and bodtype(i) are used to determine theMASL body number of that body. That MASL body number is then usedto look up ephemeris data for that body.

Assumed units: *

Typical values: mars, ceres, tempel 1


5.1.3 bodtype(i)

(Type of the ith Body on the Mission)

bodtype(i) is the type of the ith body on the mission, where i runs from1 to numbodies (examples of body type include planet and comet; see thecomplete list of allowed body types below). bodtype(1) is the type of thelaunch body and bodtype(numbodies) is the type of the final body on themission.

For the ith body, bodname(i) and bodtype(i) are used to determine theMASL body number of that body. That MASL body number is then usedto look up ephemeris data for that body.

Assumed units: *Allowed values:

asteroid

comet

planet

satellite

unnumbered asteroid

5.1.4 cm(1) through cm(5)

(Engine Mass Flow Rate Model Parameters)

These are coefficients used to calculate the mass flow rate m from a singleengine when it is given the input power P (assuming that P is between pmin

and pmax). The model used is:

m = cm(1) + cm(2)P + cm(3)P 2 + cm(4)P 3 + cm(5)P 4

where m is in kg/s and P is in kW.

Assumed units: cm(1) has units of kg/s, cm(2) has units of (kg/s)/kW, etc.Typical values:

cm(1) = 475.56E-09

cm(2) = 902.09E-09

cm(3) = 0.0E+0

cm(4) = 0.0E+0

cm(5) = 0.0E+0


5.1.5 ct(1) through ct(5)

(Engine Thrust Model Parameters)

These are coefficients used to calculate the thrust F from a single enginewhen it is given the input power P (assuming that P is between pmin andpmax). The model used is:

F = ct(1) + ct(2)P + ct(3)P 2 + ct(4)P 3 + ct(5)P 4

where F is in Newtons (N) and P is in kW.

Assumed units: ct(1) has units of N, ct(2) has units of N/kW, etc.Typical values:

ct(1) = -1.9137E-03

ct(2) = 36.242E-03

ct(3) = 0.0E+0

ct(4) = 0.0E+0

ct(5) = 0.0E+0

5.1.6 dutycyc

(Engine Duty Cycle)

The duty cycle of all low-thrust engines (a number between zero and one).When an engine is on, this is the fraction of time that it actually spendsthrusting.

The duty cycle is used when calculating the maximum possible delta-v(∆vmax) that can be achieved on a particular segment:

∆vmax =F

mln

(

m0

m0 − m(dutycyc)t

)

where F is the total thrust on the segment, m is the mass flow rate on thesegment, m0 is the mass at the beginning of the segment, and t is the durationof the segment. (The above equation is the rocket equation.)

Assumed units: *Typical value: 1.0E+0


5.1.7 dvmag epsilon

(Fudge Factor Used when Calculating ∆v Mag-nitude)

If the ∆v vectors are represented internally using Cartesian coordinates (anoption described in section 5.1.8), then the magnitude of each ∆v vector iscalculated using the differentiable approximation:

∆vapprox =√

∆v2x + ∆v2

y + ∆v2z + (dvmag epsilon)

where dvmag epsilon is a parameter that is greater than zero and has thedimensions of velocity squared. ∆vapprox is always greater than the true ∆v.Since ∆vapprox is used to calculate the change in spacecraft mass (using therocket equation), the calculated change in spacecraft mass will always be abit larger than the true value. It is as if there is a mass leak.

If dvmag epsilon is increased, then the error in ∆vapprox increases, so onemight think that it is a good idea to make dvmag epsilon very small. Unfor-tunately, as dvmag epsilon is decreased, GALLOP takes longer to converge.There is a tradeoff between accuracy and convergence time.

Assumed units: km2/s2

Allowed values: dvmag_epsilon > 0Default value: 1.0D-10 km2/s2

5.1.8 dvparam

(Internal Parameterization of the ∆v Vectors)

Specifies the coordinate system that GALLOP should use to represent the∆v vectors internally : either spherical (magnitude, Theta, and Psi) orcartesian (∆vx, ∆vy, and ∆vz).

The initial guess and bounds on the ∆v vectors should always be enteredusing spherical coordinates. dvparam only controls their internal represen-tation during optimization.

When using Cartesian coordinates to represent the ∆v vectors (inter-nally), the magnitude of each ∆v vector is calculated using the differentiableapproximation:

∆vapprox =√

∆v2x + ∆v2

y + ∆v2z + (dvmag epsilon)


where dvmag epsilon is a parameter that is greater than zero and has thedimensions of velocity squared. (See section 5.1.7 for more information aboutdvmag epsilon.)

Assumed units: *Allowed values: spherical or cartesian

5.1.9 enc type(i)

(Encounter Type at Intermediate Body i)

enc_type(i) is the type of encounter (rendezvous or flyby) that occursat the ith intermediate body. (The intermediate bodies are the ones inbetween the launch body and the final destination body. i ranges from1 to numbodies-2.)

If enc_type(i) is a rendezvous, then the arrival and departure V-infinityfrom that body will be zero. (For an intermediate rendezvous, the flybyaltitude and B-plane angle are meaningless, but they must still be includedin the optimization variables.)

If enc_type(i) is a flyby, then a gravity-assist maneuver is assumed tooccur at the ith intermediate body.

An enc_type(i) line does not have to appear in the GALLOP inputfile. When a enc_type(i) line is not present, the default value of flyby isassumed.

Assumed units: *Default value: flybyAllowed values: flyby or rendezvous

5.1.10 inf flag

(String Used to Represent Infinity)

This is a text string that is used to signify ∞ (infinity) throughout theinput file. For example, if you wanted to say that a certain optimizationvariable has no upper bound, then your would put the infinity flag in itsUPPER BOUND column. Similarly, if you wanted to say that a certainoptimization variable has no lower bound, you would put the infinity flagpreceded by a minus sign in its LOWER BOUND column.


Assumed units: *Typical value: inf

5.1.11 kt

(Tankage Factor)

GALLOP maximizes the net mass of the spacecraft, which is defined as:

net mass = (final mass) − (tankage mass)

= (final mass) − kt(propellant mass)

= (final mass) − kt [(final mass) − (initial mass)]

= (1 − kt)(final mass) + kt(initial mass)

where kt = kt is known as the tankage factor.Therefore, if kt = 1.0, GALLOP maximizes the initial mass and if kt is

very, very large (like 1.0D+10), GALLOP minimizes the propellant mass.

Assumed units: *Default value: 0.0D+0Allowed values: kt ≥ 0.0D + 0

5.1.12 legtofbds(i)

(Bounds on the TOF of leg i)

The lower and upper bounds on the time of flight of the ith leg (where i rangesfrom 1 to numlegs).

A legtofbds(i) line doesn’t need to appear in the GALLOP input file.As with a tofbounds line (see subsection 5.1.27), the lower and upper

bounds appear in the LOWER BOUND and UPPER BOUND column, re-spectively. GALLOP ignores the VALUE column in all legtofbds lines.

If you want leg k to have a particular time of flight, then set the lowerand upper bounds equal to that time of flight on a legtofbds(k) line.

By setting the lower bound on a leg’s TOF to zero, one forces the en-counter bodies to be encountered in chronological order.

If no legtofbds lines appear in the GALLOP input file, then no linearconstraints get set up to constrain leg TOF’s. If one or more legtofbds lines


appear in the GALLOP input file, then a linear constraint gets set up for

each leg, regardless of whether there is a legtofbds line for each leg. Defaultleg TOF bounds are used for the legs without a legtofbds line.

Assumed units: days

Default lower bound: 0.0D+0

Default upper bound: inf

5.1.13 mass drop(i)

(Mass Drop at Intermediate Body i)

mass_drop(i) is how much the mass of the spacecraft decreases at the ith

intermediate body encounter. (The intermediate bodies are the ones in be-tween the launch body and the final destination body. i ranges from 1 tonumbodies-2.)

A mass drop is typically used to model the drop in mass due to the use ofpropellant for spiralling-in and spiralling-out at an intermediate rendezvous.mass_drop(i) can be negative if there is a net mass gain (which may happenif there is a sample picked up at the body).

A mass_drop(i) line does not have to appear in the GALLOP input file.When a mass_drop(i) line is not present, the default value of 0.0D+0 kg isassumed.

Assumed units: kg

Default value: 0.0D+0

Typical value: 40.0D+0

5.1.14 minstaytim(i)

(Minimum Stay Time at Intermediate Body i)

minstaytim(i) is the minimum stay time allowed at the ith intermediatebody encounter. (The intermediate bodies are the ones in between the launchbody and the final destination body. i ranges from 1 to numbodies-2.)

Since it only makes sense for there to be a minimum stay time when theencounter is a rendezvous, GALLOP will give you an error message if the ith

intermediate body encounter is a flyby and minstaytim(i) is not 0.0D+0.


A minstaytim(i) line does not have to appear in the GALLOP inputfile. When a minstaytim(i) line is not present, the default value of 0.0D+0days is assumed.

Assumed units: daysDefault value: 0.0D+0Typical value: 100.0D+0

5.1.15 nsegbp(i)

(Number of Segments Before the Breakpoint onLeg i)

nsegbp(i) is the number of segments before the breakpoint on the ith legof the mission (i ranges from 1 to numbodies-1). See reference [1] for moreinformation on the meaning of breakpoints.

I typically choose the breakpoint to be right in the middle of each leg.For example, if nsegleg(2)=24 then I would choose nsegbp(2)=12. If thenumber of segments on a leg is an odd number, you should still choose nsegbpto be an integer.

Assumed units: *Typical value: 20

5.1.16 nsegleg(i)

(Number of Segments on Leg i)

nsegleg(i) is the number of segments on the ith leg of the mission (i rangesfrom 1 to numbodies-1).

I typically choose the number of segments on a leg such that each segmenton that leg has a duration of about eight days or so (the segment durationscan vary during a run because the times at the bodies can vary). You willwant shorter segments when the spacecraft is moving fast (in the inner solarsystem) and fewer segments when the spacecraft is moving slowly or notthrusting at all (in the outer solar system).

Assumed units: *Typical value: 40


5.1.17 numbodies

(Number of Bodies on the Mission)

The total number of bodies that are involved with the mission, including thelaunch body and the destination body. If a body is encountered more thanonce, then it is counted again on each encounter. Another way to definenumbodies is to say that it is the number of legs on the mission plus one.For example, a four-leg mission launching at Earth, flying by Venus, Earth,and Jupiter, and arriving at Neptune has numbodies=5.

Assumed units: *

Typical value: 3

5.1.18 optimizer

(Name of the Optimizer to Use)

The is the name of the optimization program to be used. At the time ofwriting, only NPOPT was available.

Assumed units: *

Typical value: NPOPT is currently the only option.

5.1.19 p0

(Reference Solar Array Power)

The reference power produced by the solar arrays. p0 is typically equal tothe power generated by the solar arrays when the spacecraft is at 1 AU andtime t = 0. See Appendix A for more details.

Assumed units: kW

Typical value: 7.0E+0


5.1.20 pmax and pmin

(Minimum-Needed and Maximum-AllowedEngine Power)

GALLOP assumes that all of the low-thrust engines are of the same type.Two characteristics of the engines are the minimum power needed to turnone on (pmin) and the maximum power usable by one engine (pmax).

Chapter 6 discusses how pmin and pmax affect the power delivered tomultiple engines.

Assumed units: kWTypical values:

pmin = 0.649E+0

pmax = 2.600E+0

5.1.21 r cutoff

(Radius above which Power Equals Zero)

When the distance r from the Sun to the spacecraft is greater than or equalto r cutoff, the relative power from the solar arrays is zero (and hencethe power generated by the solar arrays is zero). See Appendix A for moredetails.

An r cutoff line does not need to appear in the GALLOP input file. Ifone does not apppear, then the default value of 1.0D+20 AU is assumed.

Assumed units: AUDefault value: 1.0D+20 (effectively infinity)

5.1.22 r max

(Radius above which Solar Array RelativeEfficiency is Constant)

When the distance r from the Sun to the spacecraft is greater than or equal tor max, the relative efficiency of the solar arrays is constant. See Appendix Afor more details.

An r max line does not need to appear in the GALLOP input file. If onedoes not apppear, then the default value of 5.0D+0 AU is assumed.


Assumed units: AUDefault value: 5.0D+0

5.1.23 r tilt

(Radius below which Solar Array RelativePower is Constant)

When the distance r from the Sun to the spacecraft is less than or equal to rt,the relative power generated by the solar arrays is constant. The parameterrt is called the “tilt radius” and it is usually equal to r tilt. However, ifthe function [η(r)/r2] has a maximum somewhere between r tilt and 1 AU,then rt is at the location of that maximum. See Appendix A for more details.

An r tilt line does not need to appear in the GALLOP input file. Ifone does not apppear, then the default value of 0.7D+0 AU is assumed.

Assumed units: AUDefault value: 0.7D+0

5.1.24 sa(1) through sa(5)

(Solar Array Relative Efficiency Model Param-eters)

These coefficients are used when calculating the relative efficiency of thesolar arrays (as a function of temperature, which is a function of r). SeeAppendix A for details on how relative efficiency is calculated.

Assumed units: sa(1) is dimensionless, sa(2) has units of AU, sa(3) hasunits of AU2, sa(4) has units of AU−1, and sa(5) has units of AU−2

Typical values:

sa(1) = 1.1063E+0

sa(2) = 149.5E-3

sa(3) = -299.0E-3

sa(4) = -43.2E-3

sa(5) = 0.0E+0


5.1.25 scp

(Power Used by Spacecraft)

The amount of power that is used by the spacecraft for purposes other thanpowering the engine(s). See Appendix A for more details.

Assumed units: kWTypical value: 0.0E+0

5.1.26 solfile

(Name of Solution File)

The name of the solution file written by GALLOP once the optimization runterminates. See Section 7.1 for more information about GALLOP solutionfiles.

Assumed units: *Typical value: EMC_inp1_sol

5.1.27 tofbounds

(Bounds on the Mission TOF)

The lower and upper bounds on the total mission time of flight (TOF). (Thetotal mission TOF is defined as the time between the first mission body andthe last mission body.)

A tofbounds line doesn’t need to appear in the GALLOP input file. Infact, if you don’t want to constrain the TOF, then you should not have atofbounds line in your GALLOP input file.

A tofbounds line is a bit different from the lines that set other GALLOPparameters. The lower and upper bounds appear in the LOWER BOUNDand UPPER BOUND columns, rather than in the VALUE column. GAL-LOP ignores the VALUE column on the tofbounds line.

If you want the solution trajectory to have a desired TOF, then set thelower and upper bounds equal to the desired TOF.

Assumed units: daysDefault lower bound: 0.0D+0


Typical lower bound: 0.0D+0Typical value: *Default upper bound: infTypical upper bound: 1200.0D+0

5.1.28 trajtype

(Trajectory Type: rendezvous or flyby)

The trajectory type—either a rendezvous or a flyby. A rendezvous missionarrives at the final body with the same velocity as the body (so it can gointo orbit of that body or land on it). A flyby mission flies by the final body.Rendezvous missions usually require more propellant.

Assumed units: *Allowed values:

rendezvous

flyby

5.2 Optimization Variables in the GALLOP

Input File

The optimization variables are the GALLOP variables with names of theform x(i), where i is an integer. Optimization variables get initialized tothe values in the GALLOP input file, but GALLOP can vary them duringthe course of the run.

A lower and an upper bound should be specified for all optimizationvariables (so never put an asterisk instead of a value). If an optimizationvariable doesn’t really have any upper bound, then you should set its upperbound to infinity by putting the symbol for infinity in its upper bound column(see the description of the inf_flag parameter in the previous section).Similarly, if an optimization variable really doesn’t have any lower bound,then you should set its lower bound to negative infinity by putting the symbolfor negative infinity in its lower bound column (the minus sign character (-)followed by the symbol for infinity).

Also remember:

5.2. OPTIMIZATION VARIABLES IN THE GALLOP INPUT FILE 45

When entering non-integer numerical values into a GALLOPinput file, you should always enter them in scientific notation. Forexample, you should enter the number 1283.4 as 1283.4D+00 or1283.4E+00 or 1.2834D+03 or 1.2834E+03 (but not as 1283.4).You might find that GALLOP won’t complain if you enter 1283.4,but that doesn’t mean everything is working OK!

There are many different kinds of optimization variables. The differentkinds of optimization variables always occur in the same order in the x()

array. I use another array called n() to keep track of the indices where eachkind of variable starts and ends. Table 5.2 summarizes the different kinds ofoptimization variables in the x() array and the order in which they occur.

[Note: totsegs is the total number of segments on the mission. numbodiesis the total number of bodies on the mission (including the first and last).nint is the number of intermediate flyby bodies (nint = numbodies - 2).]


Table 5.2: The Order of the Optimization Variables

Variables Start index End index

Magnitudes of the ∆v n(1)=1 n(2)=totsegs

vectors on thesegments [km/s]Theta angles of the ∆v n(3)=n(2)+1 n(4)=n(2)+totsegs

vectors on thesegments [deg]Psi angles of the ∆v n(5)=n(4)+1 n(6)=n(4)+totsegs

vectors on thesegments [deg]Julian dates at the n(7)=n(6)+1 n(8)=n(6)+numbodies

bodies [days]Launch v∞ [km/s] n(9)=n(8)+1 n(9)Theta of launch v∞ [deg] n(10)=n(9)+1 n(10)Psi of launch v∞ [deg] n(11)=n(10)+1 n(11)Incoming inertial vx at n(12)=n(11)+1 n(13)=n(11)+numbodies-1the bodies [km/s]Incoming inertial vy at n(14)=n(13)+1 n(15)=n(13)+numbodies-1the bodies [km/s]Incoming inertial vz at n(16)=n(15)+1 n(17)=n(15)+numbodies-1the bodies [km/s]Mass at the bodies [kg] n(18)=n(17)+1 n(19)=n(17)+numbodies

Flyby altitude at the n(20)=n(19)+1 n(21)=n(19)+nint

flyby bodies [km]B-plane angle at the n(22)=n(21)+1 n(23)=n(21)+nint

flyby bodies [deg]


5.2.1 The ∆v Vectors on the Segments

The thrusting on each segment is approximated by an impulsive ∆v in themiddle of the segment. All the ∆v vectors are parameterized in sphericalcoordinates as shown in Figure 5.1. The initial guesses and bounds on the ∆vvectors are given in the GALLOP input file using these spherical coordinates.

Psi

Theta

x

z

y

∆v

Figure 5.1: Spherical Coordinates for the ∆v Vector

The xyz coordinate frame corresponds to MASL ‘VECTOR standard co-ordinates’ (GALLOP uses MASL VECTOR standard coordinates through-out). The programmers and maintainers of the MASL library try to hidewhich coordinate system they actually use for ’VECTOR standard coordi-nates’. Nonetheless, I suspect that (at the time of writing) MASL ‘VEC-TOR standard coordinates’ correspond to Earth Mean Ecliptic and Equinoxof J2000:

• The x-direction is the direction from the Sun to the first point in Aries


on January 1, 2000 at 12:00:00 (Julian date 2451545.0 = ‘J2000 epoch’).

• The z-direction is the direction of Earth’s orbital angular momentumvector at J2000 epoch.

• The y-direction completes the right-handed coordinate frame. Thismeans that the xy-plane is Earth’s orbital plane (i.e. the ecliptic plane)at J2000 epoch.

You find initial guess values for the ∆v magnitudes, Thetas, and Psis eitherby translating an AUTO3 file (using SIT), using GWIZ, or by using yourastrodynamical instincts.

The numbers that you give for the lower/upper bounds on the ∆v mag-nitudes, Thetas, and Psis have an strong effect on the outcome of the opti-mization run, so I’ll go through each of them individually.

The lower bounds on the ∆v magnitudes can all be set to 0 km/s withoutany worries.

In principle, you should be able to set the upper bounds on the ∆vmagnitudes to infinity. The (nonlinear) power-availability constraints shouldkeep the ∆v magnitudes bounded, right?

The problem is that the optimizer can meet the (linear) upper boundconstraints with no problems, but it has a harder time satisfying the (non-linear) power-availability constraints. You will get infeasible solutions wherea few of the power-availability constraints are violated, but all of the ∆vmagnitudes are on (or below) their upper bounds.

The solution to this problem is to set the upper bounds on the ∆v mag-nitudes to values just barely above the values determined by the power-availability constraints. Where do you get those values? Put reasonableguesses into your GALLOP input file, run GALLOP, get a “solution” (prob-ably infeasible), and use GLOOK to make the plot of the ∆v magnitudes.The (nonlinear) power-availability constraints are shown on that plot2.

In theory, the bounds on the Theta and Psi angles could be set to plusand minus infinity. For certain problems, that might even work. After a lotof experimentation, I’ve found that the following bounds on the Thetas andPsis ’work good’:

• Theta between -360 degrees and 360 degrees.

2this process is an example of what I call ‘bootstrapping’.


• Psi between 2 degrees and 178 degrees.

The Psi angle is kept away from 0 degrees and 180 degrees because Thetais undefined there (on the z-axis). Such a “coordinate singularity” confusesthe optimizer.

Once you have found a final, optimized solution, you can feel free to openup the Psi constraints to [0,180] and run the optimizer one last time.

5.2.2 The Julian Dates at the Bodies

The Julian dates at the bodies are the times when the spacecraft is at eachbody in the mission (measured in days since January 1, 4713 B.C.). The firstJulian date in the x() vector is the Julian date at the launch body.

When you first set out to optimize a trajectory, I recommend that youfreeze all Julian dates (by setting the lower bound, initial guess, and upperbound equal). Once you get an “optimal solution found” with all the datesfrozen, then you can allow some (or all) of the dates to be free.

When Julian dates are free, you may find that changing the Julian datetransformation parameters improves optimizer performance (see section 5.3.4).

5.2.3 The Launch v∞

The launch v∞ is the velocity of the spacecraft relative to the launch bodyonce the spacecraft has once it has gotten sufficiently far away from thelaunch body on its escape hyperbola.

The coordinate system used for the launch v∞ vector is the same as thecoordinate system used for the ∆v vectors (see Figure 5.1).

The launch v∞ can be frozen or free. To freeze the launch v∞, set thelower and upper bound equal to the initial guess. If either the lower or upperbound of the launch v∞ is not equal to the initial guess, then the optimizeris free to vary the launch v∞ (within the bounds).

If the launch v∞ is free but the launch mass is frozen, then you will geta warning message when you run GALLOP, but it will let you continue theGALLOP run.

If you want to use a launch vehicle, then let the launch v∞ be free andspecify the launch vehicle you want to use in the column for the initial guess

of the initial mass (see subsection 5.2.5 on the spacecraft masses at the bodiesfor more details on how to use a launch vehicle).


I typically allow the Theta angle of the launch v∞ to vary between -180and 180 degrees. I also allow the Psi angle to vary between 0 and 180 degrees(I suppose I should only allow Psi to vary between 2 and 178 degrees, butI’m not too worried about the optimal launch v∞ being directly out of theecliptic plane!).

5.2.4 The Incoming Velocities at the Bodies

These are the incoming inertial velocities of the spacecraft at all the bodiesafter the launch body (i.e. the velocities relative to the Sun). They areparameterized in Cartesian coordinates with the same coordinate frame asall the other vectors (MASL VECTOR standard coordinates).

Note that the x-components of the velocities all come first in the x()

vector, then the y-components, and lastly the z-components. Their units arekm/s.

I have found that it doesn’t really matter how you set the bounds on theincoming velocities at the bodies. Feel free to set them to plus and minusinfinity.

Note that if the trajectory is a rendezvous trajectory, you don’t have to“force” a rendezvous by setting the upper and lower bounds on the arrivalvelocity equal to the arrival body’s velocity. GALLOP automatically setsthe arrival velocity at the final body to the velocity of the final body on thearrival date (i.e. when the trajectory is a rendezvous, the incoming velocitycomponents at the final body are not actually optimization variables—theydepend on the Julian date at the final body).

5.2.5 The Spacecraft Mass at the Bodies

These variables are the mass of the spacecraft at the mission bodies (includingthe launch body). The units are kg.

There are two options for the mass at the first body:

1. Frozen initial mass. Set the lower bound, initial guess, and upper boundequal.

2. Initial mass dependent on launch v∞ magnitude . Set the upper boundto infinity (by putting the symbol for infinity in the upper bound col-umn). Set the lower bound to minus infinity. In the column where the


initial guess (number) would normally go, put the string lv followedby the number of the launch vehicle.

For example, you might put the string lv32 in the initial guess columnfor the initial mass. This tells GALLOP that you want to use launch vehicle32 to determine how the initial mass depends on the launch v∞ magnitude.GALLOP will look for a file named lv32.params in the directory stored inthe environment variable LVPATH.

Appendix C lists the launch vehicles available in GALLOP and containsplots showing how the initial mass depends on the launch v∞ magnitude forvarious launch vehicles.

The bounds on the masses at the bodies after the first body can be setto 0 kg for the lower bound and some suitably large number for the upperbound (like the initial mass if the initial mass is frozen).

There is a Matlab function named M0 which can compute the initial massgiven the launch v∞ magnitude and the launch vehicle. See Appendix C formore information.

5.2.6 Flyby Altitude at the Flyby Bodies

These variables are the flyby periapsis radius minus the body radius at allthe intermediate flyby bodies. The units are km. If the mission only has twobodies (i.e. the launch body and the destination body), then these variablesdo not occur in the x() vector.

The lower bound should be set to some sensible value (like 200.0E+0 kmwhen flying by Mars or 300.0E+0 km when flying by Earth). The upperbound can be set to infinity.

If the ith intermediate body is an intermediate rendezvous, then you muststill have an optimization variable x(i) in the GALLOP input file for theflyby altitude at that body, even though it is meaningless and GALLOP justignores it. It acts as a placeholder. See the descriptions of the GALLOP in-put parameters enc_type(i), minstaytim(i), and mass_drop(i) for moreinformation about intermediate rendezvous.

5.2.7 B-plane Angle of Flyby at the Flyby Bodies

These variables are the Flyby B-plane angles at the intermediate flyby bodies.The units are degrees. If the mission only has two bodies (i.e. the launch


body and the destination body), then these variables do not occur in the x()vector.

While we’re on the topic, let’s recall how the B-plane angle is defined:

• The B-plane is the plane that is perpendicular to the incoming v∞

vector and passes through the flyby body’s gravitating center.

• The B vector originates at the flyby body’s gravitating center and ex-tends out to where the spacecraft’s incoming v∞ asymptote puncturesthe B-plane.

• The T vector is a vector that lies in both the B-plane and the eclipticplane (Earth’s orbital plane at the J2000 epoch). If N is the “celestialNorth” vector (perpendicular to the ecliptic plane), then the T vectoris defined as:

T = v∞ × N

• The B-plane angle is the angle between the T vector and the B vector(in the right-hand sense with respect to the incoming v∞ vector).


T

B−planeangle

Flybybody

B−plane

Line where the

intersects theB−plane

Incoming v−infinity vector

B

J2000 eclipticplane

Figure 5.2: The B-plane angle


If the B-plane angle is between 0 and 180 degrees, then we can say thatthe flyby target point (at the tip of the B vector) is “under the eclipticplane”. Similarly, if the B-plane angle is between -180 and 0 degrees, thenwe can say that the target point is “above the ecliptic plane”.

I typically let the bounds on the B-plane angle be plus and minus infinity(i.e. no bounds at all).

If the ith intermediate body is an intermediate rendezvous, then you muststill have an optimization variable x(i) in the GALLOP input file for theflyby B-plane angle at that body, even though it is meaningless and GALLOPjust ignores it. It acts as a placeholder. See the descriptions of the GAL-LOP input parameters enc_type(i), minstaytim(i), and mass_drop(i)

for more information about intermediate rendezvous.

5.3 Optimization Variable Transformations

GALLOP reads the input file to get the initial guess of the optimizationvariables. The values of these variables can vary widely in order of magnitude.For example, angles typically range from zero to 360 degrees (order 100),whereas Julian dates are typically on the order of 1 million.

Optimization software generally works better if all the optimization vari-ables are of the same order of magnitude. Therefore, GALLOP actuallytransforms the initial guesses of the optimization variables into new “inter-nal optimization variables” that are all on the order of 1 (one). The optimizerworks with these internal optimization variables. Once a solution is found,it is transformed back into regular units for the solution file.

The transformations used to translate the optimization variables into in-ternal optimization variables are summarized below. Each transformationhas parameters associated with it. Those transformation parameters all havesensible default values, but they can (optionally) be set in the GALLOP in-put file.

5.3.1 The ∆v Magnitude Transformation

The ∆v magnitudes are all transformed into internal ∆v magnitudes by:

∆vinternal =∆v

dvmasf

where dvmasf is a scaling factor with a default value of 0.2 km/s.

5.3. OPTIMIZATION VARIABLE TRANSFORMATIONS 55

5.3.2 The Angle Transformations

There are a number of GALLOP optimization variables that are angles:

• The Psi and Theta angles of the ∆v vectors on the segments.

• The Psi angle and Theta angle of the launch v-infinity.

• The B-plane angle at the flyby bodies.

All angles are transformed into internal angles by:

angleinternal =angle

anglesf

where anglesf is a scaling factor with a default value of 180/π (so that allangles are represented internally in radians by default).

5.3.3 The Cartesian ∆v Transformations

If you have asked GALLOP to use Cartesian coordinates for its internalparameterization of the ∆v’s,3 then the x-, y-, and z-components of each∆v are transformed into internal values by:

∆vx,internal =∆vx

dvxsf

∆vy,internal =∆vy

dvysf

∆vz,internal =∆vz

dvzsf

where dvxsf, dvysf, and dvzsf are scaling factors with default values of 0.1km/s, 0.1 km/s, and 0.01 km/s, respectively.

3This is done by setting the GALLOP parameter dvparam to cartesian. See Sec-tion 5.1.8 for more information.


5.3.4 The Julian Dates Transformations

Each Julian date is transformed into an internal optimization variable by itsown transformation equation. If jd(i) is the Julian date at the ith body(where i=1 at the launch body), then the internal Julian date jd(i)internal

is calculated using:

jd(i)internal = jdsf(i)) × (jd(i) − jdref(i))

where jdref(i) is the ith reference date and jdsf(i) is the ith Julian datescaling factor. Their default values are:

jdref(i) = 2, 451, 544.5 = Jan. 1, 2000

jdsf(i) =1

365.25

(The default reference date and scaling factor allow you to interpret thedefault internal Julian dates as “years since Jan. 1, 2000”.)

5.3.5 The Launch v∞ Magnitude Transformation

The launch v∞ magnitude is transformed into an internal launch v∞ magni-tude by:

v∞ launch, internal =v∞ launch

vinflnsf

where vinflnsf is a scaling factor with a default value of 1.0 km/s.

5.3.6 The Transformation of the Velocities at theBodies

The inertial spacecraft velocity at each of the post-flyby bodies is transformedaccording to:

vx internal =vx

vxbodysf

vy internal =vy

vybodysf

vz internal =vz

vzbodysf

5.4. TRANSLATING AUTO3 FILES INTO GALLOP INPUT FILES 57

where vxbodysf, vybodysf, and vzbodysf are scaling factors. Their defaultvalues are:

vxbodysf = 20 km/s

vybodysf = 20 km/s

vzbodysf = 0.1 km/s

5.3.7 The Spacecraft Mass Transformation

The spacecraft mass the bodies is transformed according to:

minternal =m

mbodysf

where mbodysf is a scaling factor with default value being the initial guessof the mass of the spacecraft at the launch body.

5.3.8 The Flyby Altitude Transformations

The flyby altitude hi at the ith flyby body is transformed into an internaloptimization variable hi, internal using:

hi, internal = 1 +hi

fbaltsf(i)=

fbaltsf(i) + hi

fbaltsf(i)

where fbaltsf(i) is a scaling factor with default value being the radius ofthe ith flyby body (so the default meaning of hi, internal is “the flyby radiusin planetary radii”).

5.4 Translating AUTO3 Files into

GALLOP Input Files

STOUR-LTGA can produce output files known as AUTO3 files. These filescan be translated into complete GALLOP input files using a function of theSTOUR-LTGA Interactive Toolkit (SIT). (For more information on SIT, seethe SIT User’s Guide.)

AUTO3 files can contain information about several different trajectories,so it is important that you know at least some information about the tra-jectory you want. Specifically, the launch date, total time of flight, launch


v-infinity and arrival v-infinity vectors are useful. If you have used the otherfunctions of SIT to pick your trajectory and/or create the STOUR-LTGAinput file used to generate the AUTO3 file, this should be fairly straightfor-ward.

To launch SIT, simply type sit at the MATLAB command line (as longas your path includes the directory in which SIT and its associated scriptsreside). Upon initialization, the main menu appears:

STOUR LTGA Trajectory Analysis

*********************************************************************

* *

* 1) Convert an STOUR AUTO1 file to .mr (machine readable) format *

* 2) Load data from a .mr file into memory *

* 3) Run cost function evaluator on data in memory *

* 4) Run GRaphical Interactive Plotting (GRIP) tool *

* 5) Create a new STOUR input file for an AUTO3 run *

* 6) Convert an STOUR AUTO3 file to a GALLOP input file *

* 7) Quit *

* *

*********************************************************************

Please choose an option from above:

As you’ve probably guessed, you want option number 6.Next, you’ll be asked for the name of the AUTO3 file that contains the

data for your desired trajectory. The filename defaults to plain old ’AUTO3’.Now enter the name that you want your GALLOP input file to have. You’llprobably want to change it from the default ’GALLOP in’ to something moreindicative of your work.

If the AUTO3 filename you enter does not exist, or if it contains noproperly formatted data, you will be sent back to the main menu. If yourtarget input file already exists, you will be given the option to cancel theoperation so as to avoid overwriting it.

If your AUTO3 file contains more than one trajectory, a list of all of theavailable trajectories, along with several of their properties will appear. Thisis why it was important to note the launch date, time of flight, launch andarrival v-infinities before. Simply pick your trajectory from the presentedlist.

5.5. THE GALLOP WIZARD (GWIZ) 59

From this point on, you will be prompted for data goes into the GALLOPinput file. This data includes:

• The desired name of the GALLOP solution file

• Whether you want the trajectory to end in a rendezvous or a flyby

• The names of all of the bodies in the mission (including the launchbody)

• An initial mass or launch vehicle number for your mission

Once you’ve entered everything, SIT does the rest. Your GALLOP inputfile will be written to your active directory, and you’re ready to gallop!

5.5 The GALLOP Wizard (GWIZ)

In the olden days, if you wanted to create a GALLOP input file from scratch,you had to open up a text editor and enter everything manually, being verycareful to have a properly-formatted GALLOP input file. What drudgery!

Nowadays, there is a helpful program called the GALLOP Wizard whichmakes generating a new GALLOP input file much easier. (The GALLOPWizard is also known as GWIZ, which is pronounced JEE-whiz.) GWIZasks you a series of questions and then uses the answers to write the inputfile for you. Most of the questions have default answers, which saves a lot oftyping. (You just enter the letter d in order to accept a default answer.)

In order to use GWIZ, you must have a very good idea about how youwant your new GALLOP input file to look. For example, you must knowthe encounter dates at the bodies. If you give nonsense to the GALLOPWizard, then you can expect nonsense in your new GALLOP input file (i.e.“garbage-in, garbage-out”).

To run GWIZ, just go to the directory where you want to create the newGALLOP input file and type

> gwiz

at your UNIX prompt (The gwiz executable has the same path as the gallopexecutable, so if you can run GALLOP, you should be able to run GWIZ).GWIZ will run and you should see something like this in your window:


==============================

G-WIZ 3.0 (June 2002)

==============================

Hello. I am the GALLOP Wizard (GWIZ).

I will help you create a new GALLOP input file by

asking you a series of questions.

Whenever I give default values, you can accept

the default value by entering the letter d.

What would you like to call your new GALLOP input file?

Now you just answer the questions. GWIZ will dutifully use the answersto create a new GALLOP input file for you. A complete session with GWIZis given in Appendix D.

In order to keep the number of questions to a minimum, GWIZ makes anumber of assumptions. These assumptions are listed below. It is importantto keep these assumptions in mind, because they may be incorrect for yourparticular trajectory. In other words, once GWIZ is done, you may need toopen up your new input file in a text editor and change a few things.

Assumptions Made by GWIZ

• The flag for infinity is inf (so the flag for negative infinity is -inf).

• Each leg must have at least two segments. If you enter a huge numberfor the duration of the segments on a leg, it will put two segments onthat leg.

• The number of segments before the breakpoint will be roughly half thenumber of segments on the leg.

• The lower bound on all Delta-V magnitudes is 0.0D+0 km/s. The upperbound is estimated using the maximum thrust, the segment duration,and an approximation of the spacecraft mass.

5.5. THE GALLOP WIZARD (GWIZ) 61

• The bounds on the theta angles are set to [-360.0D+0, 360.0D+0]

degrees.

• The lower bound on all psi angles is 2.0D+0 degrees. The initial guessfor all psi angles is 90.0D+0 degrees. The upper bound on all psi anglesis 178.0D+0 degrees. (The psi angles are kept away from 2◦ and 180◦

because the theta angles loose meaning there, which can cause problemswith the optimizer.)

• The bounds on the Julian dates are set equal to the initial guesses ofthe Julian dates (i.e. frozen dates).

• The upper and lower bound on the launch V-infinity are set equal tothe launch V-infinity (i.e. frozen launch V-infinity).

• The bounds on the launch V-infinity theta (in-plane angle) are [-180.0D+0,180.0D+0] degrees.

• The bounds on the launch V-infinity psi (angle from celestial North)are [0.0D+0, 90.0D+0] degrees.

• The bounds on the incoming inertial velocities at the bodies are set to-inf and inf (i.e. unbounded).

• The bounds on the initial mass equal the initial guess of the initialmass (i.e. frozen initial mass).

• The bounds on the spacecraft mass at the bodies after the launch bodyare [0.1D+1 kg, mi] (where mi is the spacecraft mass at body i).

• The upper bound on the flyby altitudes is set to inf (i.e. not boundedabove).

• The bounds on the B-plane angles are set to -inf and inf (i.e. un-bounded).

GWIZ uses a very heuristic method of finding initial guesses for the space-craft incoming inertial velocities at the bodies. For each body, GWIZ firstlooks up the velocity vector of the body on the encounter date. Then, foreach body encounter, GWIZ asks:


Is this encounter:

(o)utgoing,

(i)ncoming,

(r)endezvous,

tangential with s/c (s)lower than the planet, or

tangential with s/c (f)aster than the planet?

(Enter o, i, r, s, or f)

Here is what these five options mean:

• (o)utgoing: Initial guess velocity vector = 1.3 times the planet veloc-ity vector rotated away from the Sun by 0.26 radians (15 degrees).

• (i)ncoming: Initial guess velocity vector = 1.3 times the planet ve-locity vector rotated towards the Sun by 0.26 radians (15 degrees).

• (r)endezvous: Initial guess velocity vector = planet velocity vector.

• tangential with s/c (s)lower than the planet: Initial guess veloc-ity vector = 0.7 times planet velocity vector.

• tangential with s/c (f)aster than the planet: Initial guess velocityvector = 1.3 times planet velocity vector.

WARNING: This method of getting an initial guess of theincoming inertial velocities is highly heuristic. The resulting ini-tial guess is often quite bad. To get a better initial guess, youcan use QUICK to do a Lambert fit, for example.

Chapter 6

Using Multiple Engines

6.1 Overview

A spacecraft may have many low-thrust engines. In general, each enginemight be different, but GALLOP assumes they are all the same. More specif-ically, GALLOP assumes that all the engines have the same cm, ct, pmin,pmax and dutycyc parameters.

When the spacecraft is at a given distance from the Sun, there is a knownamount of power available to be used by the engines. In principle, that powercan be distributed freely to any of the engines. One engine might get nothing.Another might get 0.76 kW and another might get 1.33 kW. Of course, eachengine cannot accept less than pmin kW or more than pmax kW. Also, theavailable power doesn’t have to be used up by the engines. It might beoptimal to have all the engines off, even if it is possible to operate them.Figure 6.1 illustrates the power-allocation situation.

For each segment, we’d like to allocate the available power to the enginesin such a way as to maximize the final mass of the spacecraft. Considerthe special case when there are just two engines. We first must decide howmany engines to turn on. There are three choices: 0, 1 or 2. If there are100 segments (which is not unusual), then there are 3100 ≈ 5× 1047 differentways to choose the number of engines to operate on all the segments! Evenworse, every time we choose to operate one or two engines on a segment, wemust also choose how much power to allocate to each operating engine. It’sjust not feasible to try out all the possibilities in order to find the one whichresults in the largest final mass.

63

64 CHAPTER 6. USING MULTIPLE ENGINES

Engines

power

Unused powerpmin

pmax

Available

Figure 6.1: The engine power-allocation situation

GALLOP uses heuristic rules to decide how much power to allocate toeach engine (as a function of the available power). Currently, the user canchoose between two different heuristic rule sets: max power and max thrust.The rules in those rule sets are listed in section 6.2.2.

When doing preliminary optimization, it is often useful to treat n engineslike one big super-engine. GALLOP has a parameter called e truthfactor

which allows the user to do this easily. When e truthfactor = 0.0D+0, theengines behave like one big super-engine and when e truthfactor = 1.0D+0,the engines are treated as separate. Values between 0.0D+0 and 1.0D+0 arealso allowed. The e truthfactor is explained further in section 6.2.3.

One useful way to think about the engine paramters is to view them asdetermining the forms of the two functions

FTotal(Pav)

mTotal(Pav)

where Pav is the power available to the engines, FTotal is the total thrustfrom all operating engines, and mTotal is the total mass-flow rate from all theoperating engines.

These two functions (FTotal(Pav) and mTotal(Pav)) always have disconti-nuities. That is, a small change in the available power Pav causes a large

6.2. MULTIPLE-ENGINE INPUT PARAMETERS 65

change in the function for certain values of Pav. Optimizers have difficultieswith discontinuous functions, so GALLOP has a parameter, e sharpness

which controls the sharpness of the discontinuities. The e sharpness is ex-plained further in section 6.2.4. Example plots of FTotal(Pav) and mTotal(Pav)are given in section 6.3.

6.2 Multiple-Engine Input Parameters

There are four GALLOP input parameters associated with using multiple en-gines: numengines, alloc rules, e truthfactor, and e sharpness. Theyall have default values so they don’t have to be set in the GALLOP inputfile.

6.2.1 numengines

(Number of engines operable)

A comma-delimited list of the number of engines that could potentially beoperated. For example, if

numengines = 1,2,4

then the spacecraft can operate either 1, 2, or 4 engines simultaneously (butnever 3, 5, 6, or more). If

numengines = 3

then the spacecraft can only operate exactly 3 engines (but not 1, 2, 4,or more). If a numengines line doesn’t appear in the GALLOP input file,then GALLOP assumes that exactly one engine is available to be operated.The entries in the numengines list must occur in increasing order, otherwiseGALLOP will give an error message.

Assumed units: *Typical values:

1

2


1,2

1,2,3

2,4

Default value: 1

6.2.2 alloc rules

(Heuristic power-allocation rules)

This parameter selects the heuristic rule set to be used by GALLOP whendeciding how much of the available power should be allocated to each engine.Currently, there are two rule sets available:

The max power rule set

1. All operating engines receive equal power.

2. The number of operating engines, Non, is that which maximizes thetotal power used by the engines.

3. If there are multiple choices of Non which maximize the total powerused by the engines, then choose the smallest one.

The max thrust rule set

1. All operating engines receive equal power.

2. The number of operating engines, Non, is that which maximizes thetotal thrust from all engines.

3. If there are multiple choices of Non which maximize the total thrust,then choose the one that minimizes the total mass-flow rate.

Assumed units: *

Allowed values: max_power, max_thrust

Default value: max_power

6.2. MULTIPLE-ENGINE INPUT PARAMETERS 67

6.2.3 e truthfactor

(Engines truthfactor)

When e truthfactor = 0.0D+0, the total thrust and mass-flow rate in-crease linearly with the available power (in the range where they vary). Thismakes the engines appear to operate like one single super-engine. Whene truthfactor = 1.0D+0, the total thrust and mass-flow rate depend on theavailable power in a complicated way (generally speaking), as determined bythe power-allocation heuristics. This is known as the “truth model.” Thee truthfactor can also take values between 0.0D+0 and 1.0D+0.

Section 6.3 explains how you can generate a plot that shows how the totalthrust depends on the available power for the super-engine, the truth model,and the user model. A similar plot can be generated for the total mass-flowrate.

Assumed units: *Allowed values: Any real number in the interval [0, 1]. (For the super-engine,use e truthfactor = 0.0D+0. For the “truth model”, use e truthfactor

= 1.0D+0.)Default value: 1.0D+0

6.2.4 e sharpness

(Sharpness of the engine thrust and mass-flowrate functions)

The total thrust and total mass-flow rate (which are functions of the availablepower) often have many discontinuities. Since optimizers generally have diffi-culties with discontinuous functions, GALLOP smoothes the discontinuitiesby replacing step functions with smoothed-out step functions. Figure 6.2illustrates the basic smoothed step function used by GALLOP. It has theform:

f(Pav) =

0 if Pav ≤ −a1 if Pav ≥ ap(Pav) otherwise

where p(Pav) is the unique fifth-degree polynomial satisfying

p(−a) = 0


p(a) = 1

p′(−a) = 0

p′(a) = 0

p′′(−a) = 0

p′′(a) = 0

That is, f(Pav), f ′(Pav), and f ′′(Pav) are continuous at −a and a.

−2 −1.5 −1 −0.5 0 0.5 1 1.5 2−0.5

0

0.5

1

1.5

Pav

f(P av

)

−a a

Figure 6.2: Smoothed step function when a = 1.0

The width of the transition interval is 2a. GALLOP calculates a frome sharpness using the formula:

a =1

(e sharpness) + 0.1

so that (roughly speaking) the width of the transition interval is inversely pro-portional to e sharpness. (The 0.1 is added to the denominator to prevent a

6.3. TESTING THE ENGINES 69

division by zero error when e sharpness = 0.0D+0.) When e sharpness =0.0D+0, the transition width is 20 kW, which is probably much larger thananyone will ever want. If e sharpness is set large enough, the transitionwidth becomes smaller than the numerical precision of the computer, so thesmooth step function becomes a discontionuous step function (effectively).

Assumed units: *Allowed values: Any real number greater than or equal to 0.0D+0. Infinityis not allowed.Default value: 10000.0D+0

6.3 Testing the Engines

There is a MATLAB script called read engine tests.m which allows youto make nice plots that show, for example, how the total thrust depends onthe available power.

To use read engine tests.m, you first need to generate some engine testdata files. Those files are created by adding ’te’ to the GALLOP commandline, as in:

> cat specs | gallop i=myinfile te

(The ’te’ stands for “Test Engines”.)You should get some output telling you that certain files are being created

or replaced, then GALLOP will stop without doing any optimizing.With the engine test data files created, you are ready to use

read engine tests.m. Load MATLAB and make sure read engine tests.m

is in the MATLAB path. (To check the MATLAB path, use the MATLAB“path” command. To add a directory to the MATLAB path, use the MAT-LAB “addpath” command.)

If read engine tests.m is in your MATLAB path, then when you enter

>> read engine tests

at the MATLAB prompt, you should get a message like the following:

Reading engine data files in the directory


/home/jupiter/a/mcconagh/GALLOP/INPUT_FILES/EJ

pmin = 0.524000 kW

pmax = 2.510000 kW

numengines(1) = 2

numengines(2) = 3

numengines(3) = 5

max_numengines = 5

alloc_rules = max_thrust

e_truthfactor = 0.500000

e_sharpness = 100.000000

OPTIONS:

0. Exit

1. Power per on-engine

2. Total thrust

3. Total mdot

4. Derivative of super-engine total thrust

5. Derivative of super-engine total mdot

6. Derivative of user-engine total thrust

7. Derivative of user-engine total mdot

Select one:

The specific values for pmin, pmax, etc. should be the same as in yourGALLOP input file.

Options 1, 2, and 3 will probably be of the most interest to you. (The re-maining four options are to test GALLOP’s derivative calculations—somethingthe average user isn’t likely to be concerned about.) If you select option 1,then MATLAB should generate a plot like the one shown in Fig. 6.3.

The vertical lines in Fig. 6.3 are drawn at Pav = pmin and Pav =MAX(numengines)× pmax. When the available power (Pav) is less than pmin,then no power can be allocated to any of the engines, so the power per on-engine is zero. When Pav is greater than MAX(numengines) × pmax, thenall engines can recieve maximum power and the power per on-engine staysconstant.

You can tell how many engines are on by looking at the slope of the linesegments. If the slope is 1, then there is one on-engine. If the slope is 1

2,

then there are two on-engines. If the slope is 13, then there are three on-

6.3. TESTING THE ENGINES 71

0 5 10 150

0.5

1

1.5

2

2.5

3

3.5

Power available (pav), kW

Pow

er p

er o

n−en

gine

(pe

), k

W

Figure 6.3: Example plot produced by option 1

engines, and so on. For example, in Fig. 6.3, as Pav increases, the number ofon-engines goes through the sequence 0, 2, 3, 2, 5, 2, 3, 5.

If you select option 2 or option 3, then you should get plots like thoseshown in Figs. 6.4 and 6.5. Each of those plots actually shows three functions:one for the super-engine, one for the truth model, and one for the user engine.

As expected, the truth model has multiple discontinuities and the super-engine behaves piecewise-linearly. The user engine lies somewhere betweenthe super-engine and the truth model (as determined by the e truthfactor,which in this case was 0.5.)


0 5 10 150

0.1

0.2

0.3

0.4

0.5


Tot

al T

hrus

t, N True engine(s)

Super−engine(s)User engine(s)


6.4 Guidelines when Using Multiple Engines

With four more parameters to tweak (numengines, alloc rules,e truthfactor, and e sharpness), there is a need for some guidelines onhow to choose their values. The numengines parameter is a property ofthe spacecraft and doesn’t need to be changed, so guidelines are really onlyneeded for the other three parameters.

• When doing the “last and final” optimization run, make suree truthfactor = 1.0D+0 and e sharpness is a large number (like10000.0D+0 or more).

• I have observed that GALLOP tends to take longer to converge when

6.4. GUIDELINES WHEN USING MULTIPLE ENGINES 73

0 5 10 150

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

x 10−5


Tot

al M

ass

Flo

w R

ate,

kg/

s

True engine(s)Super−engine(s)User engine(s)


the e sharpness is less than about 100.0D+0. In fact, the smallerit is, the longer GALLOP takes to converge. For values greater than100.0D+0, changing the e sharpness doesn’t seem to make much dif-ference in the convergence time. This is not what is expected, but thereyou have it. I usually set the e sharpness to 10000.0D+0 and keep itthere.

• When the e truthfactor = 1.0D+0, GALLOP can get stuck in alocal maximum (and return with ’EXIT – optimal solution found’). Itis therefore a good idea to do initial optimization with e truthfactor

= 0.0D+0 (i.e. with a super-engine).


• I have found that a two-step process for varying the e truthfactor

works just as well as a multi-step process. That is, you first find anoptimal solution with e truthfactor = 0.0D+0 and then use thatsolution as an initial guess with the e truthfactor = 1.0D+0.

• The alloc rules can make a difference, but only for certain enginesand certain missions where the spacecraft must thrust in a region wherethe available power leads to a different total thrust (or mass-flow rate)depending on the rules used.

• An optimal solution with alloc rules set to max power is probably agood initial guess for an optimization run with alloc rules changedto max thrust (and vice versa). You don’t need to go back to the firstinitial guess.

Chapter 7

The GALLOP Output Files

7.1 The GALLOP Solution File

The GALLOP solution file has the same format as the GALLOP input file.This means that the solution file can be used as an input file itself.

In order to do this, you must open up the solution file and enter a namefor its solution file. Also, if you used a launch vehicle, and you want to keepusing a launch vehicle, you will have to change the guess of the initial massfrom a number to a launch vehicle specifier (like lv32). You may also wantto make other changes.

There is also another way to do this. GLOOK has an option that letsyou write a new GALLOP input file based on the solution currently beinganalyzed.

7.2 The Solution Plotting Information File

The solution plotting information file contains information about the solutionthat GLOOK uses to make plots of the solution trajectory. You never needto read or modify it.

GLOOK expects the solution plotting information file to have the samename as the solution file, except with the four characters .plt concatenatedonto the end. For example, if the solution file is named EMC_inp1_sol, thenthe corresponding solution information file is named EMC_inp1_sol.plt.Don’t rename the solution plotting information file (unless you also renamethe corresponding solution file).

75

76 CHAPTER 7. THE GALLOP OUTPUT FILES

7.3 Other Output Files

GALLOP may also produce other output files. For example, the optimizerNPOPT writes a ‘summary file’ named fort.11. You can ignore and deletethese files at will.

Chapter 8

Some Notes on Using GALLOP

There are many “tricks of the trade” to using GALLOP. This chapter de-scribes some of them.

8.1 Bootstrapping

Sometimes the “solution” that GALLOP finds is not optimal, but it is bet-ter than the initial guess. By using GLOOK, you can often find things inthe solution that should obviously be changed (usually ∆v magnitudes, Psiangles, or Theta angles).

GLOOK has an option to write a new GALLOP input file based on thecurrent solution. It facilitates many of the common changes that one makes.Any changes that GLOOK doesn’t make can be made using a text editor onthe new GALLOP input file.

I call this process “bootstrapping”. It is based on the verb “to bootstrap”which means (according to Merriam-Webster’s Collegiate Dictionary):

bootstrap (v.) to promote or develop by initiative and effortwith little or no assistance.

“Bootstrapping” isn’t really the right word to use, because you aren’t doingeverything by yourself (GALLOP is helping). “Iterating” would be a morecorrect word (but less colourful).

77

78 CHAPTER 8. SOME NOTES ON USING GALLOP

8.2 Using Analytic Ephemeris Data

If you set up your .login and .cshrc files as described in Chapter 2, thenGALLOP should use the JPL DE405 ephemerides by default.

Reading ephemeris data takes longer than using analytical ephemerisdata, so sometimes you may want to speed up your GALLOP runs by usinganalytical ephemeris data. Since analytical ephemerides are only availablefor planets and satellites (moons), this trick only works if all the bodies onyour mission are planets or satellites.

You can cause GALLOP to use analytical ephemeris data by entering thefollowing commands at your UNIX prompt:

> unsetenv MAS_LOAD_POINT

> unsetenv EPHEMERIS1

8.3 Finding a Feasible Trajectory

Sometimes just finding a feasible point (trajectory) is tricky. By puttingthe a line that says Feasible point only in your NPOPT specs file, youcause the optimizer to ignore the objective function (the final mass) and toconcentrate all of its efforts on finding a feasible point. We haven’t had muchluck with this option, but it’s worth a try.

Using Cartesian coordinates for the internal representation of the ∆vvectors sometimes helps too, especially when the initial guess is quite bad.To do this, you need to have a line in the GALLOP input file that sets thevariable dvparam to cartesian. (If you don’t set dvparam, then the defaultvalue is spherical.) See section 5.1.8 for more information about dvparam.

Moving the location of a breakpoint sometimes helps as well. This isaccomplished by changing nsegbp(i). Once you find a feasible solution, youshould put the breakpoint back near the middle of the leg (to minimize theerror in the calculated derivatives). See section 5.1.15 for more informationabout nsegbp(i).

You might also try varying the optimization variable transformation pa-rameters. They are discussed in section 5.3.

8.4. NUCLEAR ELECTRIC PROPULSION (NEP) MISSIONS 79

8.4 Nuclear Electric Propulsion (NEP) Mis-

sions

GALLOP was designed to optimize missions where the power comes fromsolar arrays (Solar Electric Propulsion), but it can also be used to optimizetrajectories where the power comes from a nuclear reactor (Nuclear ElectricPropulsion or NEP). Such missions are quite a bit simpler because the thrustand mass-flow rate are constant.

Typical parameters for an NEP spacecraft are the engine input powerP , the engine Isp, and the engine efficiency η (all constants). From thosequantities, one can calculate the thrust F and the mass-flow rate m using

F =2ηP

g0Isp

m =F

g0Isp

where g0 = 9.80665 m/s2 is the standard acceleration due to gravity. In theGALLOP input file, one then sets

ct(1) = F (in Newtons)ct(2) = 0.0D+00

ct(3) = 0.0D+00

ct(4) = 0.0D+00

ct(5) = 0.0D+00

cm(1) = m (in kg/s)cm(2) = 0.0D+00

cm(3) = 0.0D+00

cm(4) = 0.0D+00

cm(5) = 0.0D+00

Other parameters could be set as follows:

sa(1) = 1.0D+0

sa(2) = 0.0D+00

sa(3) = 0.0D+00

sa(4) = 0.0D+00

80 CHAPTER 8. SOME NOTES ON USING GALLOP

sa(5) = 0.0D+00

pmin = 1.0D-04

pmax = 2.6D+00

p0 = 1.0D+04

dutycyc = 1.0D+00

scp = 0.0D+00

Chapter 9

Common Errors and Problems

9.1 GALLOP Finished without Stating an EXIT

Condition

If GALLOP finishes, but it states no EXIT condition (an example of anEXIT condition is: EXIT -- the current point current point cannot

be improved), then you should check the end of the screen output and findout what inform equals. For example, in the GALLOP screen output shownbelow, inform equals 0.

Time for MPS input 0.00 seconds

Time for solving problem 23.41 seconds

Time for solution output 0.00 seconds

Time for constraint functions 20.51 seconds

Time for objective function 0.00 seconds

The NPOPT SUMMARY file is fort.11

NPOPT returned with inform = 0

Final mass = 435.2301120987876

Data to generate plots written to EMC_inp1_sol.plt

Solution written to EMC_inp1_sol

If inform equals 3 and you got no EXIT condition, then the likely culpritis that you have the Minor iteration limit set too low (or maybe you didn’teven set the Minor iteration limit and its default is too low).

81

82 CHAPTER 9. COMMON ERRORS AND PROBLEMS

To set the Minor iteration limit, just include a line like:

Minor iterations limit 2000

in your NPOPT specs file. Keep increasing it until the problem goes away.

9.2 EXIT -- the superbasics limit is too

small

This EXIT condition occurs when the “superbasics limit” is too small. Toprevent this from occurring, just insert a line that says:

Superbasics limit 2000

in your NPOPT specs file. If you continue to get the same EXIT condition,then just keep increasing the superbasics limit (2000 above) until that EXITcondition goes away.

9.3 Core Dumped

A number of things can cause a core dump. The most common causes arearithmetic exceptions and segmentation faults.

Arithmetic exceptions happen when a program tries to do an illegal orundefined arithmetic operation (like dividing by zero). An arithmetic excep-tion can sometimes happen just by an unlucky fluke. That is, the numbersin your input file have the property that they lead the optimizer down apath to an arithmetic exception. If that is the case, then making some smallmodifications to the numbers in the input file will often stop the arithmeticexception from occurring.

Segmentation faults are usually caused by programming error (for exam-ple, some code might try to write to an element of an array that doesn’texist). If a segmentation fault happens, then contact me (Troy McConaghy)and give a complete description of the conditions that caused the error.

It is a good idea to delete the core file that is created when a core dumphappens because it tends to use up a lot of disk space.

Appendix A

The Power Model

GALLOP uses a fairly involved model to calculate the power Pav available foruse by the engine(s). In this appendix, I summarize all the calculations thatgo into calculating Pav. Whenever a GALLOP parameter occurs in a calcu-lation, its name is written out in typewriter font (i.e. scp). See Section 5.1for more details on the individual parameters.

At the highest level, the available power for the engines, Pav, is

Pav = Pgen − scp

where Pgen is the power generated by the solar arrays and scp is the powerused by the spacecraft (and not available for the engines).

If the scp is greater than Pgen, then Pav is negative. If this happens,GALLOP gives a warning message (once) and sets Pav to zero.

Pgen is calculated using

Pgen = p0 · Prel · ε

where p0 is the reference power (when r = 1 AU and t = 0), Prel is therelative power, and ε is the time-degradation factor. When r = 1 AU andt = 0, both Prel and ε equal one, so Pgen = p0 at that point.

The time degradation factor ε is a dimensionless function of time whichis used to take into account how the efficiency of the solar arrays depends ontime. It is calculated using

ε = β1 + β2eβ3t + β4t

= beta(1) + {beta(2) · exp [beta(3) · t]} + [beta(4) · t]

83

84 APPENDIX A. THE POWER MODEL

where t is the time since launch (when the trajectory began).The relative power Prel is a dimensionless function of r, the distance from

the Sun to the spacecraft (in AU).

Prel = αP ·

η(rt)/r2t if r ≤ rt

η(r)/r2 if rt < r < r cutoff

0 if r ≥ r cutoff

where αP = 1 AU2 (so that Prel is dimensionless).The calculation of Prel needs a bit of explanation. First of all, we see that

there is the usual 1/r2 dependence due to the diminishing intensity of lightas the spacecraft gets further from the Sun.

The function η(r) is the relative efficiency of the solar arrays. It takesinto account how the temperature of the solar arrays affects their efficiency(and the temperature is a function of r). The function η(r) is calculated asfollows:

η(r) =

{

κ(r) if r < r max

κ(r max) if r ≥ r max

κ(r) =

(

sa(1) + sa(2)/r + sa(3)/r2

1 + sa(4)r + sa(5)r2

)

The parameters sa(1) through sa(5) are chosen so that the relative effi-ciency is equal to 1 when r = 1 AU. I call the function κ(r) the “raw relativeefficiency”; it can have problems when its denominator is close to zero —r max was introduced to help out with that problem.

When r ≤ rt, the spacecraft is close to the Sun and the solar arrays wouldoverheat if they directly faced the Sun. So when r ≤ rt, the solar arrays gettilted away from the Sun. GALLOP assumes that the arrays get tilted insuch a way that the relative power is constant when r ≤ rt.

The parameter rt is called the “tilt radius” and it is usually equal to theGALLOP input parameter r tilt. However, if the function [η(r)/r2] has amaximum somewhere between r tilt and 1 AU, then rt is at the locationof that maximum.

The meaning of the r cutoff parameter is fairly obvious — if r is greaterthan r cutoff, then the relative power is zero.

Appendix B

The Engine Model

In GALLOP, the thrust from a single engine, F , is assumed to be a polyno-mial function of the input power P .

F = ct(1) + ct(2)P + ct(3)P 2 + ct(4)P 3 + ct(5)P 4

where thrust is in Newtons and power is in kW. Typical values of the pa-rameters are:

ct(1) = -1.9137E-03 Nct(2) = 36.242E-03 N/kWct(3) = 0.0E+0 N/kW2

ct(4) = 0.0E+0 N/kW3

ct(5) = 0.0E+0 N/kW4

When these values are used, the dependence of thrust on input power isshown in Fig. B.1.

The single-engine mass flow rate, m, is also assumed to be a polynomialfunction of the input power.

m = cm(1) + cm(2)P + cm(3)P 2 + cm(4)P 3 + cm(5)P 4

where m is in kg/s and power is in kW. Typical values of the parameters are:

cm(1) = 475.56E-09 kg/scm(2) = 902.09E-09 kg/(s·kW)cm(3) = 0.0E+0 kg/(s·kW2)

85

86 APPENDIX B. THE ENGINE MODEL

0 0.5 1 1.5 2 2.5 30

10

20

30

40

50

60

70

80

90

100

Input Power P (kW)

Thr

ust (

mN

)

Figure B.1: Thrust Model with Typical Parameters

cm(4) = 0.0E+0 kg/(s·kW3)cm(5) = 0.0E+0 kg/(s·kW4)

When these values are used, the dependence of mass flow rate on inputpower is shown in Fig. B.2.

Since an engine’s specific impulse (Isp) is a function of the thrust and themass flow rate, i.e.

Isp =F

g m

it is also a function of the input power (g = 9.80665 N/kg is just a constant).This dependence of Isp on input power is shown in Fig. B.3 (for typicalparameter values).

87

0 0.5 1 1.5 2 2.5 30

0.5

1

1.5

2

2.5

3

Input Power P (kW)

Mas

s Fl

ow R

ate

(mg/

s)

Figure B.2: Mass Flow Rate Model with Typical Parameters

0 0.5 1 1.5 2 2.5 31600

1800

2000

2200

2400

2600

2800

3000

3200

3400

Input Power P (kW)

Isp

(sec

)

Figure B.3: Engine Isp with Typical Parameters

88 APPENDIX B. THE ENGINE MODEL

Appendix C

Launch Vehicles

One can have GALLOP calculate the initial mass of the spacecraft, m0, fromthe launch v∞ by telling it which launch vehicle it should assume. (Seesections 5.2.3 and 5.2.5 for more information on how to do this.)

This appendix explains the model that is used to calculate m0 from thelaunch v∞ and the launch vehicle number. Plots of m0 as a function of launchv∞ are given for various launch vehicles.

C.1 The Launch Vehicle Model

The launch vehicle model used by GALLOP is not new: it is the same as theone used by SEPTOP (written by Carl Sauer).

The upper stage and payload (including upper stage structural mass,upper stage propellant mass, the payload adapter mass and the payloadmass) are assumed to begin in a circular parking orbit of known altitude alt.The radius rpo of the circular parking orbit is therefore given by

rpo = rEarth + alt

where rEarth = 6378 km is the radius of the Earth. The velocity vc in thecircular parking orbit is therefore

vc =√

µE/rpo

where µE = 3.986×105 km3/sec2 is the gravitational parameter of the Earth.The upper stage then does a tangential Delta-V to transfer into a hyperbolic

89

90 APPENDIX C. LAUNCH VEHICLES

orbit. The hyperbolic orbit is assumed to have its perigee at rpo. It also hasthe desired v∞ (which is the velocity when r → ∞). An example circularparking orbit and hyperbolic escape orbit are shown in Fig. C.1.

Earth

Circular parking orbit

Hyperbolic escape orbit

Figure C.1: Parking orbit and escape orbit

The velocity at perigee, vp, can be determined using the conservation ofenergy:

Energy at perigee = Energy as r → ∞

v2p

2−

µE

rpo

=v2∞

2−

µE

∞

vp =

√

2µE

rpo

+ v2∞

The required Delta-V, ∆vc, is therefore

∆vc = vp − vc

∆vc =

√

2µE

rpo

+ v2∞−

√

µE

rpo

C.1. THE LAUNCH VEHICLE MODEL 91

The final mass (including upper stage structural mass, the payload adaptermass and the payload mass) can then be determined using curve fits basedon the rocket equation.

The launch vehicle model has three different kinds of curve fits. I willrefer to these as method 1, method 2 and method 3. The model uses fourparameters: mlv(1), mlv(2), mlv(3) and mlv(4). Their units and meaningsare summarized in Table C.1.

Table C.1: The four mlv parameters

Parameter Units Meaningmlv(1) kg The total initial mass (structure + propellant +

adapter + payload) OR zeromlv(2) kg Upper stage structural massmlv(3) km/s Exhaust velocity of propellant (= gIsp)mlv(4) kg Upper stage propellant mass OR zero

These parameters are used to calculate the “launch vehicle capability”lvcap, which is the theoretical mass of the adapter plus the mass of thepayload (assuming no losses).

Note how mlv(1) could be zero. When that happens, it doesn’t mean thatthe total initial mass (mlv(1)) was zero! It means you should use Method 1(described below) to calculate lvcap.

Similarly, mlv(4) could be zero. When that happens, you should useMethod 2 (described below) to calculate lvcap.

If neither mlv(1) nor mlv(4) is zero, then you should use Method 3 (de-scribed below) to calculate lvcap. The parameters mlv(1) and mlv(4) arenever zero at the same time.

Method 1 (used when mlv(4) = 0)

In this case, we use the form of the rocket equation that gives the final mass(lvcap + structural mass) in terms of the initial mass and the Delta-V:

∆vc = gIsp ln

(

initial mass

final mass

)


final mass = (initial mass) · exp

(

−∆vc

gIsp

)

lvcap + structural mass = (initial mass) · exp

(

−∆vc

gIsp

)

lvcap + mlv(2) = mlv(1) exp

(

−∆vc

mlv(3)

)

lvcap = mlv(1) exp

(

−∆vc

mlv(3)

)

− mlv(2) (C.1)

Note how this formula for lvcap doesn’t involve mlv(4). That’s why wecan get away with setting mlv(4) equal to zero.

Method 2 (used when mlv(1) = 0)

In this case, we use the form of the rocket equation that gives the final mass(lvcap + structural mass) in terms of the propellant mass and the Delta-V:

∆vc = gIsp ln

(

final mass + propellant mass

final mass

)

final mass =(propellant mass) · exp

(

−∆vc

gIsp

)

1 − exp(

−∆vc

gIsp

)

lvcap + structural mass =(propellant mass) · exp

(

−∆vc

gIsp

)

1 − exp(

−∆vc

gIsp

)

lvcap + mlv(2) =mlv(4) exp

(

−∆vc

mlv(3)

)

1 − exp(

−∆vc

mlv(3)

)

lvcap =mlv(4) exp

(

−∆vc

mlv(3)

)

1 − exp(

−∆vc

mlv(3)

) − mlv(2) (C.2)

Note how this formula for lvcap doesn’t involve mlv(1). That’s why wecan get away with setting mlv(1) equal to zero.

C.1. THE LAUNCH VEHICLE MODEL 93

Method 3 (used when mlv(1) > 0 and mlv(4) > 0)

Method 3 uses either method 1 or method 2 to calculate lvcap, dependingon the size of ∆vc. Method 3 uses equation C.1 when ∆vc ≤ ∆vs and it usesequation C.2 when ∆vc > ∆vs.

The value of the parameter ∆vs is chosen so that lvcap is a continuousfunction of ∆vc. That is, ∆vs is chosen so that when ∆vc = ∆vs, the value oflvcap is the same regardless of whether you use equation C.1 or equation C.2.

mlv(1) exp

(

−∆vs

mlv(3)

)

− mlv(2) =mlv(4) exp

(

−∆vs

mlv(3)

)

1 − exp(

−∆vs

mlv(3)

) − mlv(2)

∆vs = −mlv(3) ln

(

1 −mlv(4)

mlv(1)

)

Note that ∆vs is a constant parameter, independent of ∆vc or v∞. Notealso that mlv(1) and mlv(4) are assumed to be independent unrelated pa-rameters (so that the curve fit for method 3 has four free parameters).

Once the launch vehicle capability (lvcap) has been calculated, one thenmultiplies it by a fudge factor of (1 - lvcont), where lvcont is a numberbetween 0 and 1 and is known as the “launch vehicle contingency.” Thisfudge factor is to take unmodelled losses into account. That is, it gives youa more conservative estimate of the actual mass delivered to the desired v∞.

The mass delivered to the desired v∞ includes both the payload mass,m0, and the mass of the adapter, madp. The adapter is the physical structurethat connects the payload to the launch vehicle. It gets disconnected fromthe payload, so

mass delivered = (1 − lvcont)lvcap = m0 + madp

or

m0 = (1 − lvcont)lvcap − madp (C.3)

Sometimes, the mass of the adapter is not assumed to be fixed. Instead,the mass of the adapter is assumed to be some fraction kadp of the payloadmass.

madp = kadpm0


so

m0 = (1 − lvcont)lvcap − kadpm0 (C.4)

m0 =(1 − lvcont)lvcap

(1 + kadp)(C.5)

The adapter mass is either assumed to be fixed or it is assumed to besome fraction of the payload mass, so one of madp or kadp is always set tozero. Therefore equations C.3 and C.5 can be combined into one:

m0 =(1 − lvcont)lvcap − madp

(1 + kadp)

In summary, there are 8 parameters in the launch vehicle model: mlv(1),mlv(2), mlv(3), mlv(4), alt, lvcont, madp and kadp. The GALLOP launchvehicle data file for a given launch vehicle contains these 8 parameters.

C.2. LAUNCH VEHICLES AVAILABLE IN GALLOP 95

C.2 Launch Vehicles Available in GALLOP

The launch vehicles currently available in GALLOP are listed in Table C.2.Plots of m0 as a function of launch v∞ are given for those launch vehiclesat the end of this appendix. You may notice that for some of the launchvehicles, the initial mass is negative when the launch v∞ is high. That’sbecause the model is only valid for low launch v∞.

There is a Matlab script named M0 that calculates the initial mass giventhe launch v∞ and the launch vehicle number. It resides in the same directoryas GLOOK, so if you can use GLOOK, you can use M0.

As an example of how to use M0, suppose you want to know the initialmass if launch vehicle 32 is used to launch the spacecraft with a launch v∞of 1.8 km/s. You would enter:

>> m_initial = m0(1.8,32)

m_initial =

609.6767

so the initial mass is 609.6767 kg.


Table C.2: Launch Vehicles Available in GALLOP

Number Name31 Delta 7925 / Star30BP32 Delta 7326-9.533 Ariane 534 Proton-DM/*63F/*37XPF/*27V35 Shuttle/TOS/*63F/*37XPF/*27V38 Medlite60 Delta 7326-9.5 [DAO98]65 Delta IV M+(5,4)66 Delta IV M+(4,2)67 Atlas V 52168 Atlas V 53177 Delta 2925-9.578 Delta 2925H-9.579 Delta 3940-1181 Delta 4240-1283 Delta 4050H-1984 Atlas IIIB85 Atlas IIIB/Star48V


0 1 2 3 4 5 6 7 8 9 100

200

400

600

800

1000

1200

1400

Launch V∞ (km/s)

Initi

al m

ass

(kg)

38603277


0 1 2 3 4 5 6 7 8 9 10−500

0

500

1000

1500

2000

2500

3000

3500

Launch V∞ (km/s)

Initi

al m

ass

(kg)

31787984


0 1 2 3 4 5 6 7 8 9 10−1000

0

1000

2000

3000

4000

5000

Launch V∞ (km/s)

Initi

al m

ass

(kg)

85668165


0 1 2 3 4 5 6 7 8 9 10−1000

0

1000

2000

3000

4000

5000

6000

Launch V∞ (km/s)

Initi

al m

ass

(kg)

67353368


0 1 2 3 4 5 6 7 8 9 100

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Launch V∞ (km/s)

Initi

al m

ass

(kg)

3483

Appendix D

Example Session with theGALLOP Wizard

Here is an example of a session with the GALLOP Wizard (GWIZ) in whicha GALLOP input file for an Earth-Venus-Vesta trajectory gets created fromscratch.

> gwiz

==============================

G-WIZ 3.0 (June 2002)

==============================

Hello. I am the GALLOP Wizard (GWIZ).

I will help you create a new GALLOP input file by

asking you a series of questions.

Whenever I give default values, you can accept

the default value by entering the letter d.

What would you like to call your new GALLOP input file?

sample_infile

A new GALLOP input file named sample_infile will now be created.

103

104APPENDIX D. EXAMPLE SESSION WITH THE GALLOP WIZARD

Before I start asking you for values, I’d like to state

some ground rules. Break them at your own risk.

GROUND RULES

------------

1. No value that you enter can be more than 19

characters long. This includes numerical values.

2. Use scientific notation for all non-integer numerical

values. There must be a decimal point and there must

be an E or a D. Correct examples are:

0.0D+00 (not 0 or 0.0)

-5.3E-08

456.3D+13

What optimization program would you like to use?

(Enter the letter d for the default)

optimizer = [ Default: NPOPT ]

d

Once GALLOP has finished an optimization run based on

the input file sample_infile, where would you like

it to write the solution file (what file)?

solfile = [ Default: sample_infile_sol ]

d

I assumed that you want to use the string ’inf’ as the

flag for infinity (inf_flag).

Now I will ask you for the coefficients for the

mdot(power) model (variables cm(1) through cm(5)):

105

cm(1) = [ Default: 475.56E-09 ]

d

cm(2) = [ Default: 902.09E-09 ]

d

cm(3) = [ Default: 0.0E+0 ]

d

cm(4) = [ Default: 0.0E+0 ]

d

cm(5) = [ Default: 0.0E+0 ]

d


thrust(power) model (variables ct(1) through ct(5)).

ct(1) = [ Default: -1.9137E-03 ]

d

ct(2) = [ Default: 36.242E-03 ]

d

ct(3) = [ Default: 0.0E+0 ]

d

ct(4) = [ Default: 0.0E+0 ]

d


ct(5) = [ Default: 0.0E+0 ]

d


pwrovp0(radius) model (variables sa(1) through sa(5)).

sa(1) = [ Default: 1.1063E+0 ]

d

sa(2) = [ Default: 149.5E-3 ]

d

sa(3) = [ Default: -299.0E-3 ]

d

sa(4) = [ Default: -43.2E-3 ]

d

sa(5) = [ Default: 0.0E+0 ]

d

What is the minimum power (pmin) needed to run the engine?

pmin = [ Default: 0.649E+0 kW ]

d

What is the maximum power (pmax) usable by the engine?

pmax = [ Default: 2.6E+0 kW ]

107

d

What is the solar array reference power p0?

p0 = [ Default: 10.0E+0 kW ]

d

What is the engine duty cycle (dutycyc)?

dutycyc = [ Default: 1.0E+0 ]

d

What is the power scp used by the spacecraft?

scp = [ Default: 0.0E+0 kW ]

d

How many bodies are there on the mission (including the

launch body, flyby bodies, and final body)?

numbodies = ( an integer >= 2 )

3

Now I am going to ask you the names of all the bodies on

the mission. bodname(1) is the launch body, bodname(2)

is the second body encountered on the mission, etc.

Use an underscore instead of a space if the body name

consists of two or more words (i.e.\ tempel_1). I’ll

replace the underscore with a space when I write it to

the file.

bodname(1) =


earth

bodname(2) =

venus

bodname(3) =

vesta

Is the mission a rendezvous or a flyby?

trajtype = [ Default: flyby ]

d

Now I am going to ask you the types of all the bodies on

the mission. The launch body is of type bodtype(1), etc.

Allowed types are planet, satellite, asteroid, comet, and

unnumbered_asteroid (note the underscore).

bodtype(1) = [ Default: planet ]

d


d


asteroid

The Times of the Body Encounters

Would you like to enter the times of the body encounters

as (j)ulian dates or as (c)alendar dates and times?

(Enter j or c)

109

c

Now I am going to ask you the calendar dates and times

at the bodies.

Calendar date and time at body 1:

Example: Jan. 30, 1975 at 10:25:09 is 19750130.102509D+0

20060101.000000D+0

(Julian date = 2453736.5 )



20070101.000000D+0

(Julian date = 2454101.5 )



20080101.0000000D+0

(Julian date = 2454466.5 )

Reading states of the bodies on the Julian dates...

EPHOPN opened analytic ephemeris

EPHOPN opened /home/roger/a/masl/data/astcom_ephemdata.bsp

EPHOPN opened /home/roger/a/masl/data/satellite_ephemdata.bsp

EPHOPN opened /home/roger/a/masl/data/de405.bsp

Now I am going to help you determine how many segments

to put on each leg. I will do this by asking you the

desired duration of the segments on each leg.

desired segment duration on leg 1 = [ Default: 8.0D+0 days ]

d


I computed nsegleg(1) = 46

and nsegbp(1) = 23

desired segment duration on leg 2 = [ Default: 8.0D+0 days ]

d

I computed nsegleg(2) = 46

and nsegbp(2) = 23

I (the GALLOP Wizard) currently assume that you want a fixed

launch v-infinity magnitude and a fixed initial mass.

launch v-infinity magnitude: [ Default: 3.0D+0 km/s ]

5.0D+0

initial mass: [ Default: 300.0D+0 kg ]

d

mass at body 2 (kg) = [ No default, just guess ]

200.0D+0

mass at body 3 (kg) = [ No default, just guess ]

150.0D+0

Now I’l help you set up the initial guess for the Delta-v

magnitudes on the segments (I automatically set their

lower and upper bounds to reasonable values.)

For each leg, I will ask you the Delta-v magnitude on

the first and last segments. I will then use a linear

interpolation to determine the Delta-v magnitude on

the intervening segments of that leg.

111

LEG 1

Delta-v magnitude on first segment of leg 1 = [ Default: 0.0D+0 km/s ]

0.1D+0

Delta-v magnitude on last segment of leg 1 = [ Default: 0.0D+0 km/s ]

0.1D+0

LEG 2

Delta-v magnitude on first segment of leg 2 = [ Default: 0.0D+0 km/s ]

0.1D+0

Delta-v magnitude on last segment of leg 2 = [ Default: 0.0D+0 km/s ]

d

Determining the Theta angles

I will now ask you the estimated number of complete

revs that the s/c does on each leg. For legs that

go out to a body farther from the Sun, I assume that the

thrust vectors are WITH the s/c velocity vector.

For legs that go in to a body closer to the Sun, I

assume that the thrust vectors are AGAINST the s/c

velocity vector.

Integer number of WHOLE s/c revs on leg 1

(The FLOOR of the number of revs)

= [ Default: 0 ]

d

Integer number of WHOLE s/c revs on leg 2


(The FLOOR of the number of revs)

= [ Default: 0 ]

d

The Theta angles part of the input file has been written.

Writing the Psi angles part of input file...

Writing the Julian dates part of the input file...

Writing the launch v-infinity part of the input file...

Now I need to ask you what kind of encounter is

happening at each of the post-launch bodies.

Encounter with body 2 (venus):

Is this encounter:

(o)utgoing,

(i)ncoming,

(r)endezvous,




f

Encounter with body 3 (vesta):

Is this encounter:

(o)utgoing,

(i)ncoming,

(r)endezvous,




113

o

Writing the incoming velocities at the post-launch

bodies...

Writing the spacecraft masses part of the input file...

Now I will ask you the minimum allowable

flyby altitude at each flyby body, as well as

a guess of the actual flyby altitude (km).

What is the minimum allowable flyby altitude on

flyby 1 (at venus)?

[ Default: 300.0D+0 km ]

d

What is your guess of the actual flyby altitude

on flyby 1 (at venus)?

[ Default: 800.0D+0 km ]

350.0D+0

Writing the B-plane angles part of the input file...

A GALLOP input file named sample_infile has been written.

I hope I’ve been helpful.

Sincerely,

The GALLOP Wizard

>

Bibliography

[1] Jon A. Sims and Steve N. Flanagan, “Preliminary Design of Low-ThrustInterplanetary Missions,” AAS/AIAA Astrodynamics Specialist Con-ference, AAS Paper 99-338, Girdwood, Alaska, 16-19 Aug. 1999, pp.583-592.

[2] McConaghy, T. Troy, Debban, Theresa J., Petropoulos, Anastassios E.,and Longuski, James M., “An Approach to Design and Optimization ofLow-Thrust Trajectories with Gravity Assists,” AAS/AIAA Astrody-namics Specialist Conference, AAS Paper 01-468, Quebec City, Quebec,July 30–Aug. 2, 2001.

[3] Chen, K. Joseph, McConaghy, T. Troy, Okutsu, Masataka, andLonguski, James M., “A Low-Thrust Version of the Aldrin Cycler,”AIAA/AAS Astrodynamics Specialist Conference, AIAA Paper 2002-4421, Monterey, California, Aug. 5–8, 2002.

[4] Debban, Theresa J., McConaghy, T. Troy, and Longuski, James M.,“Design and Optimization of Low-Thrust Gravity-Assist Trajectoriesto Selected Planets,” AIAA/AAS Astrodynamics Specialist Conference,AIAA Paper 2002-4729, Monterey, California, Aug. 5–8, 2002.

[5] McConaghy, T. Troy, Debban, Theresa J., Petropoulos, Anastassios E.,and Longusi, James M., “Design and Optimization of Low-ThrustTrajectories with Gravity Assists,” Journal of Spacecraft and Rockets,Vol. 40, No. 3, May–June 2003, pp. 380–387.

[6] Chen, Joseph K., McConaghy, T. Troy, Landau, Damon F., andLonguski, James M., “A Powered Earth-Mars Cycler with ThreeSynodic-Period Repeat Time,” AAS/AIAA Astrodynamics SpecialistConference, AAS Paper 03-510, Big Sky, MO, Aug. 3–7, 2003.

115

GALLOP Version 4.5 User’s Guide - Purdue Engineering€¦ · Before you can use GALLOP, you need...

Documents

Transcript of GALLOP Version 4.5 User’s Guide - Purdue Engineering€¦ · Before you can use GALLOP, you need...