On 02/16/2011 16:52, Mark Calabretta wrote:
On Tue 2011/02/15 18:51:58 PDT, Rob Seaman wrote
in a message to: Leap Second Discussion List<leapsecs@leapsecond.com>
My point is just that archival data is sufficient to characterize the
real world behavior of the algorithms already developed. We needn't
wait ten years to know if data limited to what was available ten years
ago can predict this year's UT1 to some level of confidence.
I was hoping to see more evidence of geophysics in the prediction
algorithms but, apart from a few that incorporate predictions of
atmospheric and oceanographic angular momentum, they mainly seem
to be mathematical extrapolation techniques.
Considering that LOD can be affected by essentially unpredictable
things such as earthquakes and volcanoes; magma currents in the deep
mantle; the melting of the ice caps due to global warming; the
southern oscillation index and Indian Ocean dipole; meteor impacts;
etc., likely including some "unknown unknowns", the task is probably
no less difficult than reliably predicting movements in the stock
exchange 10 years from now.
Applying the short-term models that work really well for 500 days (that
result in an error bar of about 100ms) to long-term works adequately
well for most people, but would exceed the 1s tolerance in the 1000-1500
day time frame due to the list of factors that you've listed.
That said, if leap second insertions were simply deferred for 10
years, DUT1 would probably grow to no more than about 6s (even
including deceleration), which seems much preferable to letting it
grow without limit.
That's part of the compromise that I've put forward. Goal: publish them
out 10-20 years. To get to that goal we can do things like let it get
to 1.1s and see what breaks as Tom has suggested. We can provisionally
publish things out one, two or even three years at first until the
models improve. Based on experiences of purposely pushing things past
the edge, as well as doing things out a few years, we can gradually
stretch that time horizon.
Given that we know approximately what the end point will be 100 years
from now, we could even have a mechanical rule like the leap-day rule
that would put us in the right neighborhood of synchronization. Having
a good, formulaic/mechanical method for declaring leap seconds would be
a vast improvement over the 'update your tables every 6 months' we see
today.
I'd bet that the following would keep us within 10s over the next 100 years:
bool
leap_second_end_of(int year, int month)
{
int m = (year - 2012) * 12 + month - 6; /* First leap june 2012 */
if (month != 6 && month != 12) return false;
if (m < 0) return false;
if (m % 18 == 0) return true;
return false;
}
which would give us a leap second every 18 months, starting June 2012.
Of course, we'd have to tweak the frequency every century to (a) steer
to 0s off and (b) track the observed LOD trends (or in other words, to
steer in phase and frequency to keep UTC synchronized to UT).
If we had something like that, then leap second compliance would
approach that of leap-day compliance in modern software.
Warner
Regards,
Mark Calabretta
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
