POSYDON-code / POSYDON-code/POSYDON

H-rich non-burning stars being directed to CO_HeMS grid

Open
#218 5 comments 0 reactions 2 assignees View on GitHub

@sgossage is already working on this.

Since Oct 9, 2025.

help wanted P2 - medium priority question
Dominant language
Python
Stars
45
Forks
37
Avg merge
8d 20h
Merged PRs (30d)
5

Description

H-rich_non_burning stars are being directed to the CO_HeMS step. These stars are then immediately re-directed from the CO_HeMS step, with mixed results.
Here is an example where the the binary continues to complete its evolution after the redirect step (the minority of cases):
Screen Shot 2023-12-13 at 11 28 14 AM

And here is an example of the behavior for the majority of cases. The binary event is set as redirect_from_CO_HeMS two times consecutively, and its state is set to initial_RLOF in the detached step, which ends the evolution:
Screen Shot 2023-12-13 at 11 31 32 AM

This issue is stemming from the fact that H-rich_non_burning are included in STAR_STATES_HE_RICH_EVOLVABLE in the flow, with the following comment:

# CE ejcetion happens istantanously, the star does not readjust before
# we infer the state, if core_definition_H_fraction=0.1 then surface_h1=0.1
# and the state is H-rich_non_burning which we stil want to evolve thorugh
# the step_CO_HeMS

Note: these stars are not designated in STAR_STATES_H_RICH, only STAR_STATES_HE_RICH_EVOLVABLE.

We have the following questions:

  1. Are these H-rich_non_burning stars being classified correctly as such by the IF interpolator, i.e. should they actually be classified as H-rich_Shell_H_burning or similar?
  2. If they are being classified correctly, should they be sent to step_CO_HeMS at all?

Note: We should make sure the redirect_from_CO_HeMS event is not appearing twice consecutively in the evolutionary tracks regardless, as it is confusing for users to read/understand. @ezapartas mentioned this in issue #202.

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.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.