I need to account for aberration of light in some optical measurements of satellites. It’s a relativistic correction related to the velocity of the observer relative to the solar system barycentre. I’ve drafted a measurement modifier, but before I make a pull request I’d like to check that this functionality isn’t already in the library?
The modifier is the opposite of standard aberration correction. Usually you would take “natural” (i.e. barycentric, astrometric) measurements and transform them into “proper” directions relative to the observing site. This is what the equations in e.g. Seidelmann, or SOFA do. I implemented an iterative numerical method to invert the equation to allow a transform from “proper” to “natural” directions in order to fit into the measurement modifier framework.
I confirm this is something we don’t have in Orekit.
It would be great to add it.
I wonder if aberration shouldn’t be split into the annual part and the diurnal part (see the figure on p.2 of SOFA) because, depending on the sensor and the reference frame used, some parts of aberration is already corrected when the measurements are received.
That’s a good point @MaximeJ. I was originally hoping that using ICRF coordinates for my measurements, rather than GCRF, would account for the aberration for me. But I tried and that wasn’t the case, as far as I could tell. Is there a way that we can coerce the coordinate transformations to correct for us?
I don’t think so, not easily at least. Orekit transformations are purely kinematic, they can account for translation and rotation (with 0th, 1st and 2nd time derivatives for both) but not for a specific physical process like light aberration correction.
There may be a way to do it by defining your own transform and implementing the correction in the TransformProvider but it would be site dependent.
I think the modifier is the best course of action here. More so because sometimes you want to correct for aberrations and sometimes not.
I’ve seen for example some operators producing TDMs given in ICRF but where both aberrations are already corrected. In that case the transformation would be purely kinematics.
Some other would give “raw” measurements in ICRF where you will have to correct for aberrations.
The modifier API allow for modularity, meaning that depending on the sensor you can add or not any number of modifiers. I think it’s well suited for that use case.
It turns out that the aberration equation from Seidelmann works in both directions (just need to change the sign of velocity), so there’s no need for a numerical solution.
Sorry @MaximeJ, I had this code ready to go so I haven’t considered the separation of annual and diurnal components.
Thanks for adding the aberration corrections to Orekit!
I believe this can be achieved in Orekit by using ICRF as frame for your satellite state. In that way, the light time correction in AngularRaDec.theoreticalEvaluation is carried out in the ICRF frame such that the Earth’s velocity is accounted for (the satellite’s velocity around the Sun is considered for the light time correction). I believe this is equivalent to applying the annual aberration correction.
I believe this ICRF “trick” works for the annual aberration, but it does not correct for the diurnal aberration. Also, I observed a tiny difference (<1e-3 arcsec in my case) between using the ICRF frame and applying the official annual aberration correction. Possibly this is due to the linear approximation inside shiftedBy as mentioned by @Serrof as well. But it may be due to other assumptions, I haven’t checked.
Thanks for the contribution @markrutten
I’ll post some comments directly on gitlab.
From a practical point of view, the effect does not depend on range so it can be precomputed before the OD, without the need for a call at each iteration of the estimator. @dgondelach as far as I’m aware there is no speed of light involved in going from Earth centered to Sun centered frame, so I don’t understand how aberration of light could be implicitly introduced there.
The section “Relationship to light-time correction and relativistic beaming” on this Wikipedia page explains it very nicely: Aberration (astronomy) - Wikipedia
I would say the ICRF “trick” that I described is fundamentally not correct, but it is a good approximation.
You’re referring to the fact that at first order in v/c, the Newtonian and relativistic formulas match (which is a convenient coincidence indeed)? I’ve already checked Wikipedia’s page but I must admit that it’s not limpid for me. Anyway, algebraically speaking, in Orekit, you say that if your state is in a Sun centered frame, its velocity has the Earth’s one substracted so it subsequently plays a role through the light time delay. Is that it?
Yeah, that’s the only way I’ve seen it calculated before. I’ve included a public static method in the modifier class, naturalToProper, to allow you to correct for aberration before OD if that’s your preference.