POSYDON-code / POSYDON-code/POSYDON

Possible inconsistency in merger-product helium core mass after stellar merger in POSYDON v2.2.8

Open
#847 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

discuss question wontfix
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.

Image

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.