gwastro
Add any provided key to `lal_pars` for waveform generation
The purpose of this PR is to pass any non default flags provided to pycbc's waveform generation to the relevant lalsimulation functions by adding them to lal_pars. The code first checks to see if the provided key can be added, and then it tries a camelcase version. The keys are added via the lalsimulation.SimInspiralWaveformParamsInsert{key} function. This code was inspired from bilby: https://git.ligo.org/lscsoft/bilby/-/blob/master/bilby/gw/source.py?ref_type=heads#L583-586.
I opted to try both e.g. modes_choice and ModesChoice as the prior is more convenient to add to configs/HDF. This change is particularly useful for modifying the default behaviour of waveform models (for example turning off multi-banding in IMRPhenomXPHM). This change will affect all pipelines that provide additional flags to the waveform generator.
- [x] The author of this pull request confirms they will adhere to the code of conduct
@hoyc1 Looks like there are some genuine test failures here! @ahnitz Any thoughts about this? The idea is to avoid having to maintain a long list of possible lal_dict arguments to LALSim (similar to how Bilby does it).
@spxiwh, I think I have fixed the test failures by only adding non-default flags to the lal_pars. I think the issue was that there exists functions such as lalsimulation.SimInspiralWaveformParamsInsertMass1, and mass1 is included in the provided dictionary. I am happy to hear other suggestions though!
Wait, what!? Why is there a lalsimulation.SimInspiralWaveformParamsInsertMass1 if mass1 has to be provided explicitly to the waveform generator anyway?
FWIW, the redundant looking InsertMass1 (etc) functions are part of the 'New Waveform Interface', see here https://git.ligo.org/lscsoft/lalsuite/-/commit/5dec1651a0f28879ba5a2f7015744300935f3839?page=2
So the 'key' here is actually the last part of the SimInspiralInsert function name, rather than the LALDict key name itself, if I've understood correctly. I guess this is an inevitable consequence of the lalsim code not having a predictable mapping from the key name to the function name ...