We have a bug in SSE [and possibly BSE -- I only checked SSE for now].
Example command: ./COMPAS --mode SSE --initial-mass 6.20
(with COMPAS v02.49.04)
This ultimately triggers a call to ResolveElectronCaptureSupernova(), which should therefore leave behind a OXYGEN_NEON_WHITE_DWARF [checked by putting in print statements].
However, that call only happens via ResolveMassLoss() in Star::EvolveOneTimestep(). And ResolveMassLoss() doesn't actually execute the switch to this new type -- instead, it throws a warning because it doesn't expect the type to change. So at the end of ResolveMassLoss(), from which ResolveElectronCaptureSupernova() was called, the type is still TPAGB [checked by putting in print statements].
Then, after EvolveOneTimestep() is called from Star::Evolve(), we immediately call UpdateAttributes(0.0. 0.0, true). By now, however, the star has lost its remaining envelope because it went through a SN, as ResolveElectronCaptureSupernova() set the core mass and the mass to the same value. Yet it's still a star of the TPAGB type, as it's type and class have not yet been updated.
So when ResolveSupernova() is called from UpdateAttributes, TPAGB::IsSupernova() evaluates to false, and a SN doesn't happen. As a result, we are left with a COWD, not an ONeWD.
Now, one can quibble whether this should have been a COWD or an ONeWD in reality -- but I think it's quite clear that the code is not doing what was intended, i.e., not setting the star to be an ONeWD as the initial evaluation of ResolveElectronCaptureSupernova() demands.
My preferred solution would be for a star to actually go supernova and change type accordingly when it successfully goes through a supernova function such as ResolveElectronCaptureSupernova(). A supernova is a more "extreme" event than mere mass loss, and so should preempt other behaviour. However, since the order of calls here is very convoluted, I am rather afraid of how many things I might break if I try to fix this -- so, @jeffriley , could you please take a look?
We have a bug in SSE [and possibly BSE -- I only checked SSE for now].
Example command: ./COMPAS --mode SSE --initial-mass 6.20 (with COMPAS v02.49.04)
This ultimately triggers a call to ResolveElectronCaptureSupernova(), which should therefore leave behind a OXYGEN_NEON_WHITE_DWARF [checked by putting in print statements].
However, that call only happens via ResolveMassLoss() in Star::EvolveOneTimestep(). And ResolveMassLoss() doesn't actually execute the switch to this new type -- instead, it throws a warning because it doesn't expect the type to change. So at the end of ResolveMassLoss(), from which ResolveElectronCaptureSupernova() was called, the type is still TPAGB [checked by putting in print statements].
Then, after EvolveOneTimestep() is called from Star::Evolve(), we immediately call UpdateAttributes(0.0. 0.0, true). By now, however, the star has lost its remaining envelope because it went through a SN, as ResolveElectronCaptureSupernova() set the core mass and the mass to the same value. Yet it's still a star of the TPAGB type, as it's type and class have not yet been updated.
So when ResolveSupernova() is called from UpdateAttributes, TPAGB::IsSupernova() evaluates to false, and a SN doesn't happen. As a result, we are left with a COWD, not an ONeWD.
Now, one can quibble whether this should have been a COWD or an ONeWD in reality -- but I think it's quite clear that the code is not doing what was intended, i.e., not setting the star to be an ONeWD as the initial evaluation of ResolveElectronCaptureSupernova() demands.
My preferred solution would be for a star to actually go supernova and change type accordingly when it successfully goes through a supernova function such as ResolveElectronCaptureSupernova(). A supernova is a more "extreme" event than mere mass loss, and so should preempt other behaviour. However, since the order of calls here is very convoluted, I am rather afraid of how many things I might break if I try to fix this -- so, @jeffriley , could you please take a look?