[MODEST] SD/SE interface: 3 choices

[Piet Hut]

Dear Colleagues:

One of the goals of our workshop was to specify ways to let existing
computer codes for stellar dynamics (SD) and for stellar evolution (SE)
communicate with minimum modification at either end.  In fact, with a
well-defined minimal interface between the two, SD should not care
whether the information obtained results from running an actual SE code,
or from a table look-up or fitting formula.  The same holds for SE:
each side should see the other as a black box.  Soon, we will also
discuss the role of stellar hydrodynamics (SH), but we'll leave that
out for now, to get started.

During the workshop, we proposed a specific protocol to let SD drive SE.
Expressed in terms of a Fortran function:

      real*8 EvolveStar(id, dtmax, dMmax, dRmax, dYmax, dZmax)

   accepts as first argument an integer variable for the identifier "id",
   followed by five real*8 variables that determine halting criteria.
   The SE code will start evolving the star, from the current time tnow,
   at which the mass, radius, and compositions are Mnow, Rnow, Ynow, Znow.
   The code will stop as soon as one of the following halting criteria
   is satisfied:

      if the time t >= tnow + dt ;
      if the mass M obeys | M - Mnow | > dMmax ;
      if the radius R obeys | R - Rnow | > dRmax ;
      if the helium fraction Y obeys | Y - Ynow | > dYmax ;
      if the metallicity Z obeys | Z - Znow | > dZmax ;

   The function returns the new time t; a negative value for t indicates
   an error condition.  We can choose specific units:

      t  -- in units of millions of years
      M  -- in units of solar mass
      R  -- in units of solar radius

This was only meant as a first shot, to get a discussion started.
Meanwhile, we have thought about two alternatives, i.e. three in total:

1) minimal interface:

   allow SD only to ask the SE code to take one step.
     pro: this is very simple, leading to a function EvolveStar(id)
          with only one argument
     con: the step may be too long; it may be inefficient to drive each
          step externally; the SE code may not even be set up for that;
          also it is not clear what "one step" would mean with table lookup.

2) multi-criteria interface:

   see above; this is what we proposed during the workshop.
     pro: more control for SD
     con: more complex to implement from SE side; SD may ask for time steps 
          that are too small, leading to too much round-off for SE.

3) maximal interface:

   after the creation of a new star through the merger of two old stars,
   SD asks SE to compute a new initial model for the new star, and to
   evolve that new star for its complete lifetime.  SE then produces a
   table with snapshots of all relevant physical parameters at various
   times during the life time of that new star.  This table will then be
   used by SE (or by a third, intermediate manager) to answer all questions
   SD might have about the current or future state(s) of the star.
     pro: SD will have the full SE information available
     con: perhaps more complicated to implement from the SE side

Of course, we could adopt two or even all three of these options,
although there is something to say for keeping things simple by
defining only one preferred option.

We look forward to hear your reactions.

Piet Hut and Jun Makino