NavList:

   

Reply

antoine.m.couette@club-internet.fr wrote:
> -*-*- Second, I am submitting here-after a fictitious example of an upcoming 
Lunar which shows that - if we were to ignore to-day the effects of delta-T 
on Lunars - we would significantly increase our error in UT determination, 
and therefore our Longitude uncertainty.
> 
> 23 Dec 2009   Height of Eye = 17 ' T = 59�F , P = 29.92 ' Estimated UT / 
Position :  16h58m53.0s / N3707.1W01253.7 - All observations assumed to occur 
at the same time - Distance SUN-MOON = 77�53'7 , SUNL = 5�50'1 , MOONL = 
50�05'0 . All sextant measures are corrected for Instrument error (and only 
instrument error), i.e. all other corrections (dip, refraction, SD, Parallax 
... ) need to be performed from the "raw data" hereabove.

Dip = .0667°, therefore lower limb apparent altitude = 5.7683° (Sun) and
50.0166° (Moon). Refraction (Nautical Almanac formula) = .1451° (Sun)
and .0138° (Moon). Lower limb observed altitude = 5.6232° (Sun) and
50.0029 (Moon).


> *** If we compute observer's position from the observed heights :
> 
> o With delta-T = 66.7 seconds (close to current value for Dec 23, 2009) :

That's different from the prediction in IERS Bulletin A
(http://maia.usno.navy.mil/ser7/ser7.dat),
which says UT1 will be 0.12 s ahead of UTC. Since UTC is 66.184 s behind
TT (until the next leap second), predicted ∆T = 66.06 seconds. This is a
problem because I want to compare your solution, my solution, and the
data from the JPL HORIZONS online calculator.

My software gets ∆T from the user, and doesn't know that the value is
"wrong". But HORIZONS uses the correct ∆T. You can't simply input a
value. Well, not directly. But you can adjust the observer's longitude.

HORIZONS doesn't tell you its ∆T [note 1], but let's assume it uses the
IERS prediction, 66.06 seconds. We want 66.70. I.e., HORIZONS thinks
Earth's rotation is 66.06 slow compared to TT, and we want it to be an
additional .64 s slow. Simulate this by moving the observer west by .64
* 15 * 1.002738 arc seconds (= .0027°). The 15 converts time to arc, and
1.002738 is the sidereal / solar time ratio.

With the USNO MICA program, the method is even simpler. When you select
TT as the input time scale to MICA, it assumes Earth rotates in step
with TT, i.e., ∆T = 0. To apply ∆T, you simply move the observer's
longitude west by ∆T * 15 * 1.002738 arc seconds. This adjusted value is
the longitude with respect to the "ephemeris meridian", which is where
the prime meridian would be if ∆T = 0.

[note 1] JPL HORIZONS can output the "delta T" for any given time.
But this value is *not* TT-UT1. It is TT-UTC, so is constant except that
a 1-second jump occurs when there's a leap second. (Actually, this value
uses "coordinate time" instead of TT, so there are fluctuations on the
order of a millisecond due to relativistic effects.) [end note]

To get compatible azimuths and elevations from HORIZONS, MICA, and other
programs, control of ∆T is important. It took me a long time to figure
out all the above. I hope that info helps someone reduce the size of
those annoying little discrepancies when testing positional astronomy
software!


> Lunar Distance UT = 17h00m00.7s - i.e. TT = 17h01m07.4s - hence UT error = 
-1m07.7s, cleared distance = 78�34.00', and
> We also get the following position at time of Lunar Distance :
> N3659.9W01300.3 (result of 2 body fix), and

Let's check this with HORIZONS, using the adjusted longitude as
explained above. To get Sun apparent azimuth, apparent unrefracted
elevation, and angular diameter, put

!$$SOF (ssd)       JPL/Horizons Execution Control VARLIST

  EMAIL_ADDR = ' '
  COMMAND    = 'sun'
  OBJ_DATA   = 'NO'
  MAKE_EPHEM = 'YES'
  TABLE_TYPE = 'OBS'
  CENTER     = 'coord'
  COORD_TYPE = 'GEODETIC'
  SITE_COORD = '-13.00767,36.99833,0.005'
  START_TIME = '2009-dec-23 17:01:07.4 tt'
  STOP_TIME  = '2009-dec-23 17:01:08'
  STEP_SIZE  = '1'
  QUANTITIES = '4,13'
  APPARENT   = 'airless'
  TIME_DIGITS = 'FRACSEC'

!$$EOF++++++++++++++++++++++++++++++++++++++++++++++++++++++

in an email, with the word "job" as the subject, and send to
horizons@ssd.jpl.nasa.gov . Leave EMAIL_ADDR blank, unless you want to
receive the reply in a different email address. The reply should come
back in a minute or two.

To get Moon data, change 'sun' to '301' (= 3rd planet, 1st satellite).
If you use 'moon', you get an error message saying there are lots of
moons in the solar system; which one do you want?

HORIZONS says Sun azimuth = 234.6738, unrefracted altitude = 5.8953,
semidiameter = .2710. Altitude - semidiameter = 5.6243 = unrefracted
lower limb altitude. The observed altitude was .0010° (.06') less.

HORIZONS says Moon azimuth = 155.5509, unrefracted altitude = 50.2549,
semidiameter = .2517. Altitude - semidiameter = 50.0032 = unrefracted
lower limb altitude. The observed altitude was .0004° (.02') less.

When we apply refraction to the HORIZONS altitudes, we get 6.0350 (Sun
center) and 50.2685 (Moon center). The refracted center to center
separation angle = 78.4161. Subtract the sum of the semidiameters
(.5227) to get the predicted limb to limb angle, 77.8934. The observed
angle was 77.8950, .0016° (.10') greater.

It would be a little more accurate to use the refracted semidiameters.
According to my program, they are .2680 (Sun) and .2517 (Moon, no change
), so the predicted limb to limb angle is 77.8964. The observed angle
was .0014 (.08') less.

Your solution is an excellent match to the observed angles.

Tomorrow I'll use the same method to check your computation with ∆T = 0.

-- 


-- 
NavList message boards: www.fer3.com/arc
Or post by email to: NavList@fer3.com
To , email NavList+@fer3.com

   

Reply