stellar_mass function in galaxies module

[WillHartley]

In the k-correct templates we have the mass in stars formed, and the mass remaining (after mass loss due to stellar winds, SNe etc.).
We're preparing a PR to allow use of stellar mass remaining. Current behaviour is that the function, stellar_mass(), refers to stellar mass formed. IMO, the default should be to return the remaining stellar mass.

Proposal:
We have two functions,
stellar_mass_formed()
stellar_mass_remain()

Then the function,
stellar_mass()
simply calls stellar_mass_remain()

[Lucia-Fonseca]

Agreed with this proposal.

Note: the stellar_mass() function docstring should explicitly explain that is defaulting to "remain".

[itrharrison]

Sounds good... do you have a sense of what fraction of the time people mean formed / remain when they say "stellar mass"?

I guess there would be three levels of safeguarding against meaning the wrong thing:

1. Only have the _formed and _remain functions
2. Have the stellar_mass function, but with a warning output that it is defaulting to _remain
3. Have the stellar_mass function, but with a docstring indicating that it defaults to _remain

I don't know if we have any sense of how verbose is good/bad for something like SkyPy in terms of giving out warnings like 2. at runtime @rrjbca?

[WillHartley]

IMO, most of the time it is assumed that we mean _remain when talking about stellar masses, with the return fraction (the difference between _formed and _remain) being the first thing considered if the mass estimates seem strange for some reason. Essentially I think most in the community would concur with Richard's comment that using _formed is a bug.

Of the options I prefer number 3, or maybe number 2, though. I can imagine that in the future we might allow use of a different template set that has just one option.

[rrjbca]

To clarify, as implemented, the stellar_mass function does not directly use the mass or mremain data from kcorrect. It uses the fact that the template SEDs are defined per unit "stellar mass", calculates a scaling factor for the compound spectrum that reproduces the sampled absolute magnitude and calls that the galaxies "stellar mass". @WillHartley are you saying that these templates are defined per unit "stellar mass formed" rather than per unit "stellar mass remaining"?

I agree that stellar_mass should return the total current mass of stars and not the integrated star formation history. If that is not the case then this should be reported as a bug and fixed. Wether or not we then decide to implement an extra stellar_mass_formed function is a separate matter.

[WillHartley]

Correct, yes.

[rrjbca]

So to fix this in stellar_mass we just need to multiply by a factor of mass_remaining / mass_formed before summing so that it returns the "stellar mass remaining".

Alternatively, we could rescale our coefficients by that factor when they are sampled, but for consistency I prefer to keep with the convention from kcorrect where the coefficients equate to "stellar mass formed"

Or am I missing something?

[WillHartley]

No, I don't think you're missing anything. That's all it is. I opened the discussion really to decide on the function naming convention and to check that everyone was happy with what I intended to do. I need to write some tests and then make a PR.
Should I also create an issue to cover it?

[WillHartley]

Slight wrinkle in the proposed approach:
The way the (noiseless) mags are derived makes use of the fact that the k-correct templates are normalised to one solar mass (formed). So changing the stellar mass changes the apparent and absolute magnitudes that are output. I suppose this is why Nicholas didn't change the meaning of stellar_mass and instead added a new stellar_mass_remain when he was first implementing this.

But I think even with clear docs, there's still potential for user error. Also, if we want to include different SED sets, it's not clear that the normalisation will always be conveniently one solar mass (though we can pre-scale them). It would be a significant change to remove the dependence though.