Propeller effect - adding a mechanism to stop accretion onto NSs.

[yuzhesong]

Currently, neutron stars in stable mass transfer are allowed to accrete as much mass as possible. This creates a few issues:

1. MSPs are too massive.
   This is the most direct impact of the issue. As shown in the figure below, MSPs after accretion can go up to 2.4 MSun. This is a lot higher than masses of known MSPs.
   

2. MSPs spin too fast.
   Because there is no stopping the accretion, MT can continue to transfer angular momentum to the NS. This would make MSPs that spin faster than the fastest known MSP. As seen in the P-Pdot diagram below:
   

3. MSP magnetic fields reach the lower limit set by program option.
   This is also obvious in the P-Pdot diagram as the red dots are all located around the 10^8 G line, lower than that of most observed MSPs. As @SimonStevenson pointed out there are multiple factors that can impact the final magnetic field of a MSP, including the magnetic decay mass scale parameter (currently chosen to be 0.025 in this simulation). This image below plots B as a function of DeltaM, the total mass accreted by a pulsar, with varied DeltaMd, the pulsar magnetic field decay mass scale. To avoid getting to Bmin, we need to limit the mass accretion to <0.1--2 Msun, or have slightly higher values of DeltaMd. With the current amount of accretion we have (something like 0.7-8 Msun) basically everything ends up at Bmin.

There are a few ways to go about solving this as Simon and I discussed.

• We can either set a lower limit for spin period, when the MSP reaches this limit, the spin-up and mass accretion both stop. The issue here is that our only reasonable limit for us to put in here would be the spin period of the fastest MSP (PSR J1748-2446ad, 1.4 ms).
• We can also attempt to implement a physical model for the propeller but so far we have failed to find anything that is easy to implement.
• MSP emitting gravitational waves would cause them to spin down again. Implementing this might naturally solve this issue but we are not yet ready for working on this.

So we put this out for the group to see if anyone has any thoughts on this and to get the discussion started.

[SimonStevenson]

Thanks for starting this @yuzhesong !

Just a comment to point out that the y-axis on that last plot should be B/G not B/B0, my bad! Here is an updated version. The coloured boxes labelled 'normal', 'DNS' and 'MSP' correspond to the approximate range of magnetic fields for each class of system, along with a typical range of accreted masses for those systems to guide the eye.

[ilyamandel]

I don't think anybody knows why the fastest pulsars spin at a rate less than physically known thresholds (causality, GR, etc.). Various people such as Lars Bildsten proposed gravitational waves something like 30 years ago, but I think that explanation is no longer in vogue. (To be fair, I have not followed this very closely recently.) It would be very exciting if you could propose a physical mechanism!

Barring that, I am not sure that putting in an arbitrary threshold is very meaningful: I think it's more informative to say that, with the best known physics, we can't reproduce this result and hence it remains a challenge than to hide it by modelling observations rather than evolutionary physics.

[ilyamandel]

Pinging @yuzhesong and @SimonStevenson

[yuzhesong]

@ilyamandel Simon and I have been working on this in the MSPdev branch. The solution we have agreed on between the two of us is to introduce a new --neutron-star-accretion-efficiency-parameter as Simon has mentioned in Slack a while back. This solution while is not solving for the propeller directly, it works in the sense that it limits the maximum mass the NS can accrete and effectively works as a propeller. ee

This issue can be closed when MSPdev is merged into dev.

@SimonStevenson is there anything to add?

[ilyamandel]

OK. I presume the default is to set the accretion efficiency parameter equal to 1?

Is this functionally different from --eddington-accretion-factor (other than being applied only to NS rather than to both NS and BH)? How will the two interact -- multiplicatively?

[yuzhesong]

The default we are currently using is 0.2, which is suggested by the long term average of the simulation in this Li. et al. 2021 paper.

We are implementing this fraction in function BaseBinaryStar::CalculateMassTransfer(). If I remember correctly, when we tried to implement it in Remnants::CalculateMassAcceptanceRate() there were some issues, but I cannot remember what exactly was the problem.

Setting --neutron-star-accretion-efficiency-parameter would limit the mass accretion onto the NS in all cases of mass transfer, including nuclear timescale mass transfer; while setting --eddington-accretion-factor only limits the mass transfer from an evolved donor.

When setting both to non-unity values, the mass accreted onto the NS from a MS is dictated by --neutron-star-accretion-efficiency-parameter only; while mass accreted onto the NS from an evolved donor is indeed a multiplication of both fractions, which isn't ideal. One solution I can think of to avoid this is to force --eddington-accretion-factor to be 1 if --neutron-star-accretion-efficiency-parameter is set to non-unity. Any other suggestions from you would be great.

[ilyamandel]

Hi @yuzhesong :

We are implementing this fraction in function BaseBinaryStar::CalculateMassTransfer(). If I remember correctly, when we tried to implement it in Remnants::CalculateMassAcceptanceRate() there were some issues,

This does not seem to be the right place for it. If it's specific to NS accretion, it should be dealt with in the NS class -- not the BaseBinaryStar class or the Remnants class.

while setting --eddington-accretion-factor only limits the mass transfer from an evolved donor.

I don't think that's true; it's used in Remnants::CalculateMassAcceptanceRate() without any reference to the evolutionary state of the donor.

The default we are currently using is 0.2, which is suggested by the long term average of the simulation in this Li. et al. 2021 paper.

From what I can tell, this is based on attempting to match observations rather than on any deep physical model. I personally don't understand the value of population synthesis which is just being forced to match observational results -- one learns nothing in the process. I therefore recommend leaving 1.0 as the default; of course, if you want to shoehorn the models to match observations, you can run with a value of 0.2.