search

SMU-clusters / ssptools

MIT License
2 stars 0 forks source link

Missing neutron star mass bins #6

Closed nmdickson closed 1 year ago

nmdickson commented 1 year ago

It was recently noticed that, in some very particular cases, the mass function evolution algorithm seems to wind up with no neutron star (NS) bins whatsoever. This does not happen often, but is likely an indicator of a larger issues. It's also almost definitely not real.

For example, when using the specific set of parameters from a fit of NGC6121, but altering the metallicity only:

ssptools_NS_bug_bars

We can that there's clearly a hole in the NS mass at a certain metallicity. (Note: This should not imply that this is a bug related to the metallicity. In this case it is just the one parameter varied, which impacts the remnants formed. This could be caused by any combination of MF parameters which result in a specific makeup of remnants.)

It is very likely this was caused by the extensive changes made to EvolvedMF earlier this year (#3), especially fixes made relating to the NS masses. The NS bins must not be being filled in by remnants as they are formed.

The effects overall should be quite small. It only seems to be a NS problem, and that's the smallest component in these models. But, it still needs to be fixed.

nmdickson commented 1 year ago

The problem has been traced back to the spot in the derivatives where the mass of a freshly formed remnant is placed into the relevant remnant derivative bin (i.e. irem): https://github.com/SMU-clusters/ssptools/blob/f0a19b7708fb184b960e43c9da9e3040da9e3f5a/ssptools/evolve_mf.py#L492-L499

Adding some logs shows that, for this example where no NS bins were populated, the mass (at every timestep which creates a NS because they all have the same mass) always goes into bin 11:

DEBUG:root:In `_derivs_sev` at time 61.51787138066902
DEBUG:root:current turn off bin is 17
DEBUG:root:m1=5.011872336272724, mto=5.7343059427359835, Nj=5361.42756899383
DEBUG:root:m_rem=1.4, cls_rem='NS'
DEBUG:root:irem=11

The issue is that this bin has a mean mass of ~1.35 (left edge at ~1.25), which also places it below the maximum WD mass for this metallicity. Therefore, the most massive WDs are also being placed into bin 11:

DEBUG:root:In `_derivs_sev` at time 61.58416871538862
DEBUG:root:current turn off bin is 17
DEBUG:root:m1=5.011872336272724, mto=5.731055782124926, Nj=5340.47811218627
DEBUG:root:m_rem=1.299616313035207, cls_rem='WD'
DEBUG:root:irem=11

And because the WD/BH IFMR limits are what is used to determine rem_types this bin is labelled as a WD bin.

So, in summary, in certain (very particular) cases, the mass bins will arrange themselves and the WD IFMR will be such that the WD and NS bins will overlap slightly, causing the NS to be placed into a WD bin.

The good news is that this would have no real effect on the dynamics of any models where this bug occurred, it is a very rare bug, and in any past models that any NS bin exists in we can be confident that the bug did not occur.

nmdickson commented 1 year ago

Another consequence of this bug, when it occurs, which is a good indicator, is that the NS mass bin should have been corrected to always have a mean mass of exactly 1.4, but that is of course not the case when it is mixed with the WDs. So whenever you don't see a mass bin of 1.4 in the remnants, the NS are wrong.