[Stellar-discuss] n processors

[Bill Paxton]

On Dec 12, 2005, at 11:45 PM, Piet Hut wrote:
> Hi Bill, and All:
>
> Greetings from Lund, Sweden, where we are in the middle of the  
> MODEST-6a
> workshop (see http://www.astro.lu.se/~melvyn/modest6a.html).
>
> The most interesting new development, right on the first day of the
> meeting, Monday, Dec. 12, was that we clearly and somewhat  
> unexpectedly
> reached a critical mass of people interested in real hands-on
> experimentation on glueing together stellar dynamics, evolution and
> hydro; topics we've been talking about for years, but it suddenly is
> all going to happen now.

I think the answer is to have all future MODEST meetings at the North  
Pole in January!

> So we decided that we needed a mailing list.
> The question is: shall we use the "stellar-discuss" list for this more
> general goal, or should we have a second parallel list.  Personally,
> I think there will be so much technical overlap (how DO you couple
> Fortran and C, or X and Y, and how DO you do this and that), that most
> people will want to be on both lists.  So I propose widening the use
> of "stellar-discuss" -- and of course, detailed questions in a
> particular field can be addressed in the subject line as such, so that
> not everyone has to read everything.
>
> Bill, since you started to get the ball rolling, is that okay with  
> you,
> to enlarge "stellar-discuss" to talk about modeling stellar evolution,
> stellar dynamics, and stellar hydrodynamics, as well as the question
> how to interface all three?

That would be ideal as far as I'm concerned.  And your first 2  
speakers certainly demonstrate the overlap.

>
> As background information, let me try to summarize that part of the
> first day of the workshop that is relevant for our discussion.
>
> In the morning, we heard two talks, by Ross Church from Cambridge, UK,
> and by Evert Grebbeek from Utrecht, NL, both present here already on
> this email list.
>
> Ross reported running various 10,000-body systems with NBODY6,
> starting with single stars, where each star had a life Eggleton code
> attached to it.  He showed HR diagrams, and good agreement with the
> BSE code of Jarrod Hurley etal.  He also included physical collisions
> between stars, but in a very simple way: after the collisions he
> replaced the merger remnant by a ZAMS model of the same mass, simply
> because he had not had time to do something better.
>
> Evert followed, by reporting that he was able to do now exactly what
> Ross had not yet done, namely to construct starting models for merger
> remnants, in a fully automated way.  Starting from Jamie Lombardi's
> make-me-a-star code, he constructed a merger remnant with a realistic
> stratification of temperature, density, entropy, chemical composition.
> He then carefully interpolated from ZAMS models to the required actual
> merger remnant model, and he demonstrated that he could indeed start
> Eggleton's code from those new models, all fully automatically.

Both reports sound wonderful, and I look forward to hearing more.  I  
can see why you are enthousiatic.

>
> Given that their efforts were nicely complementary, it will be very
> natural for Ross to include Evert's work as a module to add to the way
> her runs his code.  Work by others from the workshop might be relevant
> here as well: Houria Belkus mentioned that she has a program to  
> provide
> spectra for a population of stars, so she could take snapshots that  
> are
> output by Ross's code, and transform those in observational spectral
> information; this is in the context of her work with Joris Van Bever,
> also in developing stellar dynamics/evolution codes.
>
> In addition, Jan Pflamm, a graduate student from Bonn, showed me a
> little scripting language that he had written, similarly to what Ernie
> Mamikonyan, graduate student with Steve McMillan, had started doing,
> to orchestrate stellar dynamics runs, making initial conditions,
> integrating systems in time, and then analyzing them.  He told me that
> he was inspired by the talk I gave at the end of the Modest meeting in
> Edinburgh last year, in which I stressed the need for a very modular
> approach.  Right afterwards, over Christmas, he started writing his
> own modular environment, and I was very impressed to see what he has
> all set up in one year.  He even wrote an Aarseth-like code from
> scratch, like Joris van Bever, in C, based on Aarseth's book.  All
> quite amazing!  And like Steve to Ernie, also Jan's PhD advisor, Pavel
> Kroupa, kept saying to me that this was not his idea and that he was
> not sure whether this was the right thing to do for his student, but
> that clearly Jan did not want to do anything else.  (Steve, do I
> represent Pavel and you correctly ;>?)

Three cheers for students who ignore their advisors!  (I think I only  
talked to mine twice: once to ask him to be my advisor and once to  
tell him when to show up for the oral exams.)

>
> Well, having heard all these eager young people, we now have a pool of
> graduate students who are actually hands-on working on writing Modest
> sofware for their thesis projects.
>
> This is the first time, in the three and a half years since we started
> with Modest-1, that we are clearly going beyond repeating the same
> talking discussions, and we are now moving into hands-on-working
> discussions.  I now really feel that Modest is fully working.  So I
> immediately called for an extra one-hour discussion breakout group,
> at 5 pm, after all the normal talks and discussions were finished.
> I defined the new discussion group around the topic of a "Framework"
> for sharing modules in simulations.  The same questions of interfaces
> and data structures came up again, as in MODEST-1, but now with the
> context that a number of young folks are actually fully ready to start
> working on it together.

I could never get interested in designing interfaces before first  
building something.  It seems that the interface presents itself out  
of the rubble of initial failures and the hard work of folks with  
working parts that would really benefit by working together.

>
> So we decided to start an email list, and to begin writing toy model
> codes, to act as stubs, so that we can first interface the stubs with
> each other, as dummies to do some very simple simulations, much along
> the lines of what Jun and I wrote for the review paper of Modest-1,
> and what we put on the Modest web at that time; see our web site
> http://manybody.org/modest/modest_star.html .
>
> In addition, we started talking about scripting languages to
> orchestrate the dance of modules in a simulation.  Jan Pflamm is
> thinking about rewriting his own little language plus parser,
> switching to Python instead (today I will make a few "ahum"
> remarks about having a quick look at Ruby, just to point out that
> there are alternatives as well ;>, but of course any scripting
> language will do, and it is up to the developer what to choose).
> This will be a rich topic for email list conversations, with now
> Jun and me and Ernie and Jan all starting to write scripts for
> experimentation -- and presumably Peter Teuben is itching to do
> something similar for Nemo as well.

I'll be interested to see how that plays out.  My current working  
model is to duck the issue of Ruby vs. Python vs. whatever for now,  
and simply design with the idea that at some point the pieces of the  
system will want to be accessible from a scripting language.  it is  
probably a reasonable goal to have a system architecture in which a  
complete running code can be assembled using only "low-level" pieces  
and work without a scripting language present at all.  The same  
pieces, minus the top level "driver", should also be loadable into  
the scripting language and combined using a new driver written at the  
script level.   In EZ, for example, there is the core code that does  
evolution, and on top of that is the particular "experiment driver"  
that runs the show and turns the knobs.  In a brave new world, the  
core would be assembled from a set of interoperable modules, and the  
driver would be initially done in Ruby/Python.  If you eventually  
need to run a large experiment on a cluster, say, and it would be  
difficult to manage getting the right Ruby/Python setup, it should be  
possible to rewrite the driver and use the exact same core modules in  
a stand-alone configuration.

>
> Greetings from Sweden, where today is the day of Saint Lucia,
> the Queen of Light, a big tradition here: this morning in our
> hotel over breakfast, ten students caroled for us in a lovely
> way, with the woman playing Lucia actually wearing life burning
> candles in her hair!!!  --  all reminded me somehow of the
> dangers and problems of trying to integrate life stellar evolution
> in a star cluster simulation . . . . an auspicious day to start a
> new collaboration  q(^_^)p .

A Very Happy New Year to you all    ; - D

--Bill