Starting a new thread because the previous discussion was a bit long, and also this is a bit of a break from it.
Hey @luc . Just wanted to say I’ve been keeping this in mind as I’ve been working issue-1745, and both GroundStation and ObserverSatellite right now have the ability to let the user enter a clock into the constructor, or construct a default clock if they choose not to. I haven’t put that capability in ObservableSatellite yet but doing so would be fairly trivial.
However, I think the biggest issue in abstracting which ClockModel is used by the MeasurementObject classes might be a bit different than we originally thought. I was doing a little scouting in the clocks classes the other day to see how we might get there from here, and one of the things I realized is that QuadraticClockModel is the only ClockModel class that has a corresponding FieldClockModel. In order to create the FieldClockOffset value used in the derivatives calculations, you currently have to have a ClockModel with a method of creating its own FieldClockModel equivalent, and right now the other clock models don’t.
Structurally this is not a difficult change to implement, but I wanted to point it out because it’s not a trivial change and it definitely has to happen as part of abstracting out the ClockModel type used.