Implement the evaluation of higher order modes

[jacopok]

There are two approaches for this:
either training a separate Model for each $(\ell, m)$, or including all relevant HOMs inside the data compressed with PCA and working from there.

The idea is to use the former approach since it's simpler; the requirements to do so are:

• Modify the WaveformGenerator -> Dataset -> Model pipeline to know which mode it's working on,
• Implement the extraction of HOMs from TEOB
• and to correctly compute the normalization
• implement a prediction method including spherical harmonics
• Implement a few TaylorF2 approximants for HOMs

[jacopok]

Perhaps it's not so hard within the code!

Idea: write out a subclass of Dataset, ModesDataset maybe, overriding:

• generate_residuals
• recompose_residuals
• generate_waveforms_from_params

It would then, however, need to generate Residuals in order to neatly fit the PCA pipeline.

So, since just fitting the overall result of adding up the modes is not an option, we need to also modify the Residuals.

[jacopok]

Working on this in branch hom.

• FDWaveforms (just the docs - the class is unchanged)
• Dataset, just the aforementioned methods
• Residuals (docs & the combined / from_combined methods)
• who should know the numbers of points? currently, it's DownsamplingIndices, but maybe that's not great actually
• also, who should know which modes are being handled?
• GreedyDownsamplingTraining.train, but just slightly: list(waveforms.amplitudes) will need to be tweaked
• Model._predict_amplitude_phase, for sure
• also Model.predict, it's not so simple anymore

[jacopok]

The big problem is: do we make all this stuff still work in parallel with the old, no-modes code, or just rewrite everything?

Still, it's important to not wind up with a bunch of if modes statements...

Advantages for rewriting:

• simplicity (in the end): everything is handled within the same protocol
• in the end, the no-modes stuff is really simplified (2, 2)

Disadvantages:

• it would be nice to still be able to use old waveform generators
• adding new tests is better than rewriting old ones

[jacopok]

Or, way simpler! As thought before, just make a ModesModel, which acts as a container for several Model instances.
Each of these has its own WaveformGenerator, which generates a specific mode!

[jacopok]

Relevant papers:

PN waveforms for all modes: http://arxiv.org/abs/0710.0614
Mode twisting for precessing binaries: http://arxiv.org/abs/1012.2879
Mode twisting in TEOBResumS: http://arxiv.org/abs/2111.03675
Mode twisting in a surrogate (IMRPhenomXPHM): http://arxiv.org/abs/2004.06503

[jacopok]

Tricky things:

• timeshift should be the same for all modes - is this easy to implement?
• in a surrogate we cannot inform EOB dynamics: is it possible to run TEOBResumS without that in order to make a comparison? How much are we losing out on if we don't have that?