Improve internal consistency for reporting (previously: Implement separating major events into separate timesteps) #805
Comments
|
For future use, here is a grid of systems which all undergo MT leading to a successful CEE (non-merger). But then the donor collapses into a SN and the newborn NS collides with the companion resulting in a merger (collision is determined based on the periapsis of the new, possibly hyperbolic, orbit, so about half of these would actually point away from the companion and survive). All of this happens in one timestep though. The output is fairly confusing, so I've posted what shows up in BSE_RLOF, BSE_Common_Envelopes, and BSE_Supernovae, with some unrelated parameters cut out for brevity. The gridfile: grid.txt
|
reinhold-willcox
changed the title
|
Update: following discussions of this and related improvements, it is probably not possible to split apart events into different timesteps in all cases. An improved solution would be to ensure that the stellar and binary parameters are consistent any time in a timestep that we want to report before and after values (e.g pre/post MT, CE, SN, etc.). This remains a long term fix that we will aim to address in the coming months. |
|
@reinhold-willcox -- does this supplant and incorporate #722 , #539 and #413 -- i.e., can we close those as duplicates and just keep this one? |
|
@ilyamandel done |
|
@reinhold-willcox is this still an issue? If so, can it be at least ameliorated by using the record-type field and logging records to the RLOF file (and/or other logs files) throughout the timestep? That way the information will be available to users that require it, and other users can just filter those records. |
|
I am convinced that we should only be doing one thing per timestep. Firstly, we now end up with some weird systems that make analysing data a pain in the neck. For example, I find that among ultra-stripped SNe (SN_Type(SN) == 16), all have the pre-SN mass Mass_Total@CO(SN) equal to the pre-SN CO core mass Mass_CO_Core@CO(SN). But, remarkably, all USSNe have a pre-SN stellar type Stellar_Type_Prev(SN) of 8 -- that's a HeHG star, for which the total mass cannot be equal to the CO core mass since it must have a He envelope! That's because they all experience RLOF from the HeHG star and a SN event on the same timestep, and we update the pre-SN mass but not the pre-SN type... Secondly, and perhaps more importantly, we really should be using values at the start of the timestep to evolve during that timestep, not intermediate values. I.e., we should evolve the star using the stellar properties at the start of the time step; we should apply tides using the binary and stellar properties at the start of the timestep; we should apply GWs using the binary properties and masses at the start of the timestep; etc. This is the only way for us to be consistent and to pick sensible timesteps. As for extreme events (SNe, fast case A / case B / case C / CE RLOF), we should check for these at the start of the timestep. If a star is ready to go SN or is in fast case A / case B / case C / CE RLOF, we should undertake that behaviour on a zero-length timestep (*), then return to handling more gradual processes (stellar evolution, tides, GWs, etc.) from the following time step. We'll have to think a bit further about the corner cases, such as the ordering of SNe and RLOF if both are relevant (hopefully, these will be rare if time steps are sufficiently short, and making SNe happen first in this case would not be an issue). (*) Zero length timesteps would lead to identical timestamps, which could be problematic for determining the ordering, so perhaps a minimal timestep on which nothing else happens but the timestamp is slightly incremented would be more appropriate. |
|
Here's a concrete proposal for doing one thing per timestep. During each timestep, do the following in this order for BSE (for SSE, the order is the same, but skip steps 3, 4, and 5, and only compute/update quantities relevant for single stars in the list below).
Notes:
|
As discussed on the compas dev call
The text was updated successfully, but these errors were encountered: