Implement ability to begin evolution of star after ZAMS

[SimonStevenson]

Is your feature request related to a problem? Please describe. At the moment, we are only able to start the evolution of stars/binaries at the zero-age main sequence (ZAMS). This is fine for most cases. However, in some cases it is useful to be able to begin the evolution at some later point in the evolution. This might be useful for evolving systems similar to observed systems such as x-ray binaries, where the binary properties may be observed, for example. The other place where this is useful is in evolving merger products, since those are essentially stars that start after ZAMS. Therefore, resolving this issue is a precursor to issue #209

Describe the solution you'd like Allow the evolution of stars after the ZAMS. For stars on the main sequence, this is fairly straightforward, and just requires the current mass and age. For evolved stars, this will also require the core mass and the stellar type. See SSE/BSE and the associated papers for details.

Describe alternatives you've considered Not allowing the evolution of stars to begin after ZAMS will ultimately limit the extensibility of COMPAS and the science we can do with it.

Additional context Required for implementing mergers, issue #209

[SimonStevenson]

Here is an example of me begining the evolution of a 5 solar mass MS star ~50 Myrs after the ZAMS (orange) compared to starting from ZAMS (blue). So far so good ...

[SimonStevenson]

Some thoughts: at the moment, I have implemented this such that you provide the age of the star (in Myrs) as an additional input parameter. This is how SSE does it, and is useful because this is the form that will be needed for implementing merger products, where their new age is determined by the properties of the merging stars. This is also what you might naturally provide if you are interested in stars of a particular age, for example in a star cluster with a known age.

However, this sort of requires some prior knowledge by the user of the lifetimes of stars of different masses. Here I used 50 Myrs, which was a reasonable midpoint for a 5 solar mass star, but would be way too long for an 80 solar mass star and would be barely past ZAMS for a 1 solar mass star. A more natural quantity to provide might be 'tau', the fraction of the stellar phase elapsed, between 0 and 1; i.e. asking for a star halfway along the MS. This can then be converted to an actual time by multiplying by the lifetime of the stellar phase.

[ilyamandel]

I like the idea of providing tau. How do you handle the winds that might have affected your ZAMS star?

Also, will this work in all stellar phases? MS stars might be relatively straightforward, but IIRC, for some stellar types, the Hurley prescriptions compute certain quantities at the beginning of the phase, so this will require extra care...

Also, while doing this, might be a good idea to keep in mind that, in the future, we'd like to be able to vary the SSE prescription in COMPAS (e.g., use METISSE instead of SSE), so we should start moving the code in the direction of adding that sort of flexibility.

[ilyamandel]

Note the comment on He ZAMS stars in the now closed #524 from @reinhold-willcox :

"As @jeffriley and I recently discovered, it is straightforward to initialise He stars at ZAMS in COMPAS. Currently this is achieved through a hack - it would be preferable to do this in a more robust way, with a flag for users who wish to do this in a systematic way."

[jeffriley]

See PR https://github.com/TeamCOMPAS/COMPAS/pull/732

[reinhold-willcox]

Note that PR #732 does not address the complications of tau / winds / stellar types with values set at the beginning of the phase, but allows for initialization of types which reset tau=0.

[ilyamandel]

@reinhold-willcox , @jeffriley , @SimonStevenson -- is this feature (which I agree would be very useful!) something we can realistically expect to work on?

[reinhold-willcox]

I had a fairly mature PR for this which worked for stars that always start with tau=0. @jeffriley do you remember why we abandoned it? I would love to see this feature implemented, it would be incredibly useful for studies of more evolved binaries, and debugging.

[jeffriley]

No, not really, but the PR is still open I think (PR #732)