Add option to utilize GPR model to create zero eccentricity initial orbital parameters

[vtommasini]

Expanded file to allow option of utilizing either PN approximation or a pre-trained GPR model to create zero eccentricity initial orbital parameters. Original PN logic remains unchanged.

method = GPR option: first computes the standard PN baseline for D_0, Omega_0, and adot_0, then applies a correction from a trained GPR model on top of the PN baseline.

currently only works for zero eccentricity GPR; eccentric GPR option is left for a future PR.

runnable both in Python and as a CLI.

[Copilot]

Pull request overview

This PR extends SimulationSupport.EccentricityControl.InitialOrbitalParameters to optionally compute zero-eccentricity initial orbital parameters using a PN baseline plus a Gaussian Process Regression (GPR) correction, and adds a Click-based CLI wrapper for the same functionality.

Changes:

• Add method=("PN"|"GPR") and gpr_checkpoints to select PN-only vs. PN+GPR-corrected parameter estimation.
• Refactor PN computation into a dedicated helper and add GPR helpers for feature vector assembly and checkpoint-based corrections.
• Add a CLI command (initial-orbital-parameters) with text/JSON output.

Suppressed comments (2)

src/SimulationSupport/EccentricityControl/InitialOrbitalParameters.py:429

• NotImplementedError is raised with an empty message. Since this is a user-facing code path (selected by method == "GPR" and nonzero eccentricity), it should explain the limitation (e.g. GPR currently supports only zero eccentricity).

    raise NotImplementedError("")

src/SimulationSupport/EccentricityControl/InitialOrbitalParameters.py:161

• Spelling typo in the comment (supperted -> supported).

    # Only zero eccentricity is supperted here, since it utilizes ZeroEccParamsFromPN

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[nilsvu]

Please add a test that runs the added code. Please also look at the Copilot review and consider the suggestions.

[nilsvu]

One thing that we haven't figured out yet is how to ensure the trained model matches the simulation we want to run. For example, the trained model very likely must use the same initial data formulation (e.g. SKS or SHK) and the same initial gauge transition to be useful. For now, I suggest this:

1. Add a list of these required features to the saved model file. I also suggest to add the list of SXS IDs that the model was trained on to the saved model.
2. When evaluating the model, print a logger.warning with the required features. Then the user has to make sure they use the model within these restrictions and don't assume it's generally valid.