this content has been downloaded from iopscience. please scroll …€¦ · 6.1 in a nutshell 6-1...

This content has been downloaded from IOPscience. Please scroll down to see the full text.

Download details:

IP Address: 54.39.106.173

This content was downloaded on 23/07/2020 at 22:24

Please note that terms and conditions apply.

http://iopscience.iop.org/page/terms

Astrophysical RecipesThe art of AMUSE

AAS Editor in Chief

Ethan Vishniac, John Hopkins University, Maryland, US

About the program:AAS-IOP Astronomy ebooks is the official book program of the AmericanAstronomical Society (AAS), and aims to share in depth the most fascinating areasof astronomy, astrophysics, solar physics and planetary science. The programincludes publications in the following topics:

Books in the program range in level from short introductory texts on fast-movingareas, graduate and upper-level undergraduate textbooks, research monographs andpractical handbooks.

For a complete list of published and forthcoming titles, please visit iopscience.org/books/aas.

About the American Astronomical SocietyThe American Astronomical Society (aas.org), established 1899, is the majororganization of professional astronomers in North America. The membership(∼7,000) also includes physicists, mathematicians, geologists, engineers and otherswhose research interests lie within the broad spectrum of subjects now comprisingthe contemporary astronomical sciences. The mission of the Society is to enhanceand share humanity’s scientific understanding of the universe.

http://iopscience.org/books/aas

http://iopscience.org/books/aas

https://aas.org

Astrophysical RecipesThe art of AMUSE

Simon Portegies ZwartSterrewacht Leiden, Leiden University, 2333 CA, Leiden, The Netherlands

Steve McMillanDepartment of Physics, Drexel University, Philadelphia, PA 19104, USA

IOP Publishing, Bristol, UK

ª IOP Publishing Ltd 2018

All rights reserved. No part of this publication may be reproduced, stored in a retrieval systemor transmitted in any form or by any means, electronic, mechanical, photocopying, recordingor otherwise, without the prior permission of the publisher, or as expressly permitted by law orunder terms agreed with the appropriate rights organization. Multiple copying is permitted inaccordance with the terms of licences issued by the Copyright Licensing Agency, the CopyrightClearance Centre and other reproduction rights organizations.

Permission to make use of IOP Publishing content other than as set out above may be soughtat [email protected].

Simon Portegies Zwart and Steve McMillan have asserted their right to be identified as the authorsof this work in accordance with sections 77 and 78 of the Copyright, Designs and Patents Act1988.

ISBN 978-0-7503-1320-9 (ebook)ISBN 978-0-7503-1321-6 (print)ISBN 978-0-7503-1322-3 (mobi)

DOI 10.1088/978-0-7503-1320-9

Version: 20181201

AAS–IOP AstronomyISSN 2514-3433 (online)ISSN 2515-141X (print)

British Library Cataloguing-in-Publication Data: A catalogue record for this book is availablefrom the British Library.

Published by IOP Publishing, wholly owned by The Institute of Physics, London

IOP Publishing, Temple Circus, Temple Way, Bristol, BS1 6HG, UK

US Office: IOP Publishing, Inc., 190 North Independence Mall West, Suite 601, Philadelphia,PA 19106, USA

To Merei and Stacy

Contents

Preface xiii

Acknowledgements xvii

Author biographies xix

1 What is Computational Astrophysics? 1-1

1.1 Computational Astrophysics 1-1

1.1.1 Origin of This Book 1-1

1.1.2 Hands-on is Hands-on 1-2

1.1.3 What about the Math? 1-2

1.1.4 Objective of This Book 1-3

1.1.5 What is Missing from This Book 1-3

1.1.6 Outline of the Book 1-4

1.2 A Brief History of Simulations in Astrophysics 1-5

1.2.1 The First Simulation Experiments 1-6

1.3 Software Used in This Book 1-7

1.3.1 Motivation for a Homogeneous Software Environment 1-7

1.3.2 Choice of Programming Languages 1-9

1.3.3 Design of AMUSE 1-10

1.3.4 Terminology 1-12

1.3.5 Installing AMUSE 1-13

1.3.6 Running AMUSE 1-15

1.4 Initial Conditions 1-16

1.4.1 Particles and Particle Sets 1-17

1.4.2 The Solar System 1-19

1.4.3 The Plummer Sphere 1-21

1.4.4 The Initial Mass Function 1-24

1.4.5 Stellar Evolution 1-25

1.4.6 Hydrodynamical Models 1-28

References 1-30

2 Gravitational Dynamics 2-1

2.1 In a Nutshell 2-1

2.1.1 Equations of Motion for a Self-gravitating System 2-1

2.1.2 Gravitational Time Scales 2-2

2.1.3 Star Cluster Dynamics 2-7

2.1.4 Physics of the Integrator 2-10

vii

2.2 N-body Integration Strategies 2-12

2.2.1 Global Structure of an N-body Code 2-13

2.2.2 Types of N-body Code 2-14

2.2.3 Discretization Strategies in N-body Simulations 2-15

2.3 Gravity Solvers in AMUSE 2-19

2.3.1 Generating Initial Conditions 2-21

2.3.2 Specifying and Initializing the Gravity Solver 2-23

2.3.3 Setting and Getting Parameters in a Community Code 2-24

2.3.4 Feeding Particles to the N-body Code 2-26

2.3.5 Evolving the Model to the Desired Time 2-27

2.3.6 Retrieving Data from the N-body Code 2-29

2.3.7 Storing and Recovering Data 2-29

2.3.8 Using Other Units 2-31

2.3.9 Interrupting the N-body Integrator 2-32

2.4 Examples 2-34

2.4.1 Integrating the Orbits of Venus and Earth 2-34

2.4.2 Small Cluster with Stellar Collisions 2-39

2.4.3 Secular Multiples 2-41

2.4.4 Merging Galaxies 2-44

2.5 Validation 2-47

2.5.1 Error Propagation and Validation 2-47

2.6 Assignments 2-48

2.6.1 Orbital Trajectories 2-48

2.6.2 Vostok 2-49

2.6.3 Dynamical Binary Formation 2-50

2.6.4 L1 Lagrangian Point 2-50

2.6.5 Virial Equilibrium 2-52

References 2-53

3 Stellar Structure and Evolution 3-1


3.1.1 Stellar Time Scales 3-4

3.1.2 Physics of the Interior 3-7

3.1.3 Final Stages of Stellar Evolution 3-11

3.2 Simulating Stellar Evolution 3-13

3.2.1 Stellar Evolution Modules in AMUSE 3-15

3.2.2 Improving the Stellar Evolution Solver 3-16

Astrophysical Recipes

viii

3.2.3 Evolving an Inhomogeneous Stellar Population 3-18

3.2.4 Multiprocessing Codes 3-19

3.2.5 Enforcing Stellar Mass Loss/Gain 3-20

3.2.6 Accessing Stellar Interiors 3-22

3.2.7 Modeling Stellar Mergers 3-23

3.2.8 Interrupting Stellar Evolution 3-24

3.2.9 Binary Evolution 3-25

3.2.10Reading and Writing Binary Evolution Files 3-27

3.3 Examples 3-27

3.3.1 Response of a Star to Mass Loss 3-27

3.3.2 Blue Stragglers in M67 3-28

3.4 Validation 3-30


3.5.1 Stellar Comparison 3-33

3.5.2 Ages of the M67 Blue Stragglers 3-33

3.5.3 Constructing Isochrones 3-33

References 3-34

4 Elementary Coupling Strategies 4-1

4.1 Multiphysics Problems 4-1

4.2 Combining Two or More Solvers 4-2

4.2.1 Combining Gravity with Stellar Evolution 4-2

4.2.2 Evolution of a Hierarchical Triple System 4-3

4.2.3 Dedicated Channels and Copy Operations 4-6

4.2.4 Particle Subsets and Supersets 4-10

4.3 Analysis Tools 4-12

4.3.1 The Hop Package 4-12

4.3.2 The Kepler Package 4-12

4.4 Multi-code Strategies 4-14

4.4.1 Basic Collision Handling 4-15

4.4.2 Using a Separate Code to Manage a Collision 4-17

4.4.3 Recovering from a Code Crash 4-19

4.4.4 Event-driven Simulations 4-21

4.5 The multiples Module 4-25

4.6 Examples 4-27

4.6.1 Small Cluster with Disk-destroying Encounters 4-27

4.6.2 Stellar and Binary Evolution with Stellar Dynamics 4-30


ix

4.7 Validation 4-37


4.8.1 Interlaced Time-stepping 4-37

4.8.2 Stellar Evolution and Dynamics 4-38

4.8.3 Multiple Stellar Populations 4-38

References 4-39

5 Hydrodynamics 5-1


5.1.1 Underlying Equations 5-2

5.1.2 Turbulence and Shocks 5-5

5.1.3 Hydrodynamical Time Scales 5-8

5.1.4 Hydrodynamical Instabilities 5-9


5.2 Hydrodynamics in AMUSE 5-12

5.2.1 Types of Hydrodynamics Code 5-13

5.2.2 Smoothed Particle Hydrodynamics 5-15

5.2.3 Grid-based Methods 5-17

5.2.4 Managing Shocks and Discontinuities 5-19

5.2.5 Initializing a Grid from a Particle Distribution 5-20

5.2.6 Using a Hydro Code to Simulate a Stellar Merger 5-22

5.2.7 Continuing with Hydrodynamics after a Henyey Code Crash 5-29

5.2.8 Extending the Hydrodynamics Solver 5-30

5.3 Examples 5-35

5.3.1 Collapsing Molecular Cloud 5-35

5.3.2 Circumstellar Disk with a Bump 5-43

5.3.3 Colliding Stars 5-45

5.3.4 Accreting from the Wind of a Companion 5-47

5.4 Validation 5-49

5.4.1 Riemann Shock Tube Problem 5-50

5.4.2 Kelvin–Helmholtz Test 5-51

5.4.3 Cloud-shock Test 5-51

5.4.4 Boss–Bodenheimer Test 5-53


5.5.1 Convergence Test 5-53

5.5.2 Testing the Boss–Bodenheimer Test 5-54

5.5.3 The Dissolving Bump 5-55


x

5.5.4 Collapsing Molecular Cloud with Sink Particles 5-56

5.5.5 A Star-forming Region 5-57

5.5.6 Neutron Star Hits Companion 5-57

5.5.7 Supernova Explosion 5-58

5.5.8 Hoag’s Object 5-61

References 5-62

6 Radiative Transfer 6-1


6.1.1 Underlying Equations 6-3


6.2 Radiative Transfer in AMUSE 6-6

6.2.1 Radiative Transfer Modules 6-6

6.2.2 Ionization of a Molecular Cloud 6-9

6.2.3 Coupling Radiative Transfer with Hydrodynamics 6-13

6.3 Examples 6-14

6.3.1 Heating of a Protoplanetary Disk 6-14

6.3.2 Ionization Front in an H2 Region 6-17

6.4 Validation 6-20


6.5.1 Habitability of a Protoplanetary Disk 6-23

6.5.2 Bumpy disks 6-24

References 6-24

7 Hierarchical Coupling Strategies 7-1

7.1 Code-coupling Strategies 7-1

7.1.1 The Bridge Method 7-2

7.1.2 Implementation of Bridge 7-5

7.1.3 Higher-order Bridge 7-6

7.2 Using Bridge 7-8

7.2.1 Star Cluster in a Static Galactic Potential 7-9

7.2.2 The Classic Bridge 7-12

7.3 Bridging Other Codes 7-15

7.3.1 Bridge Hierarchies and Hierarchical Bridges 7-15

7.3.2 Bridging Gravity with Hydrodynamics 7-20

7.4 Examples 7-25

7.4.1 Dissolving Star Cluster in the Galactic Potential 7-25


xi

7.4.2 Did the Sun Originate in M67? 7-32

7.4.3 Inspiral of a Binary Star into a Common Envelope 7-34

7.4.4 Budding Planets in a Protoplanetary Disk 7-37

7.4.5 Planetary Systems in Star Clusters 7-39


7.5.1 Drift with Gravity Code 7-40

7.5.2 How Did the Sun Escape from M67? 7-40

7.5.3 Half Tree Code, Half Direct 7-42

7.5.4 The Accreting Black Hole in HLX-1 7-43

7.5.5 Forming the Widest Binary Stars 7-45

References 7-47

8 Case Studies 8-1

8.1 Accretion in the Galactic Center from S-star Winds 8-2

8.1.1 Initial Conditions 8-2

8.1.2 The Combined Solver 8-4

8.1.3 Results of the Simulation 8-9

8.2 Supernova Impact on the Early Solar System 8-11

8.2.1 Initial Conditions and Model Parameters 8-12

8.2.2 The Combined Solver 8-12

8.2.3 Radiative Hydrodynamics with Cooling and Heating 8-13

8.2.4 Injection of the Supernova Blast Wave 8-15

8.2.5 The Supernova Blast Wave Hits the Disk 8-16

8.3 Closure 8-19

References 8-19

9 Epilogue 9-1

Appendices

A AMUSE Fundamentals A-1

B AMUSE Specifics B-1

C Programming Primer C-1


xii

Preface

During a break at the MODEST-5 conference in Hamilton, Ontario, in August2004, we were sipping coffee, nibbling on cookies, and discussing the future ofstarlab, an N-body package we had developed and used (with considerablesuccess) in our research. After more than a decade of reliable service, starlab, werealized, faced complicated design choices for the future expansion of the package.Or should we start all over again?

The starlab package contained many novel features not found in comparablestate-of-the-art codes. Most codes at the time, and certainly the leading NBODY seriesdeveloped by Sverre Aarseth, were “monolithic” solvers that had been designed,written, and integrated for one particular purpose. A direct summation N-body codewith a hard-coded realization of stellar evolution is an excellent example of amonolithic code. Because they are written in a single programming language, withsimple data structures, monolithic codes are generally relatively uncomplicated,straightforward to compile, and quite portable.

By contrast, starlab was a non-monolithic code composed of two independentcomponents: a gravitational N-body solver, kira, and a binary population syn-thesis code, SeBa. Much of the internal coding in starlab was devoted tomaintaining consistent communication between its constituent parts. The result wasstill quite tightly coupled, but it preserved the essential kernel of independentcommunicating parts. However, as we contemplated expanding our scope byincluding hydrodynamics, we realized that, although we had anticipated thispossible expansion, we still did not really know how to do it without radicallychanging the basic data structures and rewriting the code. Hard-coding a hydromodule into starlab would be counter to all our design choices, as well as horriblycomplicated to code and maintain, but how else might we expand the code’sfunctionality?

We had no clear solution to the problem, until Sverre Aarseth and Peter Eggletonjoined us. We started talking about the codes they had written. Sverre is the initiatorand main developer of the NBODY series of direct summation N-body solvers. Hiscodes are highly optimized and always written in a historic FORTRAN dialect. Hislatest incarnation at that time, NBODY6, was the old-school counterpart ofstarlab. To be honest, NBODY6 was faster than starlab, but (in our opinion)was less elegantly structured, if one can speak of any formal structure at all. Peter isa pioneer in writing stellar structure and evolution codes. The time Sverre spentwriting NBODY codes, Peter spent improving EVTwin, his stellar evolution code, alsoin vintage FORTRAN.

Sverre looked very happy to hear that we considered starlab past its prime.“NBODY6 is brand-new” he told us, “very alive, and kicking bodies, yes.” Wethought that we might in some way benefit from the many decades of combinedexperience of these two grandfathers of computational astrophysics. Why redesigncode, why rewrite any software, if we already have the right tools at hand? If onlythey could be turned into useful tools with a proper interface. Maybe it would be

xiii

possible to incorporate one of these codes into the other? We asked Sverre how hewould feel about this. He responded: “Wouldn’t it be nice to have Peter’s stellarevolution code as a part of my beautiful NBODY code?” Peter responded: “But,Sverre, my dear friend, how splendid would it be to have your NBODY code as part ofmy stellar evolution code.”

That got us thinking. Maybe we should get away from “mine” and “thine,” andoperate instead in a collective framework? We proposed: “What about if both yourcodes could work together?”While hardly ever in agreement, both men thought thatthis would be an interesting idea, like the Borg (of whom we suspect neither had everheard) assimilating the positive characteristics of everybody to become better as awhole. Alas, they were even more sure that such an attempt would be impossible.You would have codes written in all sorts of languages, and how in the world wouldyou deal with all the nasty communications and unit conversions? Furthermore, thecommunication between codes would become a major bottleneck. No, better to haveanother cookie and dream about NBODY7.

Nonetheless, that conversation gave us the kernel we needed to get started. Thatevening, we had a quiet dinner and discussed the possibilities of a language-independent framework in which codes would operate as modules that carry outspecific tasks. The communication between the various codes would have to gothrough some sort of interface, yet to be determined, that would allow it to performoperations on the data, format it to the requirements of the other codes, andschedule the execution of those codes. Maybe it wasn’t so impossible after all.

The MODEST initiative, which gave rise to the Hamilton conference where thisexchange took place, was a direct outgrowth of our experience with starlab.Starlab began in the early 1990s, as an alternative and competitor to Aarseth’sNBODY series of codes. In collaboration with Piet Hut and Jun Makino, we tried towrite a modular package that combined stellar dynamics and stellar evolution, usingmodern programming paradigms and data structures. The code was written in C++,an up-and-coming language at the time, which afforded many opportunities to gobeyond the rigid arrays used in existing codes. As already noted, the result was verysuccessful, leading to hundreds of scientific papers, but it eventually became clearthat, even with the best of intentions, we still had combined algorithms in a way thatmade it hard to make radical changes to the fundamentals.

This realization led Piet Hut and Mike Shara to organize a conference in 2001 atthe American Museum of Natural History in New York, to bring together experts instellar dynamics, stellar evolution, stellar hydrodynamics, computer science, andother relevant areas, to seek truly modular ways to combine codes in order to createa new computational framework. The meeting was subsequently namedMODEST-1(for MOdeling DEnse STellar systems). Perhaps unsurprisingly, the early samplecodes that emerged from the meeting looked very much like starlab, butMODEST (subsequently re-acronymed as Modeling and Observing DEnse STellarsystems) rapidly became an important forum for discussion of all aspects ofdynamical modeling and observations of dense stellar systems.

Early MODEST meetings focused more on astrophysics than computation, butfollowing the MODEST-5 meeting in Hamilton, a rapid series of satellite meetings


xiv

changed the software landscape. At a December 2005 meeting organized by MelvynDavies at Lund University, in Sweden, a concrete plan for combining existing codeswas formulated, and the discussion continued a few months later in Amsterdam,where we organized another small workshop to discuss the possibilities. Piet Hut wasthere, along with Jun Makino, Peter Teuben, Pierro Spinnato, and Breanndán ÓNualláin. Breanndán was a Python aficionado, and with his help we had a firstversion of a rudimentary working code operational in a few days. We called thisframework MUSE, for Multipurpose Software Environment.

The key idea of MUSE was that no code got to “drive” the simulation.Dynamical, stellar evolution, and other codes were invoked as modules, withsuitably defined interfaces, but the top-level code was a Python script that createdand coordinated the scientific study. The implementation involved heavy use ofPython tools such as f2py and swig, and ran into numerous practical problemsthat needn’t concern us here, but the basic idea of a script-driven, democratic codeframework was established.

After the fundamental ideas had been put into practice—and some of theirshortcomings manifested—we realized that a bunch of astronomers would not beable to make quick progress on such a large software environment. We searched forfunding to hire a dedicated software architect, Arjen van Elteren, who could helpdesign our framework, as well as two computational astronomers, Inti Pelupessyand Nathan de Vries, to develop the first science cases with the new framework. Theteam turned out to be very effective. The framework is now called AMUSE, forAstrophysical MUlti-purpose Software Environment. This book explains some ofthe functionality and operations possible with the framework.

The main objective of this book—and indeed, the entire AMUSE framework—isto do science, to explore scientific questions, to seek new boundaries and explore newphysics by means of simulations. The progression of this book reflects the authors’roots in simulations of dense stellar systems, as well as the historical development ofthe field. After a broad introduction, in Chapter 1, to computational astrophysicsand some AMUSE conventions, we begin our journey in Chapter 2 with gravita-tional dynamics, for decades the foundation of star cluster studies. In Chapter 3, weturn to stellar evolution, and Chapter 4 presents our techniques for combining thesefields into a single integrated simulation. The result is something comparable to the“kitchen sink” codes starlab and NBODY6. In Chapter 5, we expand into newterritory by including hydrodynamics in our simulations; we continue this expansionin Chapter 6 by incorporating radiative transfer to study the effects of stellarfeedback on the hydro- and gravitational dynamics of clusters and other systems.The focal point of the book is Chapter 7, where we present a flexible and robustframework that allows us to combine many codes into a single application. Finally,Chapter 8 wraps up with two case studies based on published material, illustratinghow AMUSE can be applied to real problems at the cutting edge of astrophysicalresearch.

Above all, however, the goal of this book is to have fun. To enjoy computationalastrophysics, we want to explore the nonlinear couplings between different physicaldomains without having to worry too much about the details of energy conservation


xv

in a close three-body interaction or managing the arcana of high-dimensionaldifferential equations. Decades of computational astrophysics research have goneinto some of the modules incorporated into AMUSE. These are trustworthy codesand form an excellent basis for further study—still, never trust a code that doesn’twork, and trust a working code even less.

The AMUSE framework is a work in progress, and we suspect this book containserrors and typos that neither we nor our reviewers nor our editors caught. For thesereasons, we will maintain an evolving document in AMUSE that lists corrections tothe published text and highlights developments in AMUSE that may be of interest toreaders, such as new algorithms, functionality, or insights into the many problemswe address. It can be found in ${AMUSE_DIR}/examples/textbook/updates/AMUSE_updates.pdf, where ${AMUSE_DIR} is the base directory ofthe AMUSE installation (see Section 1.3.5). Incidentally, the “laptop” cited in thetiming estimates for most figures is Steve’s 2.7 GHz 2016 MacBook Pro or Simon’s3.4 GHz Lenovo T460S. Your timing may differ.

Simon Portegies ZwartSteve McMillan


xvi

Acknowledgements

I don’t know half of you half as well as I should like; and I like less than half ofyou half as well as you deserve.

J. R. R. Tolkien

These words were uttered by Bilbo Baggins on 3001 September 22 in front of144 invited guests to celebrate his eleventy-first birthday. With this speech, hewanted to say farewell to and acknowledge friends and family. We also would like toacknowledge a large number of people who contributed to this book, although wewill not go so far as to insult half of them. We at least do not consider any of them atthe same level as Otho and Lobelia.

AMUSE is really a community effort, and a large number of people havecontributed. The Masterʼs level students at Leiden Observatory helped to eliminatebugs and typos during the various courses on computational astrophysics. Weapologize to them for having used them as guinea pigs for the first version of themanuscript.1 We particularly thank Fré Vink, Eero Vaher, and Margot Leemker forpointing out unclear or poorly worded assignments, and the many people whocontributed by adding new code, developing or debugging scripts, or initiating newideas through stimulating discussions. They include: Tjarda Boekholt, MichaelBrewer, Maxwell Cai, Niels Drost, Evghenii Gaburov, Piet Hut, Masaki Iwasawa,Mher Kazandjian, Rob Knop, Michiko Fujii, Nicola Giacobbo, GuilhermeGoncalves, Alvaro Hacar, Adrian Hamers, Rony Keppens, Lucie Jílkova, JunMakino, Carmen Martnez-Barbosa, Yohai Meiron, Breanndán Ó’Nualláin, Jan-Pieter Paardekooper, Steven Rieder, Silvia Toonen, Alessandro Trani, Joshua Wall,Alfred Whitehead, and Thomas Wijnen. Several of the nicest figures were made byEdwin van der Helm (Figure 4.2), Alex Rimoldi (Figure 5.4), Jeroen Bedorf (Figure5.22), and Nora Lützgendorf (Figure 8.3).

We received illuminating private lectures on gravitational dynamics (Chapter 2)by Sverre Aarseth, on stellar evolution (Chapter 3) by Onno Pols and PeterEggleton, on hydrodynamics (Chapter 5) by James Lombardi and VolkerSpringel, and on radiative transfer (Chapter 6) by Barbara Ercolano and KeesDullemond.

During the development of AMUSE and the writing of the book, we madeextensive use of many additional public facilities and packages, including LaTeX,git, linux, matplotlib, python, ipython, ADS, and CDS.

Both authors had the opportunity to spend an extensive amount of time on thisbook, for which we are grateful to our host institutions, Leiden Observatory andDrexel University. We are also grateful to the Center for Planetary Science in Kobe

1Here, we refer to the Cavia porcellus, in honor of the 1901 Nobel prize in Medicine, awarded to E. Adolf vonBehring, who used this cute, furry rodent to develop a serum therapy against diphtheria.

xvii

and the Lorentz Center in Leiden, for hosting our discussions. Parts of the developmentof AMUSE were financed by NOVA NWO (639.073.803 and 614.061.608), NASA(grants NNX07AG95G, NNX08AH15G), NSF (AST0708299), H2020 FET ComPat(project No. 671564), and the EU P7/08 CHARM project.

Without Arjen van Elteren, Inti Pelupessy, and Nathan de Vries, AMUSE wouldnot exist, and we would never have been able to write this book. A special “thankyou” also is due to the anonymous referee Douglas Heggie, who identified manyomissions and errors, which we hope we have corrected. We also thank our editorand staff at IoP, particularly Leigh Jenkins and Daniel Heatley, for their support ofthis writing project.

Our spouses and children have earned considerable praise for their patience. Theyare very happy that this is over, and we are happy that they are still there.


xviii

Author biographies

Simon Portegies Zwart

Simon Portegies Zwart is professor of computational astrophysics atLeiden Observatory. From an astrophysical perspective, his interestsrange from the origin of the Solar System and the whereabouts ofthe Sun’s siblings, but he focusses also on the evolution of binary(and triple) star systems, the ecology of dense stellar clusters and theevolution of the Milky Way galaxy. From a computational-scienceperspective he is interested in high-performance architectures,

numerical algorithms, optimization strategies and deep learning. On the side, heworks on the chaotic nature of dynamical systems with few (but more than two)bodies. In his spare time, he sharpens his mind with Aikido and translating Egyptianhieroglyphs. He is married with three children and lives in historical town Haarlem.

Steve McMillan

Steve McMillan is Department Head and Professor of Physics atDrexel University. His scientific interests include the dynamicsand evolution of star clusters, chaos in dynamical systems, theformation of stars and star clusters, the evolution of planetarysystems in dense stellar environments, and hydromagneticphenomena in planets, stars, and the interstellar medium. He enjoyswriting high-performance software to simulate many aspects of

these problems, and has been involved in numerous software projects targetinglarge-scale astrophysical simulations and the analysis and visualization of complexdatasets. He enjoys supporting the Philadelphia Orchestra and commiserating withthe Phillies. He is married with two children and lives near Valley Forge,Pennsylvania.

Steve and Simon met in 1992 at the Institute for Advanced Study in Princeton. Theysoon became good friends and together they wrote more than 70 scientific papers, inparticular on the evolution of star clusters and the dynamics of black holes. They arenot frightened by large computers or complicated theoretical problems, both ofwhich they address with a good portion of humour, joy, and a sufficient quantity ofhoppy brew: they are in fact like hobbits in all but size.

xix

this content has been downloaded from iopscience. please scroll …€¦ · 6.1 in a nutshell 6-1...

Documents