[Ncep.list.nems.announce] NEMS master and GFS-FMS frozen from Nov 16 through December 11

Samuel Trahan - NOAA Affiliate samuel.trahan at noaa.gov
Thu Nov 15 17:43:07 UTC 2018


Hi all,

I was asked, possibly sarcastically, to clarify what I meant by, "midnight
Eastern time."  I will attempt to clarify that within the bounds of current
scientific knowledge and technical capabilities.  Relevant links to
international or national standards and research papers are provided.

Unless stated otherwise, any dates or times referred to in NEMS
announcements are Universal Correlated Time (UTC)
<https://www.bipm.org/en/bipm/tai/>, based on the National Institute of
Standards and Technology (NIST) Internet Time Standard
<https://www.nist.gov/pml/time-and-frequency-division/services/internet-time-service-its>,
with the local timezone adjustment
<https://nationalmap.gov/small_scale/mld/timeznp.html> valid at NCWCP
<http://commerce.maryland.gov/Documents/BusinessResource/NCWCP-NOAA-Center-Weather-Climate-Prediction.pdf>
at that time.  When relevant
<https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat>, leap
<https://www.nist.gov/pml/time-and-frequency-division/leap-seconds-faqs>
seconds <https://physics.nist.gov/cuu/Units/second.html> will be specified
<https://www.gps.gov/news/2015/05/leap-second/2015-best-practices-for-leap-second.pdf>.
On both dates in question, the adjustment is -5 hours
<https://www.bipm.org/en/publications/si-brochure/table6.html> relative to
UTC.  The approximate internet time can be viewed at time.gov, but that
time will be imprecise and inaccurate due to the inherent delays in TCP/IP
<https://ieeexplore.ieee.org/document/802014>, magnified by issues with webpage
load times
<https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/page-load-timing-process>.
Some better approximations are:

1. The GPS time
<https://www.usno.navy.mil/USNO/time/gps/usno-gps-time-transfer>.  However,
this suffers from general relativistic
<https://eclipse2017.nasa.gov/testing-general-relativity> effects which
cause a significant deviation in the time, that is partially corrected
<https://link.springer.com/article/10.12942/lrr-2003-1>.

2. NIST Broadcast Time
<https://www.nist.gov/pml/time-and-frequency-division/radio-stations/wwv>,
available via radio <https://science.nasa.gov/ems/05_radiowaves> at 2.5, 5,
10, 15, and 20 MHz.  As noted on their website
<https://www.nist.gov/pml/time-and-frequency-division/radio-stations/wwv>,
there are a variety of effects that must be considered for sub-second
precision.

3. The Network Time Protocol <http://www.ntp.org/>, used to set time on
typical computers.  This suffers from the same TCP/IP delays as time.gov,
but not webpage load times.

Other possible time sources, and different definitions of time other than
UTC, are described throughout the BIPM website
<https://www.bipm.org/en/bipm-services/timescales/>.  As discussed on their
website, as of this writing, high-precision definitions of time deviate by
at most 37 seconds.

Lastly, as noted by the NIST Time of Day FAQ
<https://www.nist.gov/time-and-frequency-division/times-day-frequently-asked-questions-faq#noon>,
"12 a.m. and 12 p.m. are ambiguous and should not be used."  Using
"midnight at the end of" or "midnight at the beginning of" a particular day
<https://www.bipm.org/en/publications/si-brochure/table6.html> removes
ambiguity by referring to the moment at which the day begins and ends in
UTC.  However, this can lead to confusion because of the multiple concepts
known as "day." <https://en.wikipedia.org/wiki/Day>

As a good "rule of thumb," you should assume a +/- 5 minute window around
times in NEMS announcements to allow different definitions of the time,
general relativistic effects, uncalibrated clocks, technological
limitations (like TCP/IP delays), differences in the understanding of the
word "day," and other issues in time specification.

Sincerely,
Sam Trahan

On Thu, 15 Nov 2018 at 08:01, Samuel Trahan - NOAA Affiliate <
samuel.trahan at noaa.gov> wrote:

> Hi all,
>
> After today's NEMS and FMS commits, we're instituting a temporary freeze
> of the NEMS master and GFS-FMS.  Only emergency commits will be allowed.
> This is necessary to allow some urgent FV3 commits to come in to its
> master.
>
> To be specific, these are frozen:
>
> branch "master" of ssh://vlab.ncep.noaa.gov:29418/NEMS
> branch "GFS-FMS" of https://github.com/NOAA-EMC/FMS
>
> from midnight at the beginning of Friday, November 16, 2018 (Eastern time)
> to midnight at the end of Tuesday, December 11, 2018 (Eastern time).
>
> After that, in mid- to late-December, there will be commits to the masters
> of NEMS and its NCEPLIBS-pyprodutil submodule to add SLURM support for
> Theia, GAEA, and Jet.  In January, those three machines will be unusable to
> workflows that haven't transitioned to SLURM.  Hence, that commit HAS to be
> in before the end of December.  You can expect similar commits to the
> masters of many other NOAA repositories in the near future for the same
> reason.
>
> Sincerely,
> Sam Trahan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.lstsrv.ncep.noaa.gov/pipermail/ncep.list.nems.announce/attachments/20181115/f50a1cb9/attachment.html 


More information about the Ncep.list.nems.announce mailing list