Our goal is build a laboratory to study the interactions between stars. Since stars don't fit in traditional laboratories, we have no choice but to use virtual stars in virtual labs. The computer provides us with the right virtual environment, and it is our task to write the software that will correctly simulate the behavior of the virtual stars and their interactions. Once that software is in place, or at least enough of it to start playing, the user can provide a starting situation, after which our software will evolve the system, perhaps for a few billion years.

In this book we will focus in detail on the whole process of developing the software needed. We will aim at realistic detail, showing the way of thinking that underlies the construction of a complex and ever-growing software environment. We will require a bit of patience, since it will take a while to have a full package in hand for modeling, say, the long-term behavior of a star cluster, and we are presenting in this book only the first few steps. This drawback, we feel, is more than offset by the advantages of our approach:

• you will be fully empowered to customize any aspect of the software environment or any larger or smaller part of it;

• you will be able to use the package with complete understanding and appreciation of what are and are not reasonable ways to apply the tools;

• you will learn to embark on completely different large-scale software projects, be they in (astro)physics or other areas of science;

• and in addition, we hope that reading these books will be as much fun for the reader as it was for us to write them.

2.2. Our Setting

We want to convey some of the atmosphere in which large software environments are grown, in a dynamic and evolutionary way, often starting from very small beginnings -- and always surprising the original authors when they see in what unexpected ways others can and will modify their products in whole new directions. Most of our narrative will follow this process step by step, but occasionally we will turn away from the process to the players: the developers writing the software. We have chosen one representative of each of the three target groups mentioned in our preface, from natural science, business and computer science.

The setting is an undergraduate lounge, where three friends occasionally hang out after dinner, and sometimes tell each other about the projects they are working on. Tonight, Erica talks with great animation to her friends Dan and Carol. Erica is an astrophysics major, Dan is currently studying biology but preparing to go to business school, and Carol majors in computer science.

Erica: Guess what! Today I was asked to choose a student project, for me to work on for half a year. Many of the choices offered seemed to be interesting, but for me the most exciting opportunity was to work on the overhaul of a laboratory for interactions between stars.

Dan: What are the interactions that are so interesting?

Erica: Imagine this, the current software package allows you to create a star cluster and to let it evolve for billions of years, and then you can fly through the whole four-dimensional history in space and time to watch all the collisions and close encounters between normal stars and black holes and white dwarfs and you name it!

Carol: If that package already exists, what then is so exciting about an overhaul?

Erica: Yes, the package exists, but every large software package tends to grow and to become overweight. As you both know, this is true in business-driven software projects, but it is even more true in science settings, where the value of clean software engineering is underrated even more than in profit-oriented areas. As a result, by far the most reasonable and efficient way to extend older packages is first to do a thorough overhaul.

Dan: I see. You mean that rewriting a package is worth the time, presumably because you have already figured out the physics and you have similarly built up extensive experience with hooking everything together in various ways in software.

Erica: Exactly. Rewriting a package takes far less time than writing it in the first place -- if we want to keep the same functionality. In practice, it may take longer than we think, since we will for sure find new extensions and more powerful ways to include more physics. As long as we don't get carried away, and keep our science goals in sight, this extra time is well spent and will lead to greater productivity.

Carol: I wonder, though, whether a complete overhaul is desirable. I have just learned about a notion called refactoring. The idea is to continuously refine and clean up code while you go along.

Erica: Yes, that would be better. In fact, I already had a brief chat with my supervisor, a professor specializing in stellar dynamics, and he mentioned just that. He said that this was the last really major overhaul he hoped to do for his software environment. The main reason for the planned overhaul is to make it flexible enough that the system from now on can grow more organically.

Dan: The overhaul that will be the end of all overhauls!

Carol: Well, maybe. I've heard a lot of hype about programming, in the few years that I have been exposed to it. But the basic idea sounds good. And even if you will have to overhaul in the future, a cleaner and more modular code will surely be easier to understand and disentangle and hence to overhaul.

Dan: May I ask a critical question? You have half a year to get your feet wet, doing a real piece of scientific research. Would it really be prudent to spend that time overhauling someone else's code?

Erica: I asked that question, too. My supervisor told me that a thorough-going attempt to improve a large software environment in a fundamental way from the bottom up is guaranteed to lead to new science. Instead of overhauling, a better term might be brewing. You will reap the benefits of all the years of experience that have gone into building the software, from working with the science to the figuring out of the architecture of the software environment. Those who wrote the original code have become too engrossed in teaching and administration. But they will have time to share their experience, and they will gladly do so when they see someone seriously working on improvements.

Carol: In other words, during this coming half year you might find yourself engaging in actual research projects, as a form of spin-off of the overhauling, or brewing as you just called it?

Erica: Exactly.

Dan: You know what? Perhaps this is a silly thing to suggest, but I suddenly got an idea. It seems that Erica today has started what amounts to an infinite task. She will have her hands full at it, even if she could clone herself into several people working simultaneously, and she is not expected to reach anywhere near completion in half a year. At the same time, she is expected to start absolutely from start. If she wouldn't do so, it wouldn't be a complete overhaul. Here is my proposal: how about all three of us pitching in, a couple times a week, after dinner, using the time we tend to spend here anyway?

Carol: To keep Erica honest?

Dan: Exactly! Of course, she may well get way ahead of us into all kinds of arcane astrophysics applications, but even so, if we plod behind her, asking her questions about each and every decision she has made from the start, we will probably keep her more honest than any astrophysicist could -- simply because we know less about astrophysics than any astrophysicist! And besides, for me too it would be a form of fun and profit. I intend to focus on the software industry when I go to business school, and I might as well get some real sense of what is brewing in the kitchen, when people write non-trivial software systems.

Carol: Hmm, you have a point. Obviously, something similar holds for me too, in that I can hone my freshly learned theoretical knowledge on realistic astrophysics problems. What do you think, Erica, are we rudely intruding upon your new project?

Erica: No, on the contrary! As long as I keep my actual project separated, as Dan stressed, I am more than happy to discuss the basics with you both during after-dinner sessions, as long as you have the stamina and interest to play with orbital dynamics of stars and star systems. And I'm sure we will all three learn from the experience: I would be very surprised if you didn't inject new ideas I hadn't thought about, or notice old ideas of mine that can be improved.

Dan: We have a deal! Let's get started right away, and get back here tomorrow, same time, same place.

Carol: Okay, but let's say almost the same place: next door is the computer center, where we will be able to find a big enough screen so that the three of us can gather around it, to start writing our first star-moving program.

Erica: An N-body code, that is what it is called. I'm game too. See you both tomorrow!

The next day, our three friends have gathered again, ready to go.

Erica: Hi, you're all back, so I guess you were really serious. Well, let's write our first code for solving the gravitational N-body problem.

Dan: I understand that we are dealing with something like gravitational attractions between objects, but why is that a problem and not, say, a system?

Carol: And why are you talking about N bodies, and not p bodies or anything else?

Dan: And why bodies and not just objects?

Erica: Traditionally, in mathematics and mathematical physics, when we pose a question, we call it a problem, as in a home work problem. And stars and planets just happen to be called celestial bodies. Specifically, the gravitational 2-body problem is defined as the question: given the initial positions and velocities of two stars, together with their masses, describe their orbits.

Dan: What if the stars collide?

Erica: For simplicity, we treat the stars as if they are mass points, without any size. In this case they will not collide, unless they happen to hit each other head-on. Of course, we can set two point masses up such that they will hit each other, and we will have to take such possibilities into account, at some point. However, when the stars in a star cluster are born from a gas cloud, their motions will not be fine tuned to lead to exactly head-on collisions with mathematical precision. Therefore, the chance of a collision between point particles is negligible.

Carol: In mathematical terms: the set of initial conditions for collisions to occur has measure zero in the space of all possible initial conditions. Don't worry, that's just a formal way of saying the same thing. But I have a serious question: real stars are not points, so why can we treat them as such?

Erica: The goal of building a laboratory for star cluster evolution is to introduce real stars with finite sizes, nuclear reactions, loss of radiation and mass, and all that good stuff. But we have to start somewhere, and a convenient starting place is to treat stars as point masses, as a first approximation.

This brings me to Carol's question: why do astrophysicists talk about N-body simulations? This is simply a historical convention. I would prefer the term many-body simulations, but somehow somewhere someone stuck in the variable N as a place-holder for how many bodies where involved, and we seem to be stuck with that notation.

Previous

ToC

Up

Next