Warn the user when creating galaxy object, the given SFH is compatible

[aswinpvijayan]

Jack Turner has noticed that currently a user can provide any custom SFH for stars, and provide that to a Galaxy object defined at a redshift, with no check for if the stellar ages and redshift are compatible. The easiest way is to warn the user of it and exit without initialisation of the galaxy object.

[christopherlovell]

This is assuming a fixed (Lambda-CDM) cosmology. What if users want to explore alternative cosmologies? Or to ask 'what would an old galaxy at this redshift look like'?

I think a warning (that can be suppressed) would be good (if the lookback time calculation isn't too expensive), but otherwise we shouldn't restrict users

[WillJRoper]

I didn’t think that’s warning worthy. That sounds like a fully fledged error!

[WillJRoper]

On the flip side, knowing that requires a cosmology is passed which we don’t necessarily want to enforce at that point 🤷‍♂️

[christopherlovell]

This is not an error. If we really want to check for this on behalf of the user, perhaps we can pass an optional cosmology instance at galaxy instantiation - if passed, this then checks that the SFH and redshift are consistent, otherwise it just accepts what the user gives it.

[aswinpvijayan]

Yeah. That makes sense.

[aswinpvijayan]

I guess an example showing that galaxy objects don't necessarily make sfh's consistent might be a good idea.

[WillJRoper]

Forgetting the logistics a second. What possible motivation is there for this not being an error? It's physically impossible, why allow it?

Now, on the logistics, I don't like passing a cosmology object purely for the check. I think it's just a fact that the user needs to not do something unphysical. It's a nasty messy workaround to put a check (whether an error or a warning) for this so best just ignored. Sure, someone could add an example showing it but I don't think it's something we could ever address explicitly.

If someone adds an example great, but lets not leave this issue open forever.

[christopherlovell]

I feel like we have this discussion ad infinitum. So let me provide a concrete example.

Say we are using this within an inference framework, to try to estimate the star formation histories of galaxies. We provide some observed data, and try to infer the ages of the stars, using an analytic SFH from synthesizer. Preventing the creation of stars older than the age of the Universe given an assumed cosmology is a very hard prior on this star formation history.

As another example, a few decades ago stars were discovered that appeared to be older than the age of the Universe. In the end the uncertainties on the stellar population modelling led to a revision of this, but in some sense this was a nice independent test of cosmology.

By fixing the cosmology, and then forcing stellar populations to abide by it, we significantly restrict the generalisability of the code. This isn't just a theoretical exercise either: in CAMELS we are actively changing the value of cosmological parameters, such $\Omega_m$ and $h$, which significantly change the age of the Universe.

[christopherlovell]

There are four options:

1. Leave it as it is, no check or error
2. Provide a cosmology object, and do a check when initialising
3. Provide a cosmology object, and error when initialising
4. Error compared to Lambda-CDM cosmology

I think 4 is strictly a no go, and 3 is very undesirable.

[WillJRoper]

I'd argue any inference without a hard prior on the age of stars coupled to redshift is nonsense ;). Your second argument is more compelling.

My vote is 1. and we close the issue.