NavList:

   

Reply

On 2017-04-03 17:18, Sean C wrote:
> As for MICA, one option is to look up the current predicted values on the  
[LINK: http://www.usno.navy.mil/USNO/earth-orientation/eo-products] USNO or  
[LINK: https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html] 
IERS websites and adjust the requested UT1 time accordingly. (About -0.5 
seconds.) Another option is to request output in TT and adjust for Delta-T 
"manually". (In other words, use the TT of the actual current UT1.)

But beware of a subtle difference between the UT1 and TT time scale
selections in MICA. In TT the observer's longitude is reckoned from the
ephemeris meridian, i.e., where the prime meridian would be if Earth
rotated in step with TT. But Earth rotation actually lags TT, so the
ephemeris meridian is east of the prime meridian.

For example, at 2017 April 5 06:00 UT1, at 40 W 90 E and 0 meters
height, MICA says Spica is at zenith distance 51.75972° and 170.24710°
azimuth.

MICA's delta T = 69.254, so the equivalent TT = 06:01:09.3, at which
time MICA says Spica is at 51.72283 170.60568, obviously different due
to the change in longitude basis.

The solution is to move the observer west by the sidereal angle
equivalent of delta T, or 15 * 69.254 * 1.002738 = 1041.65″ = 17′ 21.7″.
Corrected longitude = 90° 17′ 21″. (I've used MICA's delta T, but
normally you'd use the true delta T here.) At the corrected location, ZD
= 51.75970, azimuth = 170.24732. That vector is within .6″ of the vector
I got with UT1. The discrepancy is mainly because MICA only accepts time
to .1 s precision, so I couldn't enter an accurate TT equivalent of UT1.

That also limits accuracy if coordinates at a given UTC are needed. You
can look up UT1-UTC as Sean said, then enter the equivalent UT1 in MICA
— but only to the nearest tenth second. If UT1 is off by .05 s, the
topocentric vector to an object can be off by up to 15″ * .05 = .75″,
which is trivial for navigation but may be unacceptable if you're using
MICA as a gold standard to test your computations.

Yet another problem is that if you input the correct UT1, there's still
a delta T error in MICA. Currently UT1-UTC = +.462 s, and so delta T =
32.184 + 37 - .462 = 68.722, but MICA says 69.254. A half second delta T
error can throw the Moon's position off by a quarter second of arc.
Again, that's insignificant in navigation but can be annoying because
it's well short of MICA's potential accuracy.

Since my programs allow manual delta T input, I simply use MICA's value
during software validation. Then everything matches up!

Another solution is possible if you can't change delta T but the
software can tell you the value it's using. Apply an adjustment to UT1
so TT is correct after adding the inaccurate delta T to the adjusted
UT1. Of course now UT1 is wrong and it puts the observer too far west or
east, so apply an equal and opposite adjustment to longitude as
explained previously. I tested that on the ancient ICE ephemeris program
with excellent results.

The main motivation in writing Tinyac was to escape all the above
kluges, get accuracy at least equal to MICA, plus a far more
comprehensive selection of coordinate systems. Those goals were
attained. Unfortunately, the DLL at the heart of Tinyac won't work under
Windows 8 and later. A much improved DLL released more than a year ago
has fixed the compatibility problem and is giving excellent results in
my Luna4 program. But Tinyac is — metaphorically speaking — in pieces on
my workbench pending incorporation of my to-do list.

   

Reply