Non-ZAMS Initialization

[reinhold-willcox]

This is the start of a major refactorization in COMPAS in which we will allow non-ZAMS initialization of stars. This is related to PRs #931 and #1036 (and supercedes both). In the latter, it was suggested that we need to be very careful with the naming convention of variables that use either "ZAMS" or "initial" (or some variation), since these were previously interchangeable, but now have distinct meanings. This PR is the start of that effort to split apart the usage of ZAMS and Initial parameters, and includes the desired non-ZAMS initialization functionality.

This is expected to be a long-term PR, with input from different people at various points. Keeping this version up to date with the other changes in dev will become unmanageable. Thus, I have created a separate branch dev_frozen_for_comparison_with_genzams_changes, which is a version of dev that will not be updated, but can be used for comparison with the changes in this branch. It will be easier to compare the major changes here to a frozen version of dev while we are iterating on this. Once we are happy with this major refactorization, I'll do a subsequent merge to bring these changes up to date with the concurrent updates in dev.

The major edits are described explicitly below.

I would like to get feedback from @ilyamandel @jeffriley and @avigna, specifiically in response to your previous requests, though others are encouraged to contribute as well.

[reinhold-willcox]

Major edits:

• Added functionality for non-ZAMS initialization. This is done by adding an option --initial-stellar-type, and a function FastForward() to the appropriate stellar types. Currently, we only allow for initialization of stellar types that can be set with an evolutionary age \tau = 0, namely MS, HeMS, all WD types, NS, and BH. (This may be extended in the future).
• Variables and attributes are added in all the appropriate places for both ZAMS and Initial values of the stellar parameters. Those are mass, radius, luminosity, and temperature. Omega is only used as "initial", there is no "ZAMS" equivalent.
• In most places, ZAMS has been replaced by "initial". However, this is not necessarily correct. The challenge here is that some functions only need an initial value of some parameter to iterate off of, while other functions really depend on a true ZAMS value, and cannot be replaced with a value that occurs later in the evolution. We will have to go through function by function to check which of these is really required.

[ilyamandel]

@reinhold-willcox -- do you want us to formally review a merge from one branch into another (neither of them being dev, so no review required), or just give you comments on this?

[jeffriley]

Omega is only used as "initial", there is no "ZAMS" equivalent.

We have m_OmegaZAMS, and BaseStar::CalculateZAMSAngularFrequency() that calculates omega at ZAMS using Hurley et al. 2000, eq 108. Does Hurley et al. 2000, eq 108 generalises beyond ZAMS?

Currently, we only allow for initialization of stellar types that can be set with an evolutionary age

Why not implement the complete solution now? All it requires is the user providing a couple of values that we don't otherwise know - that's not difficult to do. Where the user gets those values is not really our concern (though they could easily get them from prior COMPAS runs) - as long as we require they provide them.

We will have to go through function by function to check which of these is really required.

Indeed - so in follow-up to @ilyamandel's question above - what is it you're looking for here? Any review will surely point out what you've just pointed out, so perhaps it is worth you doing that work before we review?

[reinhold-willcox]

@ilyamandel and @jeffriley I will eventually be looking for a formal review, even though the target branch is not dev. For now, I'm just looking for feedback on some of the decisions to use ZAMS or initial, such as what Jeff asked above about m_OmegaZams from Hurley (thanks btw, I'll look into this). I think you both are more familiar with the subtleties of Hurley implementation than I am.

@jeffriley The reason to avoid doing the complete solution now is that it's quite a bit more work for me. I was hoping to avoid scope creep (though that already seems to be happening with this Initial/ZAMS discussion).

[jeffriley]

@reinhold-willcox ok, I'll take a look when I can. I think the work to implement the complete solution is minor compared to the work to introduce what you will be implementing. Let me take a look and see if I'm right.

[ilyamandel]

A few things that stood out from a quick skim (not a review):

BaseStar.cpp:

m_MZAMS = CalculateRadiusAtZAMS(m_MZAMS);
This looks wrong. :)

BaseStar.h, etc:

virtual void FastForward() { return; }
An ambiguous function name.

You require that stellar types with an initial fractional lifetime parameter tau are used as initial types, but you don't seem to ask for tau as an input.