-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EOP-associated routines inputs #3
Comments
Those functions are meant only for internal-use so whether or not the input is standard doesn't really change much. It's just a question of whether the transformation from century\seconds to day is to be performed within the EOP retrieval functions or within the ones that compute the rotations. For the input re-naming, I'm not a fan of the notation (for a generic user it might still make no sense what those name mean, at least at the beginning) but I'm ok with it. |
Yes I agree. I think the safest is that we choose a "unit" and be consistent. I would probably prefer seconds, as it is also the
On this let's see what we can do on the previous point, and then we can take a decision accordingly. |
I changed all time inputs according to the nomenclature: TIMESCALE_UNIT:
EOP are now directly interpolated with TT centuries, so that you don't have to perform the conversion. Additionally, it allows to work with smaller numbers on the interpolators side (which might reduce some rounding\numerical errors). The operation that you point-out is performed only when computing GMST with the 1996 models, which should be a niche usage so I think it really has a negligible impact. |
https://github.com/JuliaSpaceMissionDesign/IERS.jl/blob/fd2ff8a84246f61cd65fbeaee00633128dfcc470/src/eop.jl#L8
All the EOP-associated interfaces seem to require TT centuries.
I would switch to days as it is a more standard input and the EOP data are tabulated daily.
I think would be good to use, for example,
tts
,ttd
andttc
to denote the different inputs within the package, to avoid confusion. Those would be retrieved also in the REPL when writing the function call, thus saving the time to check the documentation for the generict
details.The text was updated successfully, but these errors were encountered: