Draft: Fix XPHM for some aligned spin cases
Description
This fixes an issue found by @soichiro.morisaki where XPHM presents several discontinuities for some aligned spin cases.
When inspecting the individual modes in the J-frame, it is observed that the modes do not span over the whole frequency array. They have a sharp stop that coincides with the discontinuities in the full waveform.
The issue appeared after the review, when we added the tracking of the sign of (L + S)z in this commit.
It happens for aligned spin cases with "large" q and "large" negative spin. In those cases, the cos_beta can flip the sign from -1 to 1 (L grows as the bhs come together and rotate faster, and we pass from L < |pPrec->SL| to L > |pPrec->SL|). This flip makes the wignerD matrices kill the opposite m mode, and that's why we have the transition of frequency content from one mode to the opposite (see attached notebook).
s = pPrec->Sperp / (L + pPrec->SL);
cos_beta = copysign(1.0, L + pPrec->SL) / sqrt(1.0 + s2)The simple solution I see is that for aligned-spin cases (i.e. Sperp=s=0), cos_beta is forced to be positive (=1). If it was set to -1, then the frequency content would be wrong, i.e. modes with m>0 would have support for positives frequencies, but the LAL convention is that m>0 live in the negative frequencies regime for algined spins.
The effect of this fix can be seen in the XPHM_AlignedSpin.ipynb where the old and new behaviour are compared.
XHM Frequency Sequence
A second issue observed in the previous notebook is that the frequency sequence of XHM reaches larger frequencies than the internal cutoff of the model (Mfcut=0.3) and it presents another discontinuity. This is more prominently investigated in XHM_FrequencySequence.ipynb. What happens is that this commit changed the behaviour to generate FrequencySequence only up to Mfcut, but it missed to do it for the polarization function of the higher modes (it was done for individual modes function and 22 mode though). So the discontinuity for high frequencies is due to having the content of only higher modes and not the 22 mode. I have also introduced a fix for that and the comparison can be seen in the XHM_FrequencySequence notebook.
API Changes and Justification
Backwards Compatible Changes
-
This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions -
This change adds new classes/functions/structs/types to a public C header file or Python module
Backwards Incompatible Changes
-
This change modifies an existing class/function/struct/type definition in a public C header file or Python module -
This change removes an existing class/function/struct/type from a public C header file or Python module
If any of the Backwards Incompatible check boxes are ticked please provide a justification why this change is necessary and why it needs to be done in a backwards incompatible way.