Changing order of particles in SeBa output file

[floriskummer]

Describe the bug
When running a binary star with the SeBa code via AMUSE, the order of the stars (primary or secondary) that is printed in the output file "starev.data" changes depending on the masses of the objects. Currently, the least massive star at each time step is printed first, and the more massive last, while the initial primary should always be printed first.

To Reproduce
In line 20 of interface.cc in the seba directory of AMUSE, I set: static bool is_logging_of_evolve_enabled = true;, in order for starev.data to be created.
Additionally, in lines 71, 118 and 131, I set bi->get_starbase()->dump(starev, false); to bi->get_starbase()->dump(starev, true);, to get more readable output.

Then, run a python script to create and run a binary system:

from amuse.community.seba.interface import SeBa
from amuse.datamodel import Particles
from amuse.units import units, constants

stars = Particles(2)
stars[0].mass = 20|units.MSun
stars[1].mass = 10|units.MSun

binary = Particles(1)
binary.semi_major_axis = 1e4|units.RSun
binary.eccentricity = 0
binary.child1 = stars[0]
binary.child2 = stars[1]

code = SeBa()
code.parameters.metallicity = 0.02
code.particles.add_particles(stars)
code.binaries.add_particles(binary)
channel_stars = code.particles.new_channel_to(stars)
channel_binary = code.binaries.new_channel_to(binary)
channel_binary_reverse = binary.new_channel_to(code.binaries)
channel_stars.copy()
channel_binary.copy()

time = min(code.particles.time_step)
end_time = 25|units.Myr

while time < end_time:
    code.evolve_model(time)
    channel_stars.copy()
    channel_binary.copy()
    time += min(code.particles.time_step)

Expected behavior
The initial primary should always be printed first, and the initial secondary last. When running a binary directly from SeBa this works, because both stars are assigned a unique identity (0 for the primary, and 1 for the secondary). Instead, when running from AMUSE, both stars are assigned an identity of 0, which likely leads to the confusion of which star to print first.

Logs
At line 217 & 218 of the starev.data file (similarly line 3 & 4 of the SeBa.data file that is simultaneously created), mass ratio reversal takes place as the more massive star transitions from an agb star to black hole (from 14.75 to 4.67 solar masses, while the secondary star has roughly 10)

3 2 0 9.69349 12120.1 0     0 3 9.99906 4.89852 4.38063 0 0 8 14.7532 1355.65 3.52315 7.10802
3 2 0 9.69349 9215.76 0.728488     0 19 4.66614 1.98311e-05 5.6125 4.66614 0 3 9.99906 4.89852 4.38063 0

[spzwart]

This is not a bug. This is how SeBa was designed to operate. Simon Prof. Simon Portegies Zwart Leiden University Sterrewacht Leiden PO-Box 9513 2300 RA Leiden, the Netherlands Tel: +31-(0)71 527 5737/8429

…

On Tue, Oct 29, 2024 at 3:57 PM floriskummer ***@***.***> wrote: *Describe the bug* When running a binary star with the SeBa code via AMUSE, the order of the stars (primary or secondary) that is printed in the output file "starev.data" changes depending on the masses of the objects. Currently, the least massive star at each time step is printed first, and the more massive last, while the initial primary should always be printed first. *To Reproduce* In line 20 of interface.cc in the seba directory of AMUSE, I set: static bool is_logging_of_evolve_enabled = true;, in order for starev.data to be created. Additionally, in lines 71, 118 and 131, I set bi->get_starbase()->dump(starev, false); to bi->get_starbase()->dump(starev, true);, to get more readable output. Then, run a python script to create and run a binary system: from amuse.community.seba.interface import SeBa from amuse.datamodel import Particles from amuse.units import units, constants stars = Particles(2) stars[0].mass = 20|units.MSun stars[1].mass = 10|units.MSun binary = Particles(1) binary.semi_major_axis = 1e4|units.RSun binary.eccentricity = 0 binary.child1 = stars[0] binary.child2 = stars[1] code = SeBa() code.parameters.metallicity = 0.02 code.particles.add_particles(stars) code.binaries.add_particles(binary) channel_stars = code.particles.new_channel_to(stars) channel_binary = code.binaries.new_channel_to(binary) channel_binary_reverse = binary.new_channel_to(code.binaries) channel_stars.copy() channel_binary.copy() time = min(code.particles.time_step) end_time = 25|units.Myr while time < end_time: code.evolve_model(time) channel_stars.copy() channel_binary.copy() time += min(code.particles.time_step) *Expected behavior* The initial primary should always be printed first, and the initial secondary last. When running a binary directly from SeBa this works, because both stars are assigned a unique identity (0 for the primary, and 1 for the secondary). Instead, when running from AMUSE, both stars are assigned an identity of 0, which likely leads to the confusion of which star to print first. *Logs* At line 217 & 218 of the starev.data file (similarly line 3 & 4 of the SeBa.data file that is simultaneously created), mass ratio reversal takes place as the more massive star transitions from an agb star to black hole (from 14.75 to 4.67 solar masses, while the secondary star has roughly 10) 3 2 0 9.69349 12120.1 0 0 3 9.99906 4.89852 4.38063 0 0 8 14.7532 1355.65 3.52315 7.10802 3 2 0 9.69349 9215.76 0.728488 0 19 4.66614 1.98311e-05 5.6125 4.66614 0 3 9.99906 4.89852 4.38063 0 — Reply to this email directly, view it on GitHub <#1084>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCPFTDZQUDB72RUNWR6BRDZ56O6NAVCNFSM6AAAAABQ2BZYQOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZDCNJRGUZDKOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rieder]

Hi Simon,
I don't agree, since clearly there is a difference in how SeBa operates on its own and via AMUSE.
As Floris writes: both stars are supposed to have a unique identity, but these seem to be identical when running SeBa from AMUSE... I think this is a bug.