layup predict should give more observer useful columns like phase angle, ra & dec rates, range

[mschwamb]

layup predict should reproduce similar columns that we have for Sorcha ephemeris generation ra/dec rates, range to object, phase angle etc https://sorcha.readthedocs.io/en/latest/inputs.html#ephemeris-file-optional

[drewoldag]

What do we need to send to the Sorcha function (and what Sorcha function) in order to get back the ra/dec rates, range to object and phase angle.

If you could drop that info here @matthewholman that would be helpful :)

simulation_driver:calculate_rates_and_geometry - Matt

[bernardinelli]

A lot of this is done in https://github.com/dirac-institute/sorcha/blob/10706c88907d693676aae9876073a70611d7b5d7/src/sorcha/ephemeris/simulation_driver.py#L271 , @drewoldag ! Happy to help with integration

[drewoldag]

@matthewholman it looks like the sorcha code will require an input object like this: https://github.com/dirac-institute/sorcha/blob/10706c88907d693676aae9876073a70611d7b5d7/src/sorcha/ephemeris/simulation_driver.py#L23

However, I'm not sure that all of those parameters are passed back the predict C code: https://github.com/Smithsonian/layup/blob/main/src/lib/orbit_fit/predict_result.cpp

Please don't be shy about telling me if I am misunderstanding what I'm seeing :)

[matthewholman]

You are correct that we are not currently passing back all of those parameters. We can easily add jd_tdb to the result structure and then convert that to mjd_tai (on the python side). We have rho, so we can calculate rho_mag (magnitude) and rho_hat (unit vector). We have something close to r_ast and v_ast. Those are the position and velocity vectors of the asteroid, but I believe Sorcha will want them as heliocentric. That conversion, from barycentric to heliocentric, and be easily done on the python side.