[LEAPSECS] the big artillery

[Warner Losh]

On Nov 2, 2014, at 2:42 PM, Michael Deckers via LEAPSECS <leapsecs at leapsecond.com> wrote:

> 
>  On 2014-11-02 19:04, Warner Losh wrote:
> 
>> On Nov 2, 2014, at 11:21 AM, Michael Deckers via LEAPSECS <leapsecs at leapsecond.com> wrote:
>> 
>>>   For instance, the differential rate d(TAI - UT1)/d(UT1) is
>>>   published as LOD by the IERS as a "dimensionless" number
>>>   with unit ms/d. To compute this, one must be able to
>>>   subtract the reading of UT1 from that of TAI, and to
>>>   compute the difference numerically one has to convert to
>>>   equal units. The rate is computed correctly /only/ if
>>>   one assumes that a second of TAI equals a second of UT1.
>> 
>> This isn’t entirely true. You have to compute the length of the
>> different time scales to the same seconds. You can compute the
>> difference by comparing the clock readings at a fixed point
>> in time after interpolation to a common grid. This will give you the
>> difference in terms of the units of the common grid. If you select UT1
>> as the common grid, then you can also get a rate to come up
>> with the unit less number.
> 
>   Thanks for your reply. If I understand you right you are saying
>   that comparisons require the same time unit being used in the
>   expression of the time scale values. I agree.
> 
>   But I must confess that I do not understand your use of "grid".
> 
>   Time scales are quantities whose values can always be expressed
>   as a sum fundamental epoch + a time value, the latter expressed
>   in a common time unit. The difference between the values
>   (= phases) of two time scales at the same point in spacetime
>   thus is just the sum of the difference of their fundamental
>   epochs plus the difference of their time values (both
>   differences are again time values).
> 
>   And if I compare the rates of the two time scales, then the
>   fundamental epochs used to express the values of either become
>   irrelevant because they are fixed for each time scale.
> 
>   I am not sure which common grid is needed here.

A common grid is an artificial construct that measurements from
different clocks can be interpolated to. The top of second (or other
phase) measurements place place the top of second in time. Interpolating
to a grid places the time of each time scale at a fixed point on the grid
so they can be compared by simple subtraction. The interpolation causes
the local measurement device’s time scale to subtract out, and gives
phase measurements at a specific time.

For example, if UTC top of second for second 1 comes in at local time scale
1.1 and 2.1 and the UT1 PPS for second 1 comes in at 0.95 and 1.96[*], you
can interpolate a phase at time 1.0 on the local time scale for each of these
clocks and know the phase difference at 1.0. Do this for 1.0, 2.0, etc and you
can make phase and frequency statements about UTC and UT1.

[*] I know this is absurdly large, it should be 1.950000001 or so)

Is this required? In the general case it is, but in specific other cases it may
not be absolutely required. It also generalizes to clocks whose frequency
may not be 1Hz.

This method also assumes that the local time scale (oscillator) is more stable than
the acceptable error over the interpolation period, since all physical oscillators are
imperfect.

>> You can also compute the frequency ticking of each time scale
>> in terms of one or the other (or a third independent one) to compute
>> the frequency error of one or both of the time scales. Once you have
>> a frequency error (or difference), conversion of units is trivial. This is
>> more likely how the LOD drift number is computed. It’s how you compare
>> different atomic clocks to say this one is slow, that one is fast and assign
>> a frequency error to each one (and a similar construct to assign the
>> phase error of the PPS each one is producing). ...................
> 
>   Yes, measuring the differential quotient d(TAI)/d(UT1) and
>   measuring the "drift rate" LOD = d(TAI - UT1)/d(UT1)
>   = d(TAI)/d(UT1) - 1 are obviously equivalent.
> 
>> .............................................. There are a variety
>> of ways to measure these differences (though UT1 something has to
>> involve astronomy since it is an observational time base) and compute
>> these numbers.
> 
>   Well, most time scales are observed, directly or indirectly -- just
>   the relationships TCB <-> TDB and TCG <-> TT are fixed, and UTC
>   and the many civil time scales are determined by fiat.

Here, I use “observational” to mean “based on variable astronomical events”
like the earth’s wobbly rotation, rather than the length of the SI second at a
particular point in the geoid. The latter needs no synchronization, while the
former does (which is why we have lap seconds: to keep the SI second ticking
UTC in sync with the wobbly earth).

>> Also, UT1 were ticking in SI seconds, there would be no rate difference. :)

I’m missing an ‘if’ here. “If UT1 were ticking in SI seconds, then there’d be no rate difference."

>   No. The unit used to express the values of a time scale does not
>   determine the rate of the time scale.

86400 UT1 seconds is not exactly the same as 86400 SI seconds, except when

>   UT1 is a timescale that ticks 1 SI second when the Earth Rotation Angle
>   increases by exactly (2·π rad)/86 636.546 949 141 027 072,

Which it rarely does for any length of time.

> and TCB
>   ticks 1 SI second when proper time at the barycenter of the solar
>   system increases by 1 SI second. Each of these time scales is
>   defined or extended to the geoid where their rates differ from
>   that of TAI.

UT1’s rate isn’t determined where it is on the geoid, but how fast or
slow the earth is actually rotating this month, right? I’ve never dealt with TCB,
so I don’t know about that.

Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20141102/80de0608/attachment.pgp>