The GAMF Library - An Object-Oriented Approach to Modeling Astronomical Processes

plumponionchipsSoftware and s/w Development

Nov 18, 2013 (3 years and 8 months ago)

110 views

The
GAMF
Library
-

A
n Object
-
Oriented
Approach to
Modeling

Astronomical

Processes


Sammy Yousef

University of Western Sydney, Nepean

Prepared as part of the subject “Astronomy Research Project” of the Astronomy Internet Masters Program,
2002.

Email:
syousef@bigfoot.com

1

Abstract


Much of the current generation of
freely available
a
stronomy software is written in early

“3
rd

generation”
procedural languages

-

p
articularly
FORTRAN
,
C
, BASIC and PASCAL
.

The skill with
which software
reuse is maximized varies, but

the

software is generally written to serve one
very
specific need or
solve
a
closely
related set of
problems
. Astronomers often avoid more complex
object
-
oriented

pr
ogramming
paradigms due to the

initial
learni
ng curve associated. GAMF


the
Gener
ic Astronomy
Modeling

Framework is a proof of concept
,
upon
which a more complex and complete library may be
built by
interested parties

in an open source environment. It
is an attempt to demonstrate
that the
object
-
ori
ented

paradigm, which swept through the business programming community in the 1990s, is
particularly
well
suited to
modelling
a variety of loosely related astronomical processes

in a
versatile reuse oriented
fashion
.
The advantages of an astronomy research
er or educational software writer taking the time to learn
and use an
object
-
oriented

approach are explored.

The potential
of
the library is demonstrated using a
small
demonstration
software
program that combines several models

included in the first releas
e

of the
GAMF library
.
The p
roblems
, challenges

and limitations
of
this approach
are examined both
in general
and
for
this
specific
library
.

2

Introduction

Software programming is a skill that requires some time to master
. Additionally, time must be spent
ma
stering each programming language in order to use it effectively. Professional programmers reach a
point at which new languages can be mastered in a time

span of days or weeks, by leveraging similarities
between languages

(eg.

C
-
based


language

similariti
es
)
, and code concepts

(eg. the
object
-
oriented

paradigm)
. However
,

even then, the environment and libraries that are part of a modern programming
environment take additional time to
become proficient with
.

These facts are well known and accepted in
the in
ternational i
nformation technology community.


It is no surprise then that scientists in general
,

and astronomers in particular
,

tend to focus on their area of
expertise and learn to program only as needed.
Many astronomers that have learnt to use one or t
wo
computer languages early in their career have failed to take full advantage of advances in programming
that have been adopted by business software programmers. Since computer languages and paradigms have
evolved quickly, this has meant that not only are

small advances not
exploited
, but large advances and
even entire paradigms which could
otherwise
help astronomers in their work are
neglected.


One significant area of advance has been in code reuse. In particular the
careful employment of the
object
-
ori
ented

paradigm has allowed
a new form of
software

reuse
compared with older paradigms.
Object
-
orientation
can be
used
particularly well for physical models
,

which often map well to objects or classes.

According to the well written tutorial on
object
-
orient
ed

programming that appeared in the
Turbo C++ 3.0
User Manual

“OOP [Object
-
oriented programming] seeks to mimic the way we form models of the world.
To cope with the complexities of life, we have evolved a wonderful capacity to generalize, classify, and
ge
nerate abstractions”. The overlap with this approach and the scientific method
, and the concrete objects
that are modelled, are

what makes
object
-
oriented

programming so vital to astronomy. With
object
-
oriented programming
the prospect of the reuse of indi
vidual astronomical models to form part of a larger
software program is simply a natural consequence of the approach taken. The integration of smaller
reusable subsets of code to build larger software sys
tems becomes a necessity if increasingly

complex
cod
e is to be tackled.



GAMF
(
Gener
ic Astronomy
Modeling

Framework)

is
object
-
oriented

in nature. Its

astronomical classes
are
written in
the
C#
programming language
to work on modern
Microsoft Windows platform
s
.
As the
name suggests it is not written to sol
ve any particular astronomical problem. Rather, in the spirit of what
was intended when
the

object
-
oriented

paradigm was f
irst developed, the intent is
generally
reusable

code.

In other words, i
nstead of being written to solve any particular problem
,

GAMF
is geared towards solving
more
general astronomy problems
which can
subsequently
be conglomerated into a larger application. A
good analogy is that it is similar to a computer desktop
“windowing” library
, which

provides the
framework for writing a variety
of applications
. GAMF, instead, allows astronomical applications to be
written.


The motivation for writing GAMF is to demonstrate the great potential for using object
-
oriented
techniques to improve productivity and integrate astronomical models. It is the

belief of the author that
learning and using these techniques is a necessity
and not a luxury for today’s astronomer for
three

reasons:


1.

Research grade astrophysical computer models today are inherently more complex than
programs of the 1960s. Object
-
orie
nted techniques help to break down this complexity into more
manageable problems.


2.

Object
-
orientation allow
s

an improvement in
reuse and thus facilitate
s

the combination of several
astronomical models. Projects too large to be tackled by individual astroph
ysicists may therefore
more readily be undertaken by a team. This is analogous to the situation in the business world
where
object
-
oriented

concepts have allowed businesses to build larger and more complex
business software environments.


3.

The rapid evoluti
on of computer technology and environments requires computer users to keep
up with relatively new hardware and software if they wish to obtain support for their systems.
Often computers built a few years later cannot run the same software as their predeces
sors

since

newer hardware is built

to run the latest generation of operating system. It is an unfortunate
reality that unless
software is kept up to date, a lack of knowledge and support for a system can
make it very difficult to maintain.


The initial rel
ease of the

GAMF

library is a proof of concept
,
to be distributed
publicly
in an
open source
format.

It is hoped that even if the library itself, which by necessity is limited, is
ultimately
discarded, the
concepts
presented in
this paper will raise awaren
ess of these issues in the astronomical community,
which in turn will lead
to
wider adoption of
object
-
oriented

software technology
.

3

Libraries and Object
-
Oriented Software

A great deal has been writte
n on software reuse, and object
-
orientation. This sectio
n is intended only to
provide a context for the development of GAMF
, and
a high

level overview of what
object
-
oriented

software is, and what advantages and disadvantages it has
relative to

procedural languages
. For a more
detailed description

and history
,
there is a wide variety of available computer science literature (OOPSLA,
ACM journals, and a v
ariety of computer science
texts
including Meyer, B. 1988 and Henderson
-
Sellers
B. 1992
.)

3.1

Features of Object
-
Oriented Programming Languages

The procedural progra
mming paradigm breaks up the task required of a computer into procedures,
functions or subroutines


essentially code fragments which can be used repeatedly in a softwar
e program
to perform a specific sub
-
task. This not only allows for software reuse, but
by breaking up a task in such a
way, allows to the programmer to focus on a more manageable sub
-
process instead of the entire
process
.
These sub
-
tasks themselves in turn can further be broken down, and so on for as many levels as is required
until the sub
-
task can be expressed briefly in terms of the functions provided by a programming
environment.
This allows for complex programs to be written in such a way that they are manageable to
a
n individual or team of

programmers
.


O
bject
-
orient
ed languages go a st
ep further. Software is organized into classes which serve as an abstract
representation of an object or process.
Features of a class of object are modelled as attributes, and
behaviour of the object is modelled as the class


methods.
By
building classes r
epresenting
a specific
subset
of
the system in which the programmer is interested,

it becomes possible to further m
anage the
complexity of a task.
Each object is responsible for its own behaviour and therefore need only perform its
own role in a given proc
ess. To achieve this, the
object
-
oriented

paradigm
requires more sophisticated
programming language features
. The classic features of an
object
-
oriented

paradigm have come to

be
recognised as encapsulation,
data hiding, inheritance and polymorphism.

3.1.1

Encaps
ulation

Encapsulation describes the ability to define and delineate an object or class
, through a set of attributes

(variables that represent the state of an instance of a class)
and the routines
(methods)
that belong to the
class. As mentioned above each
class should contain only routines that define its own behaviour in a
process.

Grouping a set of related processes together in this way makes it easier to locate any given
routine.

3.1.2

Data

Hiding

Data hiding allows a class to be treated as a black box by a pr
ogrammer. Once written, the programmer
needs only to be aware of the role a class plays within a system, not its internal workings. This allows the
programmer to focus on a larger more complex goal without dealing with the internal workings of
the
parts
. I
f the class is not behaving in the way it should, the programmer can then shift focus to the internal
workings of that class
,

providing he or she has the source code. Data hiding is usually achieved through
the use of language keywords that specify whether

the behaviour is to be seen externally (“public”), only
by subclasses of the current class (“protected”) or is internal to the black box (“private”).

3.1.3

Inheritance

Further reuse is achieved by allowing a

class, and therefore all instances (o
bject
s),

to inhe
rit
part of their

behaviour from that of a parent
class
. This allows a mo
re complex child to b
e built upon an existing
parent. In effect the child is a
more specialized
sub
-
type of the parent.

3.1.4

Polymorphism

Polymorphism literally means “many forms”. By defi
ning a common parent
or interface
(and thus
common behaviour) for a set of classes, in certain contexts throughout a software program, these classes
may be used
interchangeably, without knowing exactly which
within the
set
(which sub
-
type)
is being
used.

O
nce mastered, there are circumstances under which this technique can significantly simplify code
by removing the need to deal with the complexities of each of the individual classes.

3.2

Benefits
of Object
-
Orientation

There are clear benefits to the
object
-
ori
ented

approach.
The paradigm allows for a human programmer to
think in terms that are more familiar. Instead of
just
modelling a process as a broken down list of
instructions, the programmer thinks in more natural terms of a model which represents the real

process in
simulation.


T
he mechanisms described in the previous section allow for a “second dimension” of software reuse, and
a second level at which complexity is broken down

in the form of classes
.

Testing and debugging are also
simplified since the c
ode fragment in which a problem occurs often is easier to pinpoint
when thinking in
terms of models

(classes)
.


For the programmer this finer breakdown makes for more manageable code. As the complexity of a
project increases
, the skil
led programmer
can use

object
-
orientation
to ensure that this does not make the
project unwieldy
. An
object
-
oriented

structure can also make it easier for a programmer to read code
written by another individual. The
classes
provide manageable related code fragments
which concep
tually
represent the
abstract
model
s upon which a system is based.


The added

software reuse can also cut down development time. If only slight changes are required to a
class for it to perform a slightly different goal this may be possible through the use

of inheritance. With
proper design, classes may also be used intact in multiple systems where a common
s

goal needs to be
achieved. In the case of a software library
for which
the goal is to provide reusable code, this can prove
a
very powerful

technique.


The benefits to an end
-
user of software written in this way are clear. More complex
and robust
software
can be written. Development

time can be cut through re
-
use.

A

software developer is more likely to more
easily understand the code, and the ca
use of so
ftware bugs can be pin
-
pointed more
efficiently
. All other
things being equal the
end
user should have a more stable, more easily manipulated pr
ogram
with which
to work
. The complexity
of object
-
orientation
is managed by the programmer and does not require

the end
user to be aware of it.

3.3

Drawbacks of Object
-
Orientation

The mindset required by a programmer to “think in OO” as it is often put, requires a steeper learning
curve

than a procedural language
. The programmer must be able to embrace the breakdown an
d modelling
of objects rather than resist it. This often proves difficult for a programmer
more comfortable with
a
simpler procedural mindset
, who can be tempted to build a very flat class hierarchy as a minimal
framework for falling back into procedural
c
ode
.

The programmer must also deal with the necessary
synt
actic complexity that an object
-
oriented programming language requires

in order

to provide
object
-
oriented

features.


Object
-
oriented languages also execute code more slowly and require more resourc
es compared to their
procedural counterparts
.

F
or this reason
they
may be unsuited to computationally intensive processes, or
imbedded systems. Indeed for a small system there is also a programming overhead associated with
putting the object model into pla
ce. However for a large system this overhead is negligible compared to
the benefits the object model provides.

Advancements in hardware and attempts at minimizing the
overhead associated with object
-
orientation, particularly for embedded systems, also serv
e to somewhat
reduce the significance of this drawback.

3.4

Existing
Astronomical
Software Libraries

Unfortunately the initial complexity and learning curve required have meant that many non
-
professional
programmers have avoided object
-
oriented languages,
view
ing

them as too
difficult

or too distracting
from the desired goal of building what often begins as a simple system. Scientists in general and
astronomers in particular are no exception. Often a system that starts its life as simple grows in
complexity. Be
ginning with a more powerful object model can mean the difference between having a
system that is flexible and grows, and
having to abandon the project and


start from scratch

. This has
been increasingly realized in the business world where systems have g
rown quickly in complexity, and
object methodologies have become a pre
-
requisite for building successful system
s
. This realization is
taking longer to percolate through the scientific community.


While other a
stronomy libraries exist
,

few are publicly avai
lable. Fewer still are written in object
-
orie
nted
languages, with generality
in mind. Much of today’s software is single purpose, may have cumbersome or
poorly written

FORTRAN,C, BASIC
or Pascal
components
. Much of the astronomy software
available

run
s

onl
y under a UNIX style operating system. A
n extensive

listing of existing software is beyond the
scope of this document.
(See the reference
Astronomy Software Servers

at the end of this document
for a
longer
listing

of publicly available software
).
However,
t
wo good
e
xamples of well written reuse
-
oriented
software
are
:


1.

AIPS++ (
Astronomical Information Processing System)
written in C++ for data reduction
.
Source code
is
available for public download.


2.

CLEA (Contemporary Learning Experiences in Astronomy). Thi
s is an educational package
intended to teach astronomy students basic concepts in observational astronomy through the use
of simplified practical simulations. This software,
while not object
-
oriented, does show thought
towards software reuse in the develo
pment of common
components such as a common menuing
system, and
simulated telescopes/sky views.
The s
ource code is not publicly available.


See references for web pages associated with the software. Unfortunately, such examples of reuse are still
the excep
tion
.
Furthermore,
the software listed is clearly focused in one area


there is no underlying
generic library of routines with a more general purpose underlying either.

4

Software Environment

A number of languages exist today which incorporate object
-
orient
ed features
, each with their advantages
and disadvantages
. However few are true first class object
-
oriented languages. C++
(perhaps the most
widely us
ed in the 1980s and early 1990s)

for example allows

the programmer to combine procedural and
object
-
orient
ed code, which ultimately defeats the purpose of using an object
-
oriented language
(
by
eliminating the reuse of objects
)
.

Early languages such as Simula and Smalltalk tend to be used in
specialized areas or by a limited user group. Other new languages such

as Eiffel have
, for various reasons,

never achieved the “critical mass” of users required to make them common.


Java, having internet capabilities and introduced early in the early business “.COM boom” of the late
1990s has several advantages and is a tr
ue object
-
oriented language. Unfortunately, its popularity today is
waning for a number of reasons. Chief among these is that it is not a fast or memory efficient language
due to its multi
-
platform interpretative nature. Another reason is legal disputes be
tween Sun
Microsystems, the creators of Java, and Microsoft, the undisputed market leader in the operating systems
market which
has

led to waning support for the language. As a result, while at present Java is a widely
used language with several advantages
, its fu
ture is by no means guaranteed.


C# is a proprietary language developed by Microsoft to compete with Java. In many ways it res
embles
Java

-

It has similar C
-
like syntax and

is a true first class
object
-
oriented

language. It is available only on
32
-
bit and 64
-
bit modern Microsoft
Windows
operating systems. By sacrificing portability and learning
from the choices made in creating and implementing Java, performance gains
have been realized.
Furthermore code written in C# is also interoperable with othe
r languages that are part of Microsoft’s
.NET platform (eg. Visual Basic .NET). It is by no means certain that this language will become dominant
in the next few years, however Microsoft is pushing for it to be the language of choice for writing business
s
oftware in a
Microsoft W
indows environment, making it unlikely that this language will become
irrelevant in the near future.


The chief drawback of writing
an
astronomy library in C# rather than Java is its lack of portability.
C# is
he
avily tied to the Wi
ndows 32
-
bit and 64
-
bit operating system.
Many universities
and research
institutions
use UNIX or UNIX
-
like operating systems as standard
. This is true in part for historical
reasons, and
also
because
traditionally
these operating systems

have been
more ef
ficient for more
intensive computation

For these reasons many
existing astronomical software packages only run
in a
UNIX environment (or that of a derivative such as
Linux
)
. This makes immediate integration
of this
software
with
GAMF
impossible.

A second
disadvantage is that the relatively new language of C# has not
matured to the point that other languages such as Java have. When the GAMF project was started, there
were no fully featured, standard 3D drawing libraries available for C#, although Direct3D a
nd DirectX

integration was planned.


As a matter of convenience and to save time GAMF was written and tested entirely on Windows XP,
using the first non
-
beta release of Visual Studio .NET. The software should wor
k on any platform that
fully sup
ports a Micr
osoft .NET environment i.e.
a
ll 32
-
bit and 64
-
bit windows operating systems since
W
indows 98
S
econd
E
dition.

While the
GAMF
source code itself is open source software, the
use of
Visual Studio .NET

in the initial release means that its use for further deve
lopment, while not required is
desirable. If this is not possible, the .NET SDK can be used for building models, though it would be slow
to work in this way to build up forms and visualization classes. The use of proprietary tools to build open
source soft
ware is currently a highly controversial issue in the open source community.

5

GAMF
Astronomical Models

Due to the size and nature of the GAMF project, the astronomical models presented in this library are not
robust research grade solutions. Rather these ar
e often the simplest available model, and are of a level
suited to teaching and demonstration of concepts. Some of the simplest models represent a small group of
equations. The simplicity of these models should make the code more accessible to scientists w
ishing to
study the library code to understand its benefits. It is important however to demonstrate that the concept
scales. For this reason three more complex models were introduced.

5.1

Basic Models

The basic models presented include a
narrow
sample of some
of the most fundamental physics found in
introductory astronomy and physics textbooks. A class o
f physical constants includes a variety of widely
used constants that are available globally to members of the library.

Similarly another class contains
common
astronomical quantities.
A Blackbody class
implements
We
i
n’s law as a set of methods to
calculate maximum wavelength from temperature and vice versa.

In addition blackbody luminosity (based
on temperature) is modelled. A simple Star class uses the Blackbod
y as a surface and adds absolute
magnitude, and apparent magnitude at a distance for a spherical blackbody star.
A

simple Wave

class

models
the relationship between energy of an electromagnetic wave and its frequency (E=hf).


There are a number of obvious
wa
ys in which these basic models

can be extended in future to more
completely cover the astronomical basics, at least at an educational level.
M
ore
of these basic equations
can be modelled. Modelling can be done in a more complete manner, or with more dept
h. With more time

available
, it would be possible introduce many if not all of the equations from an introductory physics,
astronomy, or astrophysics text book.

This opens up the possibility of visualization as more equations are
modelled that describe a p
articular object (eg a spectra). T
o accomplish this, t
he models may ne
ed to be
more complex than the

trivial ones
of the first release
.

5.2

Complex Models

The complex models were based on existing code found in introductory astrophysics texts. The code on
whic
h they are based is procedural.
In this code, w
here numerical methods were employed in
two

of the
models, code was repeated and only the general principles and techniques were reused. A large part of the
adaptation of these models was to build a
reusable

s
et of methods for numerical integration, and show that
by abstracting and encapsulating this behaviour, the code itself could be reused. This adaptation was not
trivial, and the some of the code is hard to recognise as matching the original text examples.
However this
leaves the writer of the astrophysical code in a position of confidence that the numerical methods work,
and do not need to be re
-
tested

repeatedly for each item of code that employs the technique
.


These examples, due to their complexity
,

de
monstrate the potential of developing
object
-
oriented

code
much more convincingly. Unfortunately, for a single individual, each model can take days to

translate or
write, then debug. Therefore
due to time constraints
even these models are trivial from a re
search
standpoint.

They are however complex enough to be demonstrative in an educational context.

It would be
natural to progress these aspects of the library in the form of more complex, research grade models, and
by expanding the number of these models
.
This would

provide a useful set of pre
-
built models on which to
build
another layer of
even more complex models, and model systems that incorporate a variety of
processes.


In order to produce closely matching results as seen in Hellings P. 1994 for the re
stricted three body
problem and polytrope models below, simultaneous equations were solved using the midpoint (Cauchy)
method as described in Hellings P. 1994 chapter 1. Note however, that unlike
changing
the original
programs, changing the method of solut
ion to a higher order method such as Runge
-
Kutta is a trivial
matter.
A single function call needs to be changed to achieve this, whereas in the original code more
substantial
changes would be required. The reason for this simplification is that the differ
ential equations
have been abstracted and a generic class for solving a system of differential equations by each method has
been written. (Even these classes are simplified as no
ne of the

methods for solving differential equations
included in the first ver
sion of the library

are adaptive
). The present form of the solving methods is
cumbersome since the equations must be translated into a form tha
t is easily modelled by a class. H
owever
a strong case can be presented that the
procedural code
is
even more cum
bersome. See Press W.H. et al.
1997 for
procedural numerical methods code in C. Chapter 16 describes adaptive and non
-
adaptive
algorithms for Runge
-
Kutta integration. The ability to abstract and encapsulate these numerical methods is
possibly one of the be
st demonstrations of the success of GAMF version 1.

5.2.1

Two Body
Problem

The
Simple2BodyProblem

class
is a
simple
model
of
the
orbit of a minor body of infinitesimal mass
around a more massive body. This matches an idealized simulation of a planet orbiting its

star in which all
other masses in the stellar system are ignored and the mass of the star is much larger than that of the
planet. The model is based on
the ideas presented in chapter two

of
Carroll
B.W.
and Ostlie

D.A.

1996
,
and on the FORTRAN code in app
endix G.
The orbit
conforms to the shape of
an eclipse and approximate
n
umerical methods are not needed
. This code is therefore
compact and easy to understand.

Parameters for
the model are

the mass of the primary body (star), the semi
-
major axis of the orb
iting body (planet), the
eccentricity of the orbit and the number of steps in the orbit to calculate.

The output is position of
the
orbiting body
in a reference frame where the
primary is at one focus of the eclipse.

5.2.2

Restricted Three Body
Problem

The class

SimpleRestricted3BodyProblem

is based on the model presented in Hellings P. 1994
. The
classi
cal formulation of the general three

body problem is considered analytically intractable due to the
mathemati
cal complications associated


nine

second order diffe
rential equations must be solved
simultaneously. The restricted
three

body problem is however more approachable and approximates the
common
scenario

of a binary system moving about a common centre of gravity

(the primaries)
, orbited
by

a smaller
third

body
.



Due to its smaller mass, the effect of the third body upon the first two may be ignored. To further simplify
this problem, circularly orbits are assumed, and in order to be able to describe the system in two
dimensions,
instead of 3, it is assumed that

the third body orbits in the same plane as the orbit of the first
two.
Finally
, a
reference frame that co
-
rotates with the primaries is chosen,
reducing the problem to one of
an o
rbit of the third body around
the centre of mass of the primaries.


The rest
ricted three body problem is successful in approximately modelling

a number of
orbital systems
which are of practical interest
:


1.

The Earth, Sun, Moon system

2.

The Earth, Moon and an artificial satellite

3.

The Sun, Jupiter and an asteroid

4.

A triple stellar syste
m in which two

more massive stars orbited by a third, smaller companion

5.

A binary
stellar
system orbited by a planet.


See Hellings P. 1994 p 57 for a more detailed description of the approximations involved for the first
three.


Given more time,
it would
be possible to draw on
a number of excellent sources of procedural orbital code
available as concrete examples to build object
-
oriented classes in GAMF

for solving problems

in celestial
mechanic
s
.

Many of these describe the problems in a way accessible to
the novice or intermediate
astrophysicist. For further details see
Danby J. M. A. 1992; Boulet D. L. Jr. 1991; Danby J. M. A. 1997;
and
Foster C. C. 1999.

In these texts m
ethods described include those of Olbers, Laplace, Gauss.
T
he
solution of
t
wo
-
, three
-

and N
-

body problems are discussed.

5.2.3

Polytrope

A polytrope or polytropic star is the simplest stellar model available

that is
based on theory that is
essentially correct
. It is
temporally

static i.e.
n
o time d
ependent processes are modelled.
Modern
resear
ch
grade models are significantly more sophisticated
.

Like other more complex models however,
it is a
hydrostatic model of infinitesimal shells with boundary conditions at the core and surface

and is
based on
the balance between p
ressure and gravitational
force
.

The
class
SimplePolytrope

represents
a polytrope as
described in

chapter four

of Hellings P. 1994. Th
is

model uses classical Newtonian descriptions for the
forces. Refer to Hellings P. 1994 for a more detailed description.


This model was chosen for

its simplicity to ensure it could be completed within the timeframe of the
o
riginal GAMF project. Two more
complex models considered but rejected
were
a homogeneous stellar
model
which does include
time dependent
processes presented in chapter five

of Hel
lings P. 1994 and the
STATSTAR program found in appendix H of
Carroll
B.W.
and Ostlie

D.A.

1996
.

The algorithms used by
each, while more sophisticated than the Polytrope model are once again greatly simplified and
demonstrative in nature.

6

Library
Design

6.1

R
o
le of Encapsulation

When the object
-
oriented paradigm was first proposed there were many early naïve attempts to build
models which would work as black boxes in any situation, so that once modelled, an object or process
would never have to be modelled agai
n. The problem with this approach is that different models need to
be used to model different aspects/conceptualizations of an object for any given application. The subset of
the behaviour of even the most concrete object will vary with application. A car
for instance will be
modelled differently for an engineering process than for a sales process. In this particular example, both
sets of functionality could be encapsulated within the one object but as the need the applications grow so
to
o

will the need to
build larger and more complex classes. Furthermore there are other applications where
different aspects of the same object would conflict.


Since it is the view of the author that an astronomer, physicists or mathematician should know the inner
workings of

the models they build, an intentional and significant departure from the current object
-
oriented paradigm has been made in building GAMF.
Where possible, a
ll methods, attributes and classes
are public. It is the opinion of the author that, while this can
be abused, the additional overhead required to
build a library in which data hiding is employed are not justified by the supposed benefits

in this instance
.
This is particul
arly true since i
n

the case of a complex astronomical model, the purpose of the cod
e is the
accurate modelling of a scientific process. The details of the model are crucial to its integrity. Avoiding
this complexity would translate to
joining potentially unsuitable models together. T
he library is written for
astronomers not application d
evelopers with
out a

knowledge of or interest in astronomy
, p
hysics
, and
mathematics

on which it is based.


Note that where interaction with existing .NET frameworks is required, different access levels are in fact
use
d in GAMF. There are two

reasons for th
is:


1.

.NET framework classes which must be extended have pre
-
existing methods and attributes, many
of which are protected. It is not possible to override these methods at
higher
access levels, and
while they may be wrapped (
i.e.

another function can be writ
ten that is public which calls the
protected member), this adds to the complexity

of the library needlessly
. Since the intent of
making members public is to simplify the model, it makes little sense to
wrap these methods
.


2.

Code generated by Visual Studio .
NET contains members whose access levels vary. Some of this
code has been modified, however it makes little sense to spend time changing access levels to
generated code which is never referred to directly

by non
-
generated code
. Access levels have
only been

changed where it was deemed both necessary and appropriate to do so.


The
decision
to make class members public where possible is a definite
departure from conventional
wisdom, which while no
t

unprecedented will prove controversial to many experienced pro
grammers. It is
a decision which will need to be revisited in the context of any subsequent releases of the library.

6.2

Library Structure

In order to ensure classes and models can interoperate, each class requires that standard solutions return
results in S.I
. Units

by default
. The library is divided into
four

sections, each residing in a
single

file for
release 1. Later releases will require further division of these classes and a directory structure with
multiple files will be appropriate.

This is particular
ly true of generated classes edited visually using Visual
Studio .NET. The current version of Visual Studio .NET only allows the first form displayed in a file to be
visually manipulated.

6.2.1

Mathematical Classes

The file
Math.cs contains elementary classes fo
r the representation of points in two
-
, three
-

and N
-

dimensional space and
the
plotting
of
their curves. More complex classes for representing equations,
combining them into a system and performing integration (numerical methods), and manipulating
polynom
ials have also been written. The majority of this portion of the code has been written
out of

necessity of performing the required calculations in the physics and astronomy classes. The Polynomial
class is the major exception to this ru
le as it is not used

at present.


The current library is cumbersome in its representation of equations. This representation is not intuitive
and will require some study for any per
son wishing to use the library. H
owever it is much simpler than a
library that could parse a mor
e natural representation.
More
control over terminating conditions and
stepwise control of numerical methods should be a part of the next release of the
GAMF
library.


The scope of a good generalized mathematical library is one of a
n

entire
separate projec
t
. Future editions
of GAMF may either be written using an open
object
-
oriented

mathematics library, or
the scope of the
current library may be extended and the library built up.

6.2.2

Physics Classes

The file Physics.cs contains classes which model physics
that

is not specific to astronomical processes
such as the physics of a wave and that of a blackbody. Physical constants are also contained in this file.

The physics portion of GAMF is certain to grow in the size and number of models present in future
releases
.

6.2.3

Astronomy Classes

The file Astronomy.cs contains astronomical quantities and the astronomical models

which are
GAMF’s
purpos
e for
having been written
. They are discussed in detail in the section
GAMF Astronomical Models
.

In order to build the main GAMF d
emo
nstration

application a number of
visualization classes
were added:

a component to display a visual representation of a star, and a number of forms for the input of parameters
and display of results for each model. Since these are potentially reusable,
these visualization classes were
also included in the library
, and not as part of the demonstration application
. Note however that the Visual
Studio .NET environment only displays the first form in a source file for graphical editing. For this reason,
futu
re versions of GAMF should split each visualization class out into its own file.

6.2.4

Utilities

Classes

The file Utility.cs is intended to contain miscellaneous support classes that do not belong to any of the
other categories. Currently the only class belongin
g to this categ
ory is a printable display form class.

6.3

Testing

and Documentation

Testing consists of
a
simpl
e test case or set of test cases
, in the form of a test program,

for each non
-
trivial
class in the library. These test applications

have been collect
ed into their own project

(see Appendi
x A
GAMF
)

and have been distributed with the library. In addition, the main demonstration application allows
for testing of each model in an ad hoc manner, as each of the model’s parameters can be manipulated.
Where th
e models are based on existing code, the existing
software
, or output accompanying its
documentation was used to ensure that output from GAMF code matches existing code. At this level of
complexity
,

testing
has been
informal, and
thus
no
formal
test plan w
as written.

This is appropriate for a
proof of concept, but more complex testing will be required for
subsequent
releases of the library.


Documentation consists of this
document

which outlines the project itself, and documentation for the
library. Library

documentation
consists of h
eaders for each file, including a copyright notice
and
description,

C# comments embedded within the code. C# documentation tools were then used to produce
HTML and XML documentation for the library

from imbedded comments
.

HTML d
ocumentation is
located in the

GAMF library

archive (See
the
README.TXT file

embedded in
Appendix A)

7

Results

GAMF release 1.0, an
Object
-
oriented

library written in C# within the Microsoft .NET framework has
been successfully generated. This release is a
proof of concept with the limited functionality described
above. Though somewhat artificial in nature, due mainly to the limitations of the scope of the library, a
single integrated demonstration application which uses the majority of the code within the l
ibrary was also
successfully created.


The
GAMF
models came from a variety of sources. Simple models were based on simple equations
familiar to any Astronomy student. More complex models were based on pre
-
existing code written in
procedural languages (FOR
TRAN and
BASIC
).
The equivalence of the GAMF models with the code on
which they are based has been tested in a limited fashion, and the code has been shown to be correct for
selected cases.

One notable exception is the SimplePolytrope class which handles b
oundary conditions
slightly differently to the original code. (Only whole steps are considered at the boundary, not half steps as
in the original code). This deviation from expected results appears to be minor.
In general the use of
models limited to a few

pages of code has made the construction process relatively problem
-
free.


A higher level of reuse of mathematical code was achieved by using math classes for the numerical
methods. Furthermore the
physics and astronomical
models created for this library a
re the
mselves
extensible and reusable, as is the intent of the library. While none of the models are research grade, each is
u
sable in an educational context, and
it would be possible to build research grade models into future
editions of t
he library.

8

Conc
lusion

The GAMF
project
has
successfully
demonstrated the potential for using a modern object
-
oriented
language in the context of astronomical software to improve reuse.

In itself this is not a surprising result,
however having a concrete example at this l
evel of object
-
oriented software outperforming procedural
counterparts highlights the need for astronomers who
wish to
write
quality
software to keep up to date
with modern techniques.


As this project is a proof of concept it may be built upon in a number

of ways

including
:


1.

The mathematical classes can be extended to provide a more solid and complete mathematical
base for the rest of the library
.


2.

The existing
physical and astronomical
models can be further tested, improved and extended
.


3.

New
physical and

astronomical
models

and corresponding visualization classes

can be added.
Both educational models and more complex research grade models could be included in
subsequent releases.


4.

More applications could be written based on existing and future editions of

the library. As the
library grows applications based on it will be less artificial than the demonstration application
included in this proof of concept.

Depending on the direction taken in developing the library, a
wide variety of applications are possibl
e


from amateur software such as planetarium and
charting software, to image manipulation and data reduction software. More importantly each
model added to the library will potentially be reusable allowing for a blend of models which
would typically requi
re several items of separate and more specialized software.


5.

The library could be translated to another modern object
-
oriented language such as Java, or an
older one such as C++ or Smalltalk. Translation to Java for non
-
graphical components should be
an ea
sy task due to sim
ilarities between the languages and would provide for a cross
-
platform,
albeit slower library.


To this end, the source code has been released under the lesser GNU public license, in the hope that others
in the astronomical community will

both build upon the existing code and

see the advantages of the
general approach taken.

9

Disclaimer

Microsoft,
Microsoft Windows
, Microsoft Visual Studio, Microsoft .NET
, Microsoft Visual BASIC

and
C# are

registered

trademark
s

of Microsoft
C
orporation. UN
IX is a
registered
trademark of
T
he Open
Group.
Linux is a registered trademark of Linus Torvalds.
Java

is a
registered
trademark of Sun
Microsystems.


The views expressed in this document are those of the author. No warranty on the views or accuracy of
in
formation contained herein, or on its fitness for a particular purpose is granted.

10

Acknowledgements

I’d like to thank David Blank for his rapid and friendly feedback, instruction and guidance throughout the
subjects
Astronomy
Written

Project

and
Astronomy
Research Project
, and Alex Hons for his tireless work
in support of the Astronomy Internet Masters program
.


In addition I received invaluable feedback, wisdom and guidance from the students of the
Astronomy
Research Project

specifically and from the stude
nts of the
Astronomy Internet Masters

program in
general.
Christopher Fulton was particularly supportive and helpful in reading early drafts of this
document
.
The help and support I received
from the Astronomy Internet Masters community
was vital to
crysta
llizing my vision of just what the library should be and how it should be described to other students
and professionals

in the field of astronomy
.


This work would have been much more difficult without the understanding and patience shown by my
colleagues
at Sandstone Technology Pty. Ltd. In particular Bill Nicholls and Bob Hall who arranged that I
have the time away from work to complete the last semester of the degree of which this project is a part on
a full time basis.


Naturally, any omissions, mistake
s or
other
shortcomings are my own.

11

References

ACM (Association for Computer
Machinery
) portal journals

http://store.acm.org/acmstore/dir.icl?secid=19&orderidentifier=or
derid


AIPS++

(
Astronomical Information Processing System
-

Software)

http://aips2.nrao.edu/docs/aips++.html


Astronomy Software Servers

http://www.cv.nrao.edu/fits/www/yp_software.html


Boulet D. L. Jr. 1991
Methods of Orbit Determination for the Micro Computer

ISBN 0
-
993396
-
34
-
4

Willmann
-
Bell Inc., Virginia, U.S.A.


Carroll
B.W.
and Ostlie

D.A.

1996

An Introduction to Modern Astrophy
sics

Addison
-
Wesley Publishing Company , Inc.

ISBN 0
-
201
-
54730
-
9


CLEA

(
Contemporary Learning

Experiences in Astronomy


Software)

http://www.gettysburg.edu/academics/physics/cl
ea/CLEAhome.html


Danby J. M. A. 1992
The Fundamentals of Celestial Mechanics Second Edition
, Third Printing (Revised
and Enlarged)

ISBN 0
-
943396
-
20
-
4

Willmann
-
Bell Inc., Virginia, U.S.A.


Danby J. M. A. 1997
Computer Modeling: From Sports to Spaceflight…
From Order to Chaos

Pages 215
-
220

ISBN 0
-
993396
-
51
-
4

Willmann
-
Bell Inc., Virginia, U.S.A.


Foster C. C. 1999
The Orrery: Computer Models of Astronomical Systems

Chapters 2 and 3

ISBN 0
-
993396
-
65
-
4

Willmann
-
Bell Inc., Virginia, U.S.A.


Henderson
-
Sellers B.
1992
A Book of Object
-
Oriented Knowledge

ISBN 0
-
13
-
059445
-
8

Prentice Hall


Hellings P. 1994
Astrophysics with a PC


An Introduction to Computational Astrophysics

Willmann
-
Bell, Inc.

ISBN 943396
-
43
-
3


Hostetter

C. 2002
Survey of Object Oriented Programming

Languages

http://www.rescomp.berkeley.edu/~hossman/cs263/paper.html


H
-
R Calc for Windows

(Software) Version 2.0

David C. Irizarry 1996

xerxees@ix.netcom.com


Kaufman, W. J. III and Freedman, R. A. 1998
Universe 5
th

Edition

W.H. Freedman and Company, New York

ISBN 0
-
7167
-
3495
-
8


Meyer, B. 1988
Object
-
oriented Software Construction

ISBN 0
-
13
-
629031
-
0

Prentice Hall International


OOPSLA
-

Object
-
Oriented Programming, Systems Languages and Applications Conferences

http://oopsla.acm.org/


Press W.H., Teukolsky S.A., Vetterling W. T., Flannery B.P. 1997
Numerical Recipes in C: The Art of
Scientific Compu
ting 2
nd

Edition

ISBN 0
-
521
-
43108
-
5

Cambridge University Press

http://www.ulib.org/webRoot/Books/Numerical_Recipes/bookc.html


Turbo C++ 3.0 User’s Guide

1992: Chapter 4 Object
-
oriented programming with C++

Borland International

Appendices

Appendix A
-

GAMF Library Distribution


The following zip file contains the GAMF library, including documentation and test applications:




Please see the included README.T
XT file for a description of

the contents of the archive.

See
COPYING.TXT for the copyright notice and disclaimers.

Appendix B


Test Program Output

Appendix B.1
-

TestFlux

Stellar Flux Calculator: GAMF demo 2


Menu

[C] Calculate Stellar Flux

[E] Exit the
program


Choice: c

Enter the radius of the Star in metres: 6.8599E8

Enter the luminosity of the star in Watts: 3.9E26

Enter your distance from the centre of the star in metres: 1.496E11


The Star's radius is 685990000 m

The Star's luminosity is 3.9E+26 W

T
he Star's flux at the surface is 65950664.1353442 W/m^2

At your distance from the Star of 149600000000 metres, the flux is
1386.72886623

329 W/m^2


Menu

[C] Calculate Stellar Flux

[E] Exit the program


Choice:

Appendix B.2
-

Test
WeinsLaw

Wein's Law Calcula
tor: GAMF demo 1


Menu

[T] Calculate Surface Temperature of a Star (enter max emission
wavelength)

[W] Calculate Max Emission Wavelength of a Star (enter surface
temperature)

[E] Exit the program


Choice: T

Enter the maximum emission frequency in metres: 5
00E
-
9

Wavelength of maximum emission is 5E
-
07 metres

The star's surface temp must be 5800 Kelvin


Menu

[T] Calculate Surface Temperature of a Star (enter max emission
wavelength)

[W] Calculate Max Emission Wavelength of a Star (enter surface
temperature)

[
E] Exit the program


Choice: W

Enter the temperature in degrees Kelvin: 5800

The star's surface temp is 5800 K

Wavelength of maximum emission must be 5E
-
07 metres


Menu

[T] Calculate Surface Temperature of a Star (enter max emission
wavelength)

[W] Calcula
te Max Emission Wavelength of a Star (enter surface
temperature)

[E] Exit the program


Choice:

Appendix B.3
-

TestSimplePolytrope


i x=r/rn f h log(P/Pc) log(d/dc) LM(r)

----

---------

---------

---------

---------

---------

------
---


0 0.00000 1.00000 0.00000 0.0000 0.0000 0.0000


1 0.05000 0.99958
-
0.01666
-
0.0005
-
0.0003 0.0000


2 0.10000 0.99833
-
0.03329
-
0.0018
-
0.0011 0.0003


3 0.15000 0.99626
-
0.04983
-
0.0041
-
0.0024

0.0011


4 0.20000 0.99335
-
0.06627
-
0.0072
-
0.0043 0.0027


5 0.25000 0.98963
-
0.08256
-
0.0113
-
0.0068 0.0052


6 0.30000 0.98510
-
0.09866
-
0.0163
-
0.0098 0.0089


7 0.35000 0.97976
-
0.11455
-
0.0222
-
0.013
3 0.0140


8 0.40000 0.97364
-
0.13018
-
0.0290
-
0.0174 0.0208


9 0.45000 0.96674
-
0.14552
-
0.0367
-
0.0220 0.0295


10 0.50000 0.95909
-
0.16054
-
0.0454
-
0.0272 0.0401


11 0.55000 0.95069
-
0.17522
-
0.0549
-
0
.0329 0.0530


12 0.60000 0.94157
-
0.18951
-
0.0654
-
0.0392 0.0682


13 0.65000 0.93174
-
0.20340
-
0.0768
-
0.0461 0.0859


14 0.70000 0.92123
-
0.21686
-
0.0891
-
0.0534 0.1063


15 0.75000 0.91005
-
0.22985
-
0.1023

-
0.0614 0.1293


16 0.80000 0.89824
-
0.24237
-
0.1165
-
0.0699 0.1551


17 0.85000 0.88582
-
0.25438
-
0.1316
-
0.0790 0.1838


18 0.90000 0.87280
-
0.26588
-
0.1477
-
0.0886 0.2154


19 0.95000 0.85923
-
0.27683
-
0.1
647
-
0.0988 0.2498


20 1.00000 0.84512
-
0.28723
-
0.1827
-
0.1096 0.2872


21 1.05000 0.83051
-
0.29707
-
0.2016
-
0.1210 0.3275


22 1.10000 0.81541
-
0.30633
-
0.2216
-
0.1329 0.3707


23 1.15000 0.79987
-
0.31500
-
0.2424
-
0.1455 0.4166


24 1.20000 0.78391
-
0.32307
-
0.2643
-
0.1586 0.4652


25 1.25000 0.76757
-
0.33055
-
0.2872
-
0.1723 0.5165


26 1.30000 0.75086
-
0.33743
-
0.3111
-
0.1867 0.5703


27 1.35000 0.73382
-
0.3437
0
-
0.3360
-
0.2016 0.6264


28 1.40000 0.71649
-
0.34936
-
0.3620
-
0.2172 0.6848


29 1.45000 0.69889
-
0.35443
-
0.3890
-
0.2334 0.7452


30 1.50000 0.68105
-
0.35890
-
0.4171
-
0.2502 0.8075


31 1.55000 0.66300
-
0.
36278
-
0.4462
-
0.2677 0.8716


32 1.60000 0.64477
-
0.36607
-
0.4765
-
0.2859 0.9371


33 1.65000 0.62639
-
0.36879
-
0.5079
-
0.3047 1.0040


34 1.70000 0.60789
-
0.37094
-
0.5404
-
0.3243 1.0720


35 1.75000 0.58930

-
0.37254
-
0.5742
-
0.3445 1.1409


36 1.80000 0.57063
-
0.37360
-
0.6091
-
0.3655 1.2105


37 1.85000 0.55194
-
0.37413
-
0.6453
-
0.3872 1.2805


38 1.90000 0.53322
-
0.37415
-
0.6827
-
0.4096 1.3507


39 1.95000 0.51
452
-
0.37368
-
0.7215
-
0.4329 1.4209


40 2.00000 0.49585
-
0.37273
-
0.7616
-
0.4570 1.4909


41 2.05000 0.47725
-
0.37132
-
0.8031
-
0.4819 1.5605


42 2.10000 0.45872
-
0.36947
-
0.8461
-
0.5077 1.6294


43 2.15000
0.44030
-
0.36720
-
0.8906
-
0.5344 1.6974


44 2.20000 0.42200
-
0.36453
-
0.9367
-
0.5620 1.7643


45 2.25000 0.40385
-
0.36148
-
0.9845
-
0.5907 1.8300


46 2.30000 0.38585
-
0.35806
-
1.0339
-
0.6204 1.8941


47 2.3500
0 0.36804
-
0.35431
-
1.0853
-
0.6512 1.9567


48 2.40000 0.35042
-
0.35023
-
1.1385
-
0.6831 2.0174


49 2.45000 0.33302
-
0.34586
-
1.1938
-
0.7163 2.0761


50 2.50000 0.31583
-
0.34122
-
1.2514
-
0.7508 2.1326


51 2.
55000 0.29889
-
0.33632
-
1.3112
-
0.7867 2.1869


52 2.60000 0.28220
-
0.33118
-
1.3736
-
0.8242 2.2388


53 2.65000 0.26577
-
0.32583
-
1.4387
-
0.8632 2.2882


54 2.70000 0.24962
-
0.32029
-
1.5068
-
0.9041 2.3349


55

2.75000 0.23375
-
0.31458
-
1.5781
-
0.9469 2.3790


56 2.80000 0.21816
-
0.30872
-
1.6531
-
0.9918 2.4203


57 2.85000 0.20287
-
0.30272
-
1.7319
-
1.0392 2.4588


58 2.90000 0.18789
-
0.29661
-
1.8152
-
1.0891 2.4945



59 2.95000 0.17321
-
0.29041
-
1.9036
-
1.1421 2.5273


60 3.00000 0.15885
-
0.28413
-
1.9975
-
1.1985 2.5572


61 3.05000 0.14480
-
0.27780
-
2.0981
-
1.2589 2.5842


62 3.10000 0.13107
-
0.27143
-
2.2063
-
1.3238 2.60
84


63 3.15000 0.11766
-
0.26504
-
2.3235
-
1.3941 2.6298


64 3.20000 0.10456
-
0.25864
-
2.4515
-
1.4709 2.6485


65 3.25000 0.09179
-
0.25225
-
2.5930
-
1.5558 2.6644


66 3.30000 0.07934
-
0.24590
-
2.7513
-
1.6508
2.6778


67 3.35000 0.06720
-
0.23959
-
2.9315
-
1.7589 2.6888


68 3.40000 0.05538
-
0.23334
-
3.1416
-
1.8850 2.6974


69 3.45000 0.04387
-
0.22717
-
3.3946
-
2.0368 2.7039


70 3.50000 0.03266
-
0.22109
-
3.7149
-
2.2289

2.7084


71 3.55000 0.02176
-
0.21513
-
4.1559
-
2.4936 2.7112


72 3.60000 0.01115
-
0.20930
-
4.8819
-
2.9291 2.7125


73 3.65000 0.00083
-
0.20363
-
7.7045
-
4.6227 2.7128


Central Pressure Pc (dyne/cm^2): 4.329641E+14

Average Density (g/cm^3) : 0.105185

Central Density dc (g/cm^3) : 0.630583

Mass Parameter (L) : 1.356410

Distance Unit (Solar Radii) : 0.821003

Appendix B.4
-

T
est2BodyProblem


Mass of star (AU): 1.000000000

Semi
-
major axis (AU): 1.000000000

Eccentricity: 0.000000000


t(yr) x(AU) y(AU)

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

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

-----------


0.000 1.000 0.000


0.010 0.998 0.063


0.020 0.992 0.127


0.
030 0.982 0.189


0.040 0.968 0.251


0.051 0.950 0.312


0.061 0.928 0.372


0.071 0.903 0.430


0.081 0.874 0.486


0.091 0.841

0.541


0.101 0.805 0.593


0.111 0.766 0.643


0.121 0.724 0.690


0.131 0.679 0.735


0.141 0.631 0.776


0.152 0.580 0.815


0.162

0.527 0.850


0.172 0.472 0.881


0.182 0.415 0.910


0.192 0.357 0.934


0.202 0.297 0.955


0.212 0.236 0.972


0.222 0.174 0.9
85


0.232 0.111 0.994


0.242 0.048 0.999


0.253
-
0.016 1.000


0.263
-
0.079 0.997


0.273
-
0.142 0.990


0.283
-
0.205 0.979


0.293
-
0.266 0.964


0.303
-
0.327 0.945


0.313
-
0.386 0.922


0.323
-
0.444 0.896


0.333
-
0.500 0.866


0.343
-
0.554 0.833


0.354
-
0.606 0.796



0.364
-
0.655 0.756


0.374
-
0.701 0.713


0.384
-
0.745 0.667


0.394
-
0.786 0.618


0.404
-
0.824 0.567


0.414
-
0.858 0.514


0.424
-
0.88
9 0.458


0.434
-
0.916 0.401


0.444
-
0.940 0.342


0.455
-
0.959 0.282


0.465
-
0.975 0.220


0.475
-
0.987 0.158


0.485
-
0.995 0.095


0.495
-
0.999 0.032


0.505
-
0.999
-
0.032


0.515
-
0.995
-
0.095


0.525
-
0.987
-
0.158


0.535
-
0.975
-
0.220


0.545
-
0.960
-
0.282


0.556
-
0.940

-
0.342


0.566
-
0.916
-
0.401


0.576
-
0.889
-
0.458


0.586
-
0.858
-
0.514


0.596
-
0.824
-
0.567


0.606
-
0.786
-
0.618


0.616
-
0.745
-
0.667


0.626

-
0.702
-
0.713


0.636
-
0.655
-
0.756


0.646
-
0.606
-
0.796


0.657
-
0.554
-
0.833


0.667
-
0.500
-
0.866


0.677
-
0.444
-
0.896


0.687
-
0.386
-
0
.922


0.697
-
0.327
-
0.945


0.707
-
0.267
-
0.964


0.717
-
0.205
-
0.979


0.727
-
0.142
-
0.990


0.737
-
0.079
-
0.997


0.747
-
0.016
-
1.000


0.758

0.047
-
0.999


0.768 0.111
-
0.994


0.778 0.174
-
0.985


0.788 0.236
-
0.972


0.798 0.297
-
0.955


0.808 0.357
-
0.934


0.818 0.415
-
0.910


0.828 0.472
-
0.882


0.838 0.527
-
0.850


0.848 0.580
-
0.815


0.859 0.630
-
0.776


0.869 0.678
-
0.735


0.879 0.724
-
0.690


0.889 0.
766
-
0.643


0.899 0.805
-
0.593


0.909 0.841
-
0.541


0.919 0.874
-
0.486


0.929 0.903
-
0.430


0.939 0.928
-
0.372


0.949 0.950
-
0.312



0.960 0.968
-
0.251


0.970 0.982
-
0.189


0.980 0.992
-
0.127


0.990 0.998
-
0.064


1.000 1.000 0.000



Mass of star (AU): 1.000000000

Semi
-
major axis (AU): 1.00000
0000

Eccentricity: 0.700000000


t(yr) x(AU) y(AU)

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

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

-----------


0.000 0.300 0.000


0.010 0.277 0.153


0.020 0.209 0.297


0.030 0.115 0.
414


0.040 0.013 0.501


0.051
-
0.088 0.565


0.061
-
0.185 0.612


0.071
-
0.277 0.647


0.081
-
0.364 0.673


0.091
-
0.446 0.691


0.101

-
0.524 0.703


0.111
-
0.598 0.710


0.121
-
0.668 0.714


0.131
-
0.734 0.714


0.141
-
0.797 0.711


0.152
-
0.857 0.705


0.162
-
0.915 0.698



0.172
-
0.969 0.688


0.182
-
1.021 0.676


0.192
-
1.070 0.663


0.202
-
1.117 0.649


0.212
-
1.162 0.633


0.222
-
1.204 0.617


0.232
-
1.2
45 0.599


0.242
-
1.283 0.580


0.253
-
1.319 0.561


0.263
-
1.354 0.540


0.273
-
1.386 0.519


0.283
-
1.417 0.498


0.293
-
1.446 0.476



0.303
-
1.473 0.453


0.313
-
1.499 0.430


0.323
-
1.523 0.406


0.333
-
1.545 0.382


0.343
-
1.566 0.357


0.354
-
1.585 0.332


0.364
-
1.603

0.307


0.374
-
1.619 0.282


0.384
-
1.633 0.256


0.394
-
1.646 0.231


0.404
-
1.658 0.204


0.414
-
1.668 0.178


0.424
-
1.677 0.152


0.43
4
-
1.684 0.126


0.444
-
1.690 0.099


0.455
-
1.695 0.072


0.465
-
1.698 0.046


0.475
-
1.700 0.019


0.485
-
1.700
-
0.008


0.495
-
1.699
-
0.034


0.505
-
1.696
-
0.061


0.515
-
1.692
-
0.087


0.525
-
1.687
-
0.114


0.535
-
1.681
-
0.140


0.545
-
1.672
-
0.166


0.556
-
1.663
-
0.192


0.566

-
1.652
-
0.218


0.576
-
1.640
-
0.244


0.586
-
1.626
-
0.269


0.596
-
1.611
-
0.295


0.606
-
1.594
-
0.319


0.616
-
1.576
-
0.344


0.626
-
1.557
-
0.368


0.636
-
1.536
-
0.392


0.646
-
1.513
-
0.416


0.657
-
1.489
-
0.439


0.667
-
1.464
-
0.461


0.677
-
1.436
-
0.483


0.687
-
1.408
-
0.505


0.697
-
1
.377
-
0.525


0.707
-
1.345
-
0.546


0.717
-
1.311
-
0.565


0.727
-
1.276
-
0.584


0.737
-
1.239
-
0.602


0.747
-
1.200
-
0.619


0.758
-
1.159
-
0.634



0.768
-
1.116
-
0.649


0.778
-
1.072
-
0.663


0.788
-
1.025
-
0.675


0.798
-
0.976
-
0.686


0.808
-
0.926
-
0.696


0.818
-
0.873
-
0.703


0.828
-
0.818

-
0.709


0.838
-
0.761
-
0.713


0.848
-
0.701
-
0.714


0.859
-
0.639
-
0.713


0.869
-
0.575
-
0.708


0.879
-
0.508
-
0.701


0.889
-
0.438
-
0.689


0.
899
-
0.366
-
0.673


0.909
-
0.292
-
0.652


0.919
-
0.216
-
0.625


0.929
-
0.137
-
0.590


0.939
-
0.058
-
0.548


0.949 0.022
-
0.494


0.960 0.100

-
0.429


0.970 0.174
-
0.348


0.980 0.238
-
0.248


0.990 0.284
-
0.128


1.000 0.300 0.013



Appendix B.5
-

Test
SimpleRestricted3BodyProblem

Mass Primary 1: 1047.355392478

Mass Prima
ry 2: 1.000000000

Mass Parameter: 0.000953875

Initial Position 3rd body (x):
-
0.509046125

Initial Position 3rd body (y): 0.883345912

Initial Velocity 3rd body (u): 0.0258975212

Initial Velocity 3rd body (v): 0.0149272418



i x

y u v

---

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

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

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

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

0.0
-
0.509046125 0.883345912 0.0258975212 0.0149272418

0.4
-
0.498648646 0.889247275 0.0260656072 0.0145894235

0.8
-
0.488186942 0.895012259 0.0262198772
0.0142444218

1.2
-
0.477666356 0.900637413 0.0263598894 0.0138887615

1.6
-
0.467092970 0.906117740 0.0264824338 0.0135186022

2.0
-
0.456474651 0.911446730 0.0265820581 0.0131306496

2.4
-
0.445821802 0.916616747 0.0266519727 0.0127229632

2.8
-
0.4351
47692 0.921619714 0.0266851922 0.0122955261

3.2
-
0.424468301 0.926447959 0.0266757319 0.0118504843

3.6
-
0.413801692 0.931095089 0.0266196653 0.0113920168

4.0
-
0.403167012 0.935556741 0.0265158689 0.0109258604

4.4
-
0.392583263 0.939831084 0.02
63663286 0.0104585705

4.8
-
0.382068047 0.943918980 0.0261759526 0.0099966414

5.2
-
0.371636487 0.947823786 0.0259519135 0.0095456328

5.6
-
0.361300488 0.951550817 0.0257026188 0.0091094470

6.0
-
0.351068470 0.955106569 0.0254364741 0.0086898751

6
.4
-
0.340945619 0.958497819 0.0251606345 0.0082864852

6.8
-
0.330934621 0.961730747 0.0248799468 0.0078968691

7.2
-
0.321036752 0.964810233 0.0245962579 0.0075172034

7.6
-
0.311253176 0.967739425 0.0243082031 0.0071430328

8.0
-
0.301586210 0.97051
9651 0.0240115153 0.0067701418

Appendix B.6
-

TestDifferentialEquation

X Euler Midpoint Predictor RungeKutta

----

----------

----------

----------

----------

0.00 1.00000000 1.00000000 1.00000000 1.00000000

0.10 1.00000000 0.99000000 0.9900000
0 0.99004983

0.20 0.98000000 0.96059700 0.96069600 0.96078944

0.30 0.94080000 0.91352775 0.91381404 0.91393117

0.40 0.88435200 0.85149921 0.85204021 0.85214377

0.50 0.81360384 0.77792968 0.77876475 0.77880078

0.60 0.73224346 0.69663603 0.69777321 0.6976763
9

0.70 0.64437424 0.61150711 0.61292399 0.61262661

0.80 0.55416185 0.52620187 0.52785014 0.52729293

0.90 0.46549595 0.44390389 0.44571666 0.44485904

1.00 0.38170668 0.36715291 0.36905339 0.36788107

1.10 0.30536534 0.29776101 0.29967136 0.29819974

1.20 0.23
818497 0.23680933 0.23865827 0.23693119

1.30 0.18102058 0.18471128 0.18643984 0.18452398

1.40 0.13395523 0.14132260 0.14288749 0.14086388

1.50 0.09644776 0.10607674 0.10745139 0.10540556

1.60 0.06751343 0.07812552 0.07929913 0.07731173

1.70 0.04590914 0.05
646913 0.05744429 0.05558359

1.80 0.03030003 0.04006485 0.04085438 0.03917137


Poly: x^2

Poly Symbolic Integral: 0.333333333333333x^3

True value of integral (assuming x axis not crossed): 333333.333333333

Integral using Simpson's method : 333333.333333333

Appendix B.7
-

TestPlot2d


Point (
-
1,
-
1); Scaled {X=78,Y=194}; UnScaled (
-
1,
-
0.991869918699187)

Point (
-
0.9,
-
0.9); Scaled {X=85,Y=187}; UnScaled (
-
0.897058823529412,
-
0.878048

780487805)

Point (
-
0.8,
-
0.8); Scaled {X=92,Y=181}; UnScaled (
-
0.794117647058
823,
-
0.780487

804878049)

Point (
-
0.7,
-
0.7); Scaled {X=99,Y=175}; UnScaled (
-
0.691176470588235,
-
0.682926

829268293)

Point (
-
0.6,
-
0.6); Scaled {X=106,Y=169}; UnScaled (
-
0.588235294117647,
-
0.58536

5853658537)

Point (
-
0.5,
-
0.5); Scaled {X=112,Y=163}; UnS
caled (
-
0.5,
-
0.487804878048781)

Point (
-
0.4,
-
0.4); Scaled {X=119,Y=157}; UnScaled (
-
0.397058823529412,
-
0.39024

3902439024)

Point (
-
0.3,
-
0.3); Scaled {X=126,Y=151}; UnScaled (
-
0.294117647058824,
-
0.29268

2926829268)

Point (
-
0.2,
-
0.2); Scaled {X=133,Y=1
45}; UnScaled (
-
0.191176470588235,
-
0.19512

1951219512)

Point (
-
0.1,
-
0.1); Scaled {X=140,Y=139}; UnScaled (
-
0.0882352941176471,
-
0.0975

609756097561)

Point (0, 0); Scaled {X=146,Y=133}; UnScaled (0, 0)

Point (0.1, 0.1); Scaled {X=152,Y=127}; UnScaled (0.0
882352941176471, 0.09756097

56097561)

Point (0.2, 0.2); Scaled {X=159,Y=121}; UnScaled (0.191176470588235, 0.195121951

219512)

Point (0.3, 0.3); Scaled {X=166,Y=115}; UnScaled (0.294117647058824, 0.292682926

829268)

Point (0.4, 0.4); Scaled {X=173,Y=109};
UnScaled (0.397058823529412, 0.390243902

439024)

Point (0.5, 0.5); Scaled {X=180,Y=103}; UnScaled (0.5, 0.487804878048781)

Point (0.6, 0.6); Scaled {X=186,Y=97}; UnScaled (0.588235294117647, 0.5853658536

58537)

Point (0.7, 0.7); Scaled {X=193,Y=91}; UnScal
ed (0.691176470588235, 0.6829268292

68293)

Point (0.8, 0.8); Scaled {X=200,Y=85}; UnScaled (0.794117647058823, 0.7804878048

78049)

Point (0.9, 0.9); Scaled {X=207,Y=79}; UnScaled (0.897058823529412, 0.8780487804

87805)

Point (1, 1); Scaled {X=214,Y=72}; Un
Scaled (1, 0.991869918699187)







Appendix B.8
-

TestPoint

PointNd: (1, 2, 3)

PointNd.asPoint2d: (1, 2)

PointNd.asPoint3d: (1, 2, 3)


Appendix B.9
-

TestPolynomial

d/dx(9x^4 + 3x^3 + 20x^2 + 15x + 1) =

36x^3 + 9x^2 + 40x + 15


Integrate:

9x^4 + 3x^3 +

20x^2 + 15x + C


d/dx(1) =

0


Integrate:

0 + C


d/dx(
-

1) =

0


Integrate:

0 + C


d/dx(x + 1) =

1


Integrate:

x + C


d/dx(
-

x
-

1) =

-

1


Integrate:

-

x + C


d/dx(
-

9x^4 + 3x^3
-

20x^2 + 15x
-

1) =

-

36x^3 + 9x^2
-

40x + 15


Integrate:

-

9x^4 + 3x^3
-

20x^
2 + 15x + C


d/dx(
-

9x^4 + 3x^3
-

20x^2
-

15x + 1) =

-

36x^3 + 9x^2
-

40x
-

15


Integrate:

-

9x^4 + 3x^3
-

20x^2
-

15x + C


d/dx(9x^4 + 3x^3
-

20x^2
-

15x
-

1) =

36x^3 + 9x^2
-

40x
-

15


Integrate:

9x^4 + 3x^3
-

20x^2
-

15x + C


d/dx(
-

9x^4
-

3x^3 + 20x^2
+ 15x + 1) =

-

36x^3
-

9x^2 + 40x + 15


Integrate:

-

9x^4
-

3x^3 + 20x^2 + 15x + C


Evaluation of p:
-
57


p+p:
-

18x^4
-

6x^3 + 40x^2 + 30x + 2

p
-
p: 0

def int of p from 1 to 2 3.11666666666667


p 9x^2 + 3x + 1

q 1

r 4x + 1

p*q 9x^2 + 3x + 1

p*r 36x^3 + 21x
^2 + 7x + 1

p*r/r Q = 9x^2 + 3x + 1 R = 0

p*r/r Q = 9x^2 + 3x + 1 R = 0

3*p 27x^2 + 9x + 3

p*3 27x^2 + 9x + 3

Appendix B.11
-

TestSystemOfFirstOrderDifferentialEquations

X Y Z

----

--------

--------

0.00 1.000000 0.000000

0.05 0.997502 0.049917

0
.10 0.990033 0.099335

0.15 0.977668 0.147760

0.20 0.960531 0.194709

0.25 0.938791 0.239713

0.30 0.912668 0.282321

0.35 0.882421 0.322109

0.40 0.848353 0.358678

0.45 0.810805 0.391663

0.50 0.770151 0.420735


X Y

----

--------

0.00 1.00000000

0.10 0.99004
983

0.20 0.96078944

0.30 0.91393117

0.40 0.85214377

0.50 0.77880078

0.60 0.69767639

0.70 0.61262661

0.80 0.52729293

0.90 0.44485904

1.00 0.36788107

1.10 0.29819974

1.20 0.23693119

1.30 0.18452398

1.40 0.14086388

1.50 0.10540556

1.60 0.07731173

1.70 0.05558
359

1.80 0.03917137


Appendix C
-

Sample Ou
tput of Demonstration Program
GAMFStellarSystemDemo