bpp write is not recording SN kicks for some systems.

[katiebreivik]

If the system is disrupted, the first SN which caused the disruption isn't recorded. This also happens if two stars merge to leave behind a compact object (e.g. He star + MS collision --> NS).

I'm still trying to sleuth out why this is happening but maybe @scottcoughlin2014 or @michaelzevin have ideas on how to fix this? Maybe we have already talked about this and I don't remember?

[michaelzevin]

I'm not sure why this would be happening, we should talk about it at the meeting tomorrow.

[katiebreivik]

@scottcoughlin2014 Here is a binary that should have a recorded SN kick in the bpp array and doesn't:

initC = pd.DataFrame([1.0, 1.0, 9.796257, 3.810971, 461234.426274, 0.261915, 0.02, 13700.0], columns = ['kstar_1', 'kstar_2', 'mass1_binary', 'mass2_binary', 'porb', 'ecc', 'metallicity', 'tphysf'])

note that the orbital period is in days here and not years

From the bpp output, you can see that there is an SN which disrupts the binary and the Vsys values are updated, but there is not a recorded SN kick. Here is the bpp output:

tphys	mass_1	mass_2	kstar_1	kstar_2	sep	porb	ecc	RROL_1	RROL_2	evol_type	Vsys_1	Vsys_2	SNkick	SNtheta	bin_num
25.563189	9.586953	3.810841	2.0	1.0	60891.881962	1302.615624	0.261915	0.000326	0.000131	2.0	0.000000	0.000000	0.0	0.0	2
25.632548	9.584600	3.810840	3.0	1.0	60902.578654	1303.073321	0.261915	0.006434	0.000131	2.0	0.000000	0.000000	0.0	0.0	2
25.643798	9.582717	3.810841	4.0	1.0	60911.137404	1303.439621	0.261915	0.013132	0.000131	2.0	0.000000	0.000000	0.0	0.0	2
28.641112	9.164163	3.810836	5.0	1.0	62876.314732	1388.899347	0.261915	0.012283	0.000126	2.0	0.000000	0.000000	0.0	0.0	2
28.754905	1.107869	3.810851	13.0	1.0	-10.149849	1411.335527	99.900000	0.000000	-2.000000	11.0	184.110771	56.597087	0.0	0.0	2
202.600113	1.107869	3.809852	13.0	2.0	0.000000	1411.335527	-1.000000	0.000100	0.000100	2.0	0.000000	0.000000	0.0	0.0	2
203.614038	1.107869	3.809599	13.0	3.0	0.000000	1411.335527	-1.000000	0.000100	0.000100	2.0	0.000000	0.000000	0.0	0.0	2
204.450998	1.107869	3.808455	13.0	4.0	0.000000	1411.335527	-1.000000	0.000100	0.000100	2.0	0.000000	0.000000	0.0	0.0	2
242.992379	1.107869	3.772034	13.0	5.0	0.000000	1411.335527	-1.000000	0.000100	0.000100	2.0	0.000000	0.000000	0.0	0.0	2
244.713103	1.107869	3.733721	13.0	6.0	0.000000	1411.335527	-1.000000	0.000100	0.000100	2.0	0.000000	0.000000	0.0	0.0	2
245.375405	1.107869	0.842797	13.0	11.0	0.000000	1411.335527	-1.000000	0.000100	0.000100	2.0	0.000000	0.000000	0.0	0.0	2
13700.000000	1.107869	0.842797	13.0	11.0	0.000000	1411.335527	-1.000000	0.000100	0.000100	10.0	0.000000	0.000000	0.0	0.0	2

[scottcoughlin2014]

Good news, the kick is written to bcm so it is being recorded, the bad news, I am not really sure in bpp_array.f in the write_bpp function what we were thinking with how we decided what to write to the bpp from the bkick array. I am trying to fix that logic now by being super explicit than I will ping @michaelzevin to review.

[katiebreivik]

sounds good. I'm happy to look it over to make sure it makes sense to me too as an outsider who didn't have much to do with bpp_array.f

[michaelzevin]

@scottcoughlin2014 I forget, did we figure this out?

[scottcoughlin2014]

I do not think we confirmed we are good here. We should do it together quick if we can.

[michaelzevin]

This was fixed by @scottcoughlin2014 and myself in #245