Complete the set of ECI/ECF transform routines

[Dave Offiler]

Johannes Fritzer (GFZ) requests completing the set of ECI/ECF coordinate transforms by including satellite velocity as well as position components of POD:

3) The ropp_utils/coordinates module contains routines for
converting positions between the ECI and ECF coordinate frames,
i.e. eci2ecf() and ecf2eci().

The "SUBROUTINE ropp_pp_set_coordinates(rodata)" converts the GNSS
and LEO positions to the the reference frame used internally in
the ropp_pp package, but not the velocities of the GNSS and of the LEO.
 In case the reference frame for the GNSS and LEO velocities 
is not set to "ECI", only a warning message is issued, but no
conversion is actually done.

Is it intended to upgrade the eci2ecf() and ecf2eci() routines to
convert not only positions, but also velocities, and to add the
conversion of the velocity reference frame to

ropp_pp_set_coordinates() in the near future?

If this is not the case, would it make sense that I provide that
feature for including it in the next ROPP release?

[Ian Culverwell]

I am not aware of any plans to process velocity data in ROPP in the way the user requests, mainly because velocities are currently calculated internally in ROPP, by means of the regression routine ropp_pp_satellite_velocities.f90. So unless action were taken to bypass this calculation, ingested satellite velocities would, I think, have no effect.

But perhaps the user does envisage such a course of action. In which case, we would be happy to implement any velocity processing he suggests in the next release.

[Ian Culverwell]

I have tested how much use is made of the input satellite velocities in ropp_pp by artificially multiplying them (and their valid ranges) by 1000, and reprocessing. The results are the same.

(To check that I hadn't made a mistake, I later doubled r_leo, and that definitely did have an effect.)

So I don't think there is any point in converting the velocities as the user suggests. I have asked his permission to mark the ticket as "won't fix".

(Of course, if it is later considered beneficial to use the given velocities, rather than derive them from the positions, then we can re-open the ticket. Or we can implement the velocity transformations if users desire them for other reasons.)

[Ian Culverwell]

No response from user after 5 weeks, so marking ticket "won't fix"