POSYDON-code / POSYDON-code/POSYDON
Possible inconsistency in merger-product helium core mass after stellar merger in POSYDON v2.2.8
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 45
- Forks
- 37
- Avg merge
- 8d 20h
- Merged PRs (30d)
- 5
Description
Describe the bug
I am using POSYDON v2.2.8 and noticed a possible inconsistency in the helium core mass of stellar merger products.
According to my reading of Section 5.2.3 of the POSYDON v2 paper, the merger-product properties are estimated following Hurley et al. (2002), and the corresponding layers of the two merging stars are summed. In particular, I understood that the helium core mass of the merger product should be obtained by summing the corresponding helium-core layers of the two merging stars.
However, in several runs with different initial parameters, I found that after the merger of two stars that both have helium cores, the helium core mass of the merger product seems to remain equal to the helium core mass of star 1, rather than becoming the sum of the helium core masses of star 1 and star 2.
The example below is one representative case.
To Reproduce
This is a single-binary run, not a population or model grid run, so I do not have an .ini file for a population run.
The initial binary setup is:
STAR1 = SingleStar(**{
'mass': 36,
'state': 'H-rich_Core_H_burning'
})
STAR2 = SingleStar(**{
'mass': 36 * 0.99,
'state': 'H-rich_Core_H_burning'
})
BINARY = BinaryStar(
STAR1,
STAR2,
**{
'time': 0.0,
'state': 'detached',
'event': 'ZAMS',
'orbital_period': 12,
'eccentricity': 0.0
},
properties=sim_prop
)
# metallicity = 1.0 Zsun, set through sim_prop / POSYDON step kwargs
BINARY.evolve()
Here sim_prop is the standard POSYDON simulation-properties object used for this run. I can provide the full sim_prop construction if needed.
The metallicity used in sim_prop is 1.0 Zsun.
The relevant initial binary parameters are therefore:
star 1 initial mass = 36 Msun
star 2 initial mass = 36 * 0.99 = 35.64 Msun
initial orbital period = 12 days
initial eccentricity = 0.0
initial binary state = detached
initial binary event = ZAMS
metallicity = 1.0 Zsun, set through sim_prop / POSYDON step kwargs
Before the merger, I obtained approximately:
star 1 mass = 21.60 Msun
star 2 mass = 33.86 Msun
star 1 helium core mass = 9.35 Msun
star 2 helium core mass = 9.61 Msun
star 1 CO core mass = 0.0 Msun
star 2 CO core mass = 0.0 Msun
After the merger, the reported merger-product properties were approximately:
merger-product mass = 55.45 Msun
helium core mass = 9.35 Msun
CO core mass = 0.0 Msun
Thus, the total mass appears to be added correctly:
21.60 + 33.86 ≈ 55.45 Msun
but the helium core mass appears to remain equal to the helium core mass of star 1:
reported helium core mass after merger = 9.35 Msun
instead of being close to:
9.35 + 9.61 = 18.96 Msun
I have seen similar behavior for other initial parameter choices as well; the above case is just one example.
Expected behavior
Based on my reading of the POSYDON v2 paper, I expected the helium core mass of the merger product to be close to the sum of the helium core masses of the two merging stars.
For the example above, I expected the merger-product helium core mass to be approximately:
9.35 + 9.61 = 18.96 Msun
instead of:
9.35 Msun
Could you please clarify whether this is the intended behavior of the current POSYDON implementation, or whether I may be misunderstanding how the merger-product core masses are stored or updated?
In particular, is the helium core mass reported immediately after merger expected to be the summed helium core mass, or can it be reset later through the matching to the single-star grid?
Screenshots
I attached a screenshot showing the values before and after the merger.
The screenshot compares the pre-merger values of he_core_mass1 and he_core_mass2 with the post-merger value he_core_mass_merged.
POSYDON Version:
POSYDON version: 2.2.8
Specific POSYDON grids used:
POSYDON v2 solar-metallicity grid / 1.0 Zsun grid
System Configuration
Operating System: Ubuntu
HPC scheduler: None
Python version: 3.11.0
Additional context
This behavior seems to occur for multiple initial binary parameters, not only for the example above.
I can provide the full binary history, the relevant output columns, or a more complete minimal script if useful.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the supplied SingleStar/BinaryStar reproduction and run BINARY.evolve() using the stated POSYDON v2.2.8 configuration. Trace how he_core_mass1, he_core_mass2, and he_core_mass_merged are updated during the merger and subsequent single-star-grid matching. Done means establishing whether the post-merger value should be summed and documenting or correcting the observed behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100