Stellar Merger classification

[reinhold-willcox]

Describe the bug We do not currently have a consistent way to output the final parameters of a system that undergoes stellar merger, without using the detailed printing. This is generally desirable (I won't list all the use cases here) even without an internal prescription for how the post-merger remnant should look - this can be done in post-processing. I believe this should be possible with the current output files we have, without the need for a new one.

Here is a rundown of the stellar merger-related parameters across all the output files:

• In the BSE_System_Parameters output, we have the parameters Merger and Merger_at_birth which appear to work as advertised. I can get all the seeds of non-immediate mergers by masking for 'Merger' and not 'Merger_at_birth'.
• In the BSE_RLOF output, we have the radii of both stars and the separation before and after each MT event (which we can use to calculate if the post-MT system has merged). We also have CEE>MT which is potentially useful, though I have found that it occasionally gives false negatives.
• In the BSE_Common_Envelopes output, we have a parameter specifically for Merger, which works as advertised but requires that a Common Envelope event be triggered.

I have attached an output file that contains several example systems which undergo stellar merger, but are not flagged correctly in the RLOF or CEE outputs, and thus cannot be analyzed. The output was created prior to the seed bug fix, so it's not straightforward to reproduce the systems on the seed alone, but the seeds in question include: [ 106277 148043 159355 159374 159850 160013 ]

Edit: The datafile, even zipped, is too large for github. I'll try to slim it down, but it may be easier to send to interested parties through ozstar...

Interestingly, all of these systems undergo a 1st SN USSN, where the companion is a very low mass (<1 Msol) star. The timing of the SN also coincides with the 2nd MT event, and the separation and radius parameters help to illuminate what (I think) is going on. Taking values specifically from seed 106277 at time 18.664696 Myr:

Output file	Param	pre-Event	post-Event
BSE_RLOF	SemiMajorAxis	5.720709	1.296268
BSE_RLOF	Radius(1)	3.307674	0.000014
BSE_RLOF	Radius(2)	0.655627	0.655701
BSE_Supernovae	SemiMajorAxis	0.454136	1.296268

The post separations from RLOF and SN agree, but the pre separations do not - I attribute this to the SN output sampling the preSN separation in the middle of the timestep ( after the RLOF). If this is the case, the true separation after RLOF is less than the sum of the post-RLOF radii, and thus this should be considered a merger. The System_Parameters flags this as such, so internally Compas is recognizing this correctly. But it then continues and evaluates the SN, widening the separation and resulting in a post-SN and post-RLOF separation that allows for the two stars to fit. It is worth noting that the 2nd MT isn't classified as a CE, so there is no associated CE output event.

A simple fix for this specific bug, which would also solve the larger issue of inconsistent printing of stellar mergers, would be to trigger the CE output any time there is a merger, i.e when the separation is less than the sum of the radii (with tests added at the end of the timestep and in the middle - between the SSE and BSE components). From there, the relevent parameters of interest for mergers can be added as desired to the BSE_COMMON_ENVELOPES_REC and stellar mergers will be appropriately recorded.

urgency_moderate - This is a moderately urgent issue severity_minor - This is a minor bug with minimal impact

Versioning (please complete the following information):

• COMPAS v02.22.00 for the provided data file, but the bug exists in the current v02.24.02 as well.

[reinhold-willcox]

COMPAS_Output_reduced.h5.txt

This should work. Github is weird about file type extensions, but you should be able to just mv this back to a .h5.

[ilyamandel]

@reinhold-willcox , is this still an issue? I've lost track.

[reinhold-willcox]

We haven't fully addressed it, but it should be straightforward with a bit of thought. Likely the best solution is to add more parameters to the default BSE_RLOF output. This will bloat that output a bit, but there's already bloat there and it hasn't been a major concern, and stellar mergers are a common enough use case of interest that I'd advocate including the relevant parameters by default. If that works for you, I'll address this in the next month or so.

[jeffriley]

@reinhold-willcox what attributes of the binary, and/or constituent stars, do you want output? Once we decide we have a stellar merger, we stop evolution and write the system parameters record - no attributes should change between detecting the stellar merger and writing to the system parameters file.

Are there attributes for which you want to know the values at some time earlier than at the detection of the stellar merger, and that might have changed between that time and the detection of the merger? If so, then I don't think we can write them all to the same output file - users should be able to rely on the values of attributes written to a single record in an output file being consistent with each other time-wise. i.e. I don't think we should stash values away (at say time t1) and write them to a log file later (say at time t2) and include the current (i.e. time t2) values for some attributes. If there are attributes that we might want but they are spread over multiple files (e.g. sysparms, rlof, cee) then at post-processing the user should gather them from where they are and be aware of the (probably different) timestamps for each record (and if some log files don't include time, we should make that a default field for those log files).

I know we have pre/post-mt, and pre/post-ce columns in some files - that's ok as long as we know what they are relative to. So, I think we need to be careful about labelling here, and unless a column is labelled to reflect that the values aren't values from the same time as writing of the record, the users should be able to assume they were valid at the time the record was written. I hope I'm making sense...