Decouple Hurley SSE from COMPAS

[ilyamandel]

COMPAS is generally based on plug-and-play recipes, but Hurley SSE recipes are currently deeply embedded in the COMPAS code, making it challenging to include other alternatives (e.g., METISSE). We must decouple Hurley's SSE from single-stellar evolution in general in preparation for the inclusion of alternative models.

[jeffriley]

I wanted to kick this off again at the hackathon... I have a couple of initial questions:

1. We mention MATISSE as an example of an alternative to Hurley SSE. What are the others?
2. COMPAS is (currently) driven by timestep (and age I guess) and stellar type - are the alternatives similarly driven? If so, including alternatives to Hurley won't be that difficult, but if not, then we'd need to do much more work I think.

[ilyamandel]

I think we can stick to the assumption that stellar types (and hence our class hierarchy) will stay the same.

There are other direct stellar track interpolators (e.g., MIST). Perhaps more relevantly, one may want to make specific variations by hand (e.g., the suggestion in #291).

[poojanagrawal]

My 2 cents on this. Other than METISSE (which itself is an improved version of MIST), there are codes like SEVN, Combine, and several home-grown recipes (might not be public). (MIST and likes are more suitable for creating isochrones and are not adapted for pop synth needs). Both METISSE and SEVN are suitable candidates for COMPAS; METISSE because it uses the same stellar types as COMAPS (but is in Fortran) and SEVN because it is written in C++. Alejandro and I discussed this last year and came up with the first steps to include interpolation-based recipes in COMPAS.

[jeffriley]

METISSE because it uses the same stellar types as COMAPS (but is in Fortran) ...

The METISSE code being in Fortran isn't an issue - as long as you are willing to share the code :-) I spent the first 10 years of my programming life programming almost exclusively in Fortran...

... and SEVN because it is written in C++

The language doesn't matter so much - is it compatible with the COMPAS architecture?

It would be easier if we stick to our class hierarchy - so the Hurley stellar types.

At each timestep we calculate number of attributes of stars and binaries. Taking a naive approach, if we can just (optionally) use a method different from the Hurley equations to do those calculations then decoupling COMPAS from Hurley is not too difficult. From an implementation standpoint it doesn't matter too much whether it's an interpolation method or not - as long as we know how to do those calculations. If we can't do that, then it gets a bit more difficult...