The GAMF Library - An 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 astronomy software is written in early “3rd generation”
procedural languages - particularly 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 programming
paradigms due to the initial learning curve associated. GAMF – the Generic 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-oriented
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 researcher 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 release of the
GAMF library. The problems, 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
mastering 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 similarities), 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 international information 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 two
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 objectoriented paradigm has allowed a new form of software reuse compared with older paradigms. Objectorientation can be used particularly well for physical models, which often map well to objects or classes.
According to the well written tutorial on object-oriented 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
generate 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 objectoriented programming the prospect of the reuse of individual 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 systems becomes a necessity if increasingly complex
code is to be tackled.
GAMF (Generic Astronomy Modeling Framework) is object-oriented in nature. Its astronomical classes
are written in the C# programming language to work on modern Microsoft Windows platforms. As the
name suggests it is not written to solve any particular astronomical problem. Rather, in the spirit of what
was intended when the object-oriented paradigm was first developed, the intent is generally reusable code.
In other words, instead 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-oriented techniques help to break down this complexity into more
manageable problems.
2. Object-orientation allows an improvement in reuse and thus facilitates the combination of several
astronomical models. Projects too large to be tackled by individual astrophysicists 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 evolution 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 predecessors 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 release 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 awareness 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 written on software reuse, and object-orientation. This section 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 variety of computer science texts including Meyer, B. 1988 and Henderson-Sellers
B. 1992.)
3.1
Features of Object-Oriented Programming Languages
The procedural programming paradigm breaks up the task required of a computer into procedures,
functions or subroutines – essentially code fragments which can be used repeatedly in a software 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
an individual or team of programmers.
Object-oriented languages go a step 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 representing a specific
subset of the system in which the programmer is interested, it becomes possible to further manage the
complexity of a task. Each object is responsible for its own behaviour and therefore need only perform its
own role in a given process. 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 Encapsulation
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 programmer. 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. If 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 (objects), to inherit part of their
behaviour from that of a parent class. This allows a more complex child to be 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 defining 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. Once 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-oriented 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.
The 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 code 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 skilled 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 conceptually
represent the abstract models 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 commons 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 cause of software bugs can be pin-pointed more efficiently. All other
things being equal the end user should have a more stable, more easily manipulated program 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 and 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 code. The programmer must also deal with the necessary
syntactic complexity that an object-oriented programming language requires in order to provide objectoriented features.
Object-oriented languages also execute code more slowly and require more resources compared to their
procedural counterparts. For 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 place. 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 serve 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, viewing 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. Beginning 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 grown quickly in complexity, and
object methodologies have become a pre-requisite for building successful systems. This realization is
taking longer to percolate through the scientific community.
While other astronomy libraries exist, few are publicly available. Fewer still are written in object-oriented
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
runs only under a UNIX style operating system. An 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, two good examples 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). This 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 development of common components such as a common menuing
system, and simulated telescopes/sky views. The source code is not publicly available.
See references for web pages associated with the software. Unfortunately, such examples of reuse are still
the exception. 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-oriented features, each with their advantages
and disadvantages. However few are true first class object-oriented languages. C++ (perhaps the most
widely used in the 1980s and early 1990s) for example allows the programmer to combine procedural and
object-oriented 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 true 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 between 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 future is by no means guaranteed.
C# is a proprietary language developed by Microsoft to compete with Java. In many ways it resembles
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 other 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
software in a Microsoft Windows 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
heavily tied to the Windows 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 efficient 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 and 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 work on any platform that
fully supports a Microsoft .NET environment i.e. all 32-bit and 64-bit windows operating systems since
Windows 98 Second Edition. 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 development, 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 software 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 are 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 wishing 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 of 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 Wein’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 Blackbody 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 ways in which these basic models can be extended in future to more
completely cover the astronomical basics, at least at an educational level. More of these basic equations
can be modelled. Modelling can be done in a more complete manner, or with more depth. 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 particular object (eg a spectra). To accomplish this, the models may need 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
which they are based is procedural. In this code, where 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 set 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, demonstrate 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 research
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 restricted 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 solution 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 differential 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 none of the methods for solving differential equations
included in the first version of the library are adaptive). The present form of the solving methods is
cumbersome since the equations must be translated into a form that is easily modelled by a class. However
a strong case can be presented that the procedural code is even more cumbersome. 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 best 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 appendix G. The orbit conforms to the shape of an eclipse and approximate
numerical 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 orbiting 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
classical formulation of the general three body problem is considered analytically intractable due to the
mathematical complications associated – nine second order differential 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 orbit of the third body around the centre of mass of the primaries.
The restricted three body problem is successful in approximately modelling a number of orbital systems
which are of practical interest:
1.
2.
3.
4.
5.
The Earth, Sun, Moon system
The Earth, Moon and an artificial satellite
The Sun, Jupiter and an asteroid
A triple stellar system in which two more massive stars orbited by a third, smaller companion
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
mechanics. 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 methods described include those of Olbers, Laplace, Gauss. The
solution of two-, 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. no time dependent processes are modelled. Modern research
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 pressure and gravitational force. The class SimplePolytrope represents a polytrope as
described in chapter four of Hellings P. 1994. This 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
original 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 Hellings 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
Role 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 again. 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
too 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 objectoriented paradigm has been made in building GAMF. Where possible, all 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 particularly true since in the case of a complex astronomical model, the purpose of the code 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. The library is written for
astronomers not application developers without a knowledge of or interest in astronomy, physics, and
mathematics on which it is based.
Note that where interaction with existing .NET frameworks is required, different access levels are in fact
used in GAMF. There are two reasons for this:
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 written 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 not unprecedented will prove controversial to many experienced programmers. 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 particularly 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 for the representation of points in two-, three- and Ndimensional 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
polynomials 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 rule 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 person wishing to use the library. However it is much simpler than a
library that could parse a more 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 an entire separate project. 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
purpose for having been written. They are discussed in detail in the section GAMF Astronomical Models.
In order to build the main GAMF demonstration 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,
future 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 belonging to this category is a printable display form class.
6.3
Testing and Documentation
Testing consists of a simple 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 collected into their own project (see Appendix 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 the 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 was 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 headers 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 documentation 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 library 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 (FORTRAN 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 boundary 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 are themselves
extensible and reusable, as is the intent of the library. While none of the models are research grade, each is
usable in an educational context, and it would be possible to build research grade models into future
editions of the library.
8
Conclusion
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 level 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 possible – 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 require 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 easy task due to similarities 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 trademarks of Microsoft Corporation. UNIX is a registered trademark of The 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
information 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 students 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
crystallizing 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, mistakes 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=orderid
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 Astrophysics
Addison-Wesley Publishing Company , Inc.
ISBN 0-201-54730-9
CLEA (Contemporary Learning Experiences in Astronomy – Software)
http://www.gettysburg.edu/academics/physics/clea/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 5th 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 Computing 2nd 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.TXT 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
The 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 - TestWeinsLaw
Wein's Law Calculator: 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: 500E-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] Calculate 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.0133
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
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
0.60000
0.65000
0.70000
0.75000
0.80000
0.85000
0.90000
0.95000
1.00000
1.05000
1.10000
1.15000
1.20000
1.25000
1.30000
1.35000
1.40000
1.45000
1.50000
1.55000
1.60000
1.65000
1.70000
1.75000
1.80000
1.85000
1.90000
1.95000
2.00000
2.05000
2.10000
2.15000
2.20000
2.25000
2.30000
2.35000
2.40000
2.45000
2.50000
2.55000
2.60000
2.65000
2.70000
2.75000
2.80000
2.85000
2.90000
2.95000
3.00000
3.05000
3.10000
0.94157
0.93174
0.92123
0.91005
0.89824
0.88582
0.87280
0.85923
0.84512
0.83051
0.81541
0.79987
0.78391
0.76757
0.75086
0.73382
0.71649
0.69889
0.68105
0.66300
0.64477
0.62639
0.60789
0.58930
0.57063
0.55194
0.53322
0.51452
0.49585
0.47725
0.45872
0.44030
0.42200
0.40385
0.38585
0.36804
0.35042
0.33302
0.31583
0.29889
0.28220
0.26577
0.24962
0.23375
0.21816
0.20287
0.18789
0.17321
0.15885
0.14480
0.13107
-0.18951
-0.20340
-0.21686
-0.22985
-0.24237
-0.25438
-0.26588
-0.27683
-0.28723
-0.29707
-0.30633
-0.31500
-0.32307
-0.33055
-0.33743
-0.34370
-0.34936
-0.35443
-0.35890
-0.36278
-0.36607
-0.36879
-0.37094
-0.37254
-0.37360
-0.37413
-0.37415
-0.37368
-0.37273
-0.37132
-0.36947
-0.36720
-0.36453
-0.36148
-0.35806
-0.35431
-0.35023
-0.34586
-0.34122
-0.33632
-0.33118
-0.32583
-0.32029
-0.31458
-0.30872
-0.30272
-0.29661
-0.29041
-0.28413
-0.27780
-0.27143
-0.0654
-0.0768
-0.0891
-0.1023
-0.1165
-0.1316
-0.1477
-0.1647
-0.1827
-0.2016
-0.2216
-0.2424
-0.2643
-0.2872
-0.3111
-0.3360
-0.3620
-0.3890
-0.4171
-0.4462
-0.4765
-0.5079
-0.5404
-0.5742
-0.6091
-0.6453
-0.6827
-0.7215
-0.7616
-0.8031
-0.8461
-0.8906
-0.9367
-0.9845
-1.0339
-1.0853
-1.1385
-1.1938
-1.2514
-1.3112
-1.3736
-1.4387
-1.5068
-1.5781
-1.6531
-1.7319
-1.8152
-1.9036
-1.9975
-2.0981
-2.2063
-0.0392
-0.0461
-0.0534
-0.0614
-0.0699
-0.0790
-0.0886
-0.0988
-0.1096
-0.1210
-0.1329
-0.1455
-0.1586
-0.1723
-0.1867
-0.2016
-0.2172
-0.2334
-0.2502
-0.2677
-0.2859
-0.3047
-0.3243
-0.3445
-0.3655
-0.3872
-0.4096
-0.4329
-0.4570
-0.4819
-0.5077
-0.5344
-0.5620
-0.5907
-0.6204
-0.6512
-0.6831
-0.7163
-0.7508
-0.7867
-0.8242
-0.8632
-0.9041
-0.9469
-0.9918
-1.0392
-1.0891
-1.1421
-1.1985
-1.2589
-1.3238
0.0682
0.0859
0.1063
0.1293
0.1551
0.1838
0.2154
0.2498
0.2872
0.3275
0.3707
0.4166
0.4652
0.5165
0.5703
0.6264
0.6848
0.7452
0.8075
0.8716
0.9371
1.0040
1.0720
1.1409
1.2105
1.2805
1.3507
1.4209
1.4909
1.5605
1.6294
1.6974
1.7643
1.8300
1.8941
1.9567
2.0174
2.0761
2.1326
2.1869
2.2388
2.2882
2.3349
2.3790
2.4203
2.4588
2.4945
2.5273
2.5572
2.5842
2.6084
63
64
65
66
67
68
69
70
71
72
73
3.15000
3.20000
3.25000
3.30000
3.35000
3.40000
3.45000
3.50000
3.55000
3.60000
3.65000
0.11766
0.10456
0.09179
0.07934
0.06720
0.05538
0.04387
0.03266
0.02176
0.01115
0.00083
-0.26504
-0.25864
-0.25225
-0.24590
-0.23959
-0.23334
-0.22717
-0.22109
-0.21513
-0.20930
-0.20363
Central Pressure Pc (dyne/cm^2):
Average Density
(g/cm^3)
:
Central Density dc (g/cm^3)
:
Mass Parameter (L)
:
Distance Unit (Solar Radii)
:
-2.3235
-2.4515
-2.5930
-2.7513
-2.9315
-3.1416
-3.3946
-3.7149
-4.1559
-4.8819
-7.7045
-1.3941
-1.4709
-1.5558
-1.6508
-1.7589
-1.8850
-2.0368
-2.2289
-2.4936
-2.9291
-4.6227
4.329641E+14
0.105185
0.630583
1.356410
0.821003
Appendix B.4 - Test2BodyProblem
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.985
0.232
0.111
0.994
0.242
0.048
0.999
2.6298
2.6485
2.6644
2.6778
2.6888
2.6974
2.7039
2.7084
2.7112
2.7125
2.7128
0.253
0.263
0.273
0.283
0.293
0.303
0.313
0.323
0.333
0.343
0.354
0.364
0.374
0.384
0.394
0.404
0.414
0.424
0.434
0.444
0.455
0.465
0.475
0.485
0.495
0.505
0.515
0.525
0.535
0.545
0.556
0.566
0.576
0.586
0.596
0.606
0.616
0.626
0.636
0.646
0.657
0.667
0.677
0.687
0.697
0.707
0.717
0.727
0.737
0.747
0.758
-0.016
-0.079
-0.142
-0.205
-0.266
-0.327
-0.386
-0.444
-0.500
-0.554
-0.606
-0.655
-0.701
-0.745
-0.786
-0.824
-0.858
-0.889
-0.916
-0.940
-0.959
-0.975
-0.987
-0.995
-0.999
-0.999
-0.995
-0.987
-0.975
-0.960
-0.940
-0.916
-0.889
-0.858
-0.824
-0.786
-0.745
-0.702
-0.655
-0.606
-0.554
-0.500
-0.444
-0.386
-0.327
-0.267
-0.205
-0.142
-0.079
-0.016
0.047
1.000
0.997
0.990
0.979
0.964
0.945
0.922
0.896
0.866
0.833
0.796
0.756
0.713
0.667
0.618
0.567
0.514
0.458
0.401
0.342
0.282
0.220
0.158
0.095
0.032
-0.032
-0.095
-0.158
-0.220
-0.282
-0.342
-0.401
-0.458
-0.514
-0.567
-0.618
-0.667
-0.713
-0.756
-0.796
-0.833
-0.866
-0.896
-0.922
-0.945
-0.964
-0.979
-0.990
-0.997
-1.000
-0.999
0.768
0.778
0.788
0.798
0.808
0.818
0.828
0.838
0.848
0.859
0.869
0.879
0.889
0.899
0.909
0.919
0.929
0.939
0.949
0.960
0.970
0.980
0.990
1.000
0.111
0.174
0.236
0.297
0.357
0.415
0.472
0.527
0.580
0.630
0.678
0.724
0.766
0.805
0.841
0.874
0.903
0.928
0.950
0.968
0.982
0.992
0.998
1.000
-0.994
-0.985
-0.972
-0.955
-0.934
-0.910
-0.882
-0.850
-0.815
-0.776
-0.735
-0.690
-0.643
-0.593
-0.541
-0.486
-0.430
-0.372
-0.312
-0.251
-0.189
-0.127
-0.064
0.000
Mass of star (AU):
1.000000000
Semi-major axis (AU):
1.000000000
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
0.202
0.212
0.222
0.232
0.242
0.253
0.263
0.273
0.283
0.293
0.303
0.313
0.323
0.333
0.343
0.354
0.364
0.374
0.384
0.394
0.404
0.414
0.424
0.434
0.444
0.455
0.465
0.475
0.485
0.495
0.505
0.515
0.525
0.535
0.545
0.556
0.566
0.576
0.586
0.596
0.606
0.616
0.626
0.636
0.646
0.657
0.667
0.677
0.687
0.697
-1.070
-1.117
-1.162
-1.204
-1.245
-1.283
-1.319
-1.354
-1.386
-1.417
-1.446
-1.473
-1.499
-1.523
-1.545
-1.566
-1.585
-1.603
-1.619
-1.633
-1.646
-1.658
-1.668
-1.677
-1.684
-1.690
-1.695
-1.698
-1.700
-1.700
-1.699
-1.696
-1.692
-1.687
-1.681
-1.672
-1.663
-1.652
-1.640
-1.626
-1.611
-1.594
-1.576
-1.557
-1.536
-1.513
-1.489
-1.464
-1.436
-1.408
-1.377
0.663
0.649
0.633
0.617
0.599
0.580
0.561
0.540
0.519
0.498
0.476
0.453
0.430
0.406
0.382
0.357
0.332
0.307
0.282
0.256
0.231
0.204
0.178
0.152
0.126
0.099
0.072
0.046
0.019
-0.008
-0.034
-0.061
-0.087
-0.114
-0.140
-0.166
-0.192
-0.218
-0.244
-0.269
-0.295
-0.319
-0.344
-0.368
-0.392
-0.416
-0.439
-0.461
-0.483
-0.505
-0.525
0.707
0.717
0.727
0.737
0.747
0.758
0.768
0.778
0.788
0.798
0.808
0.818
0.828
0.838
0.848
0.859
0.869
0.879
0.889
0.899
0.909
0.919
0.929
0.939
0.949
0.960
0.970
0.980
0.990
1.000
-1.345
-1.311
-1.276
-1.239
-1.200
-1.159
-1.116
-1.072
-1.025
-0.976
-0.926
-0.873
-0.818
-0.761
-0.701
-0.639
-0.575
-0.508
-0.438
-0.366
-0.292
-0.216
-0.137
-0.058
0.022
0.100
0.174
0.238
0.284
0.300
-0.546
-0.565
-0.584
-0.602
-0.619
-0.634
-0.649
-0.663
-0.675
-0.686
-0.696
-0.703
-0.709
-0.713
-0.714
-0.713
-0.708
-0.701
-0.689
-0.673
-0.652
-0.625
-0.590
-0.548
-0.494
-0.429
-0.348
-0.248
-0.128
0.013
Appendix B.5 - TestSimpleRestricted3BodyProblem
Mass Primary 1: 1047.355392478
Mass Primary 2:
1.000000000
Mass Parameter:
0.000953875
Initial Position 3rd body (x):
Initial Position 3rd body (y):
Initial Velocity 3rd body (u):
Initial Velocity 3rd body (v):
i
--0.0
0.4
0.8
1.2
1.6
2.0
2.4
2.8
3.2
3.6
4.0
4.4
-0.509046125
0.883345912
0.0258975212
0.0149272418
x
y
u
v
------------ ------------ ------------- -------------0.509046125 0.883345912 0.0258975212 0.0149272418
-0.498648646 0.889247275 0.0260656072 0.0145894235
-0.488186942 0.895012259 0.0262198772 0.0142444218
-0.477666356 0.900637413 0.0263598894 0.0138887615
-0.467092970 0.906117740 0.0264824338 0.0135186022
-0.456474651 0.911446730 0.0265820581 0.0131306496
-0.445821802 0.916616747 0.0266519727 0.0127229632
-0.435147692 0.921619714 0.0266851922 0.0122955261
-0.424468301 0.926447959 0.0266757319 0.0118504843
-0.413801692 0.931095089 0.0266196653 0.0113920168
-0.403167012 0.935556741 0.0265158689 0.0109258604
-0.392583263 0.939831084 0.0263663286 0.0104585705
4.8
5.2
5.6
6.0
6.4
6.8
7.2
7.6
8.0
-0.382068047
-0.371636487
-0.361300488
-0.351068470
-0.340945619
-0.330934621
-0.321036752
-0.311253176
-0.301586210
0.943918980
0.947823786
0.951550817
0.955106569
0.958497819
0.961730747
0.964810233
0.967739425
0.970519651
0.0261759526
0.0259519135
0.0257026188
0.0254364741
0.0251606345
0.0248799468
0.0245962579
0.0243082031
0.0240115153
0.0099966414
0.0095456328
0.0091094470
0.0086898751
0.0082864852
0.0078968691
0.0075172034
0.0071430328
0.0067701418
Appendix B.6 - TestDifferentialEquation
X
---0.00
0.10
0.20
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00
1.10
1.20
1.30
1.40
1.50
1.60
1.70
1.80
Euler
---------1.00000000
1.00000000
0.98000000
0.94080000
0.88435200
0.81360384
0.73224346
0.64437424
0.55416185
0.46549595
0.38170668
0.30536534
0.23818497
0.18102058
0.13395523
0.09644776
0.06751343
0.04590914
0.03030003
Midpoint
---------1.00000000
0.99000000
0.96059700
0.91352775
0.85149921
0.77792968
0.69663603
0.61150711
0.52620187
0.44390389
0.36715291
0.29776101
0.23680933
0.18471128
0.14132260
0.10607674
0.07812552
0.05646913
0.04006485
Predictor
---------1.00000000
0.99000000
0.96069600
0.91381404
0.85204021
0.77876475
0.69777321
0.61292399
0.52785014
0.44571666
0.36905339
0.29967136
0.23865827
0.18643984
0.14288749
0.10745139
0.07929913
0.05744429
0.04085438
RungeKutta
---------1.00000000
0.99004983
0.96078944
0.91393117
0.85214377
0.77880078
0.69767639
0.61262661
0.52729293
0.44485904
0.36788107
0.29819974
0.23693119
0.18452398
0.14086388
0.10540556
0.07731173
0.05558359
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.794117647058823, -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}; UnScaled (-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=145}; 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.0882352941176471, 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}; UnScaled (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}; UnScaled (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
---0.00
0.05
0.10
0.15
0.20
0.25
0.30
0.35
0.40
0.45
0.50
Y
-------1.000000
0.997502
0.990033
0.977668
0.960531
0.938791
0.912668
0.882421
0.848353
0.810805
0.770151
Z
-------0.000000
0.049917
0.099335
0.147760
0.194709
0.239713
0.282321
0.322109
0.358678
0.391663
0.420735
X
---0.00
0.10
0.20
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00
1.10
1.20
1.30
1.40
1.50
1.60
1.70
1.80
Y
-------1.00000000
0.99004983
0.96078944
0.91393117
0.85214377
0.77880078
0.69767639
0.61262661
0.52729293
0.44485904
0.36788107
0.29819974
0.23693119
0.18452398
0.14086388
0.10540556
0.07731173
0.05558359
0.03917137
Appendix C - Sample Output of Demonstration Program
GAMFStellarSystemDemo