[Stellar-discuss] n processors

[Piet Hut]

Hi Bill, and All:

Glad to hear your agreement with widening the scope of our email list.
Through a stroke of either luck or genius or both, Ross gave our list
a name that does not have the word "evolution" in it, so we can now
apply the name "stellar-discuss" to anything stellar, from stellar
evolution to stellar dynamics and stellar hydrodynamics and who knows
what ;>).  Ross today already change the opening lines of the list
web site accordingly.

> 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.

Exactly, well put!!

> 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.

Exactly, that sounds just right.

> 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.

Yes, and our plan is to make this brave new world happen this spring!
We just agreed upon dates for a two-day Modest-6d meeting on Frameworks,
March 27-28, 2006, in Amsterdam, Holland.  Peter Teuben, Jun Makino,
Steve McMillan and I are all committed to attend, and so will Simon
Portegies Zwart, our host.  Hopefully most active people nearby will
attend; those in Holland, Belgium, Germany and the U.K. and assorted
other countries.  Bill, we would be delighted if you could join us,
though we realize it's a long travel for you for two days.

So our plan is to develop toy model versions of all the relevant
modules well before March 27, 28, so that we can spend the workshop
to reflect on our experience with playing with the interfaces between
the toy versions of stellar evolution, dynamics, and hydro, and then
to march on toward your brave new world!

I will send an email to the general MODEST email list, to sollicit
others interested in joining us.  We can then start planning how to
produce and interface our toy models -- while continuing the stellar
evolution (and other physics) discussions.

My intention is to keep the exact same atmosphere and style as Bill
started with his first Call for Comments, a month ago.  We should be
prepared for a wider segment of the MODEST community to join us, if
they like, but this will remain a specialized lists, and discussions
beyond the scope of modular software development will be gently but
firmly guided to other lists.

Ross, you mentioned that you had already started to write a stellar
evolution toy model module, swappable with the current version of
Peter Eggleton's stellar evolution code that you have coupled to your
version of Sverre Aarseth's code.  When you are ready with that,
perhaps you can put a copy of it on the stellar-discuss web site?

At some point, we may want to open a Wiki or set up an CVS or svn
repository or something like that to make it easy to share code.
But perhaps to get started, we could just send code to Ross, to
put up on the web.  As soon as Ross gets tired of that, which will
hopefully be soon, if we produce enough code, we can discuss what
mechanism of code sharing to implement.

Cheers,

Piet