Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates #1

Open
wants to merge 10 commits into
base: add-gw-radiation
Choose a base branch
from
Open

Updates #1

wants to merge 10 commits into from

Conversation

jeffriley
Copy link

@jeffriley jeffriley commented Aug 24, 2024

I have made significant changes to BaseBinaryStar::Evolve(). In its current form, even when the option --emit-gravitational-radiation is not selected, COMPAS v03.01.00 creates a different detailed output file file from COMPAS v03.00.05 for the command:

./compas -n 1 --random-seed 0 --logfile-type csv --detailed-output

The value of dt is calculated differently in v03.01.00 even when --emit-gravitational-radiation is not selected. My changes reinstate the code so that v03.01.00 and v03.00.05 calculate dt in the same way (and produce identical detailed output files) when --emit-gravitational-radiation is not selected.

I believe my changes preserve the dt calculation for GW emission, but you should check this. I have checked for the command shown above, and the detailed output files when --emit-gravitational-radiation is selected are identical - EXCEPT that I have changed the code to reduce the duration of the first timestep (see comments in code). If you remove the reduction of the first timestep, the detailed output files are identical my updates vs your original code (if you choose to remove the reduction of the duration of the first timestep, you should only remove it for the GW case - it should be retained for the non-GW case).

As part of those changes I also changed BaseBinaryStar::ChooseTimestep().

I do not like this line in the code:

m_SemiMajorAxis = utils::Compare(aNew, 0.0) > 0 ? aNew : 1E-20;  // if <0, set to arbitrarily small number

Can we not avoid this kludge? Perhaps if we change the definition of HasStarsTouching() from

return (utils::Compare(m_SemiMajorAxis, 0.0) > 0) && (m_SemiMajorAxis <= RSOL_TO_AU * (m_Star1->Radius() + m_Star2->Radius()));

to

return (utils::Compare(m_SemiMajorAxis, 0.0) >= 0) && (m_SemiMajorAxis <= RSOL_TO_AU * (m_Star1->Radius() + m_Star2->Radius())); 

I don't think that will have adverse effects in other places that HasStarsTouching() is used - thoughts?

@jeffriley
Copy link
Author

jeffriley commented Aug 24, 2024

Actually, the code and comment here:

m_SemiMajorAxis = utils::Compare(aNew, 0.0) > 0 ? aNew : 1E-20; // if <0, set to arbitrarily small number

don't match. The comment says <0, but the code is <= 0. My suggested change to HasStarsTouching() will work for equals 0, but not less than 0. Still, my objection stands - surely there's a better way...

EDIT: In view of the need to get this done this weekend I'm ok to let this go and fix it later.

Copy link

@ilyamandel ilyamandel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @jeffriley ,

I am happy with your change, modulo a request to update the declaration of ChooseTimestep() in BaseBinaryStar.h. (It will happily compile without an update because the signature stayed the same, with a const double argument, but it'll be confusing for future developers otherwise.)

I agree with your unhappiness about the kludge for "over-tightened" binaries -- see my comments on the original PR -- but that can be fixed later (the right fix is, IMHO, to stop using a negative semi-major axis as a proxy for an unbound binary).

Copy link

@ilyamandel ilyamandel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @jeffriley !

I'm not sure if Adam is still online, so I'll merge this in (Adam can always check later, but I don't see anything objectionable here); please go ahead and approve Adam's original PR afterwards if you are OK with it [note my three caveats there on things to work on in the future, one of which matches yours].

@ilyamandel
Copy link

Ahh, never mind, can't roll it in -- claims I don't have write access... Which is strange, because I was able to edit Adam's PR directly on his branch via github?

@jeffriley
Copy link
Author

Odd - I can't pull it in either. I was also able to edit Adam's branch...

@ilyamandel
Copy link

OK, I can just apply the same edits by hand to Adam's branch. ;-)

ilyamandel added a commit that referenced this pull request Aug 25, 2024
Matching Jeff's PR, #1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants