The `fromSI`

and `toSI`

methods should have a field version.

**Luc Maisonobe**
(a0cd1aa3)
*
at
06 Dec 17:07
*

Merge branch 'issue-1285' into develop

*
... and
1 more commit
*

The `fromSI`

and `toSI`

methods should have a field version.

It appears the constructor from Instant already exists, as per issue #1107 (closed).
However, this constructors allows any time scale to be used, which is not compliant with the Instant API.
So I would really like to deprecate this constructor and set up another one that enforces `UTCScale`

.

The reversed conversion, on the other hand (from `AbsoluteDate`

to `Instant`

) is really missing and could be implemented exactly as explained in the forum thread. There is no real way to save any computation there, as the UTC time scale really needs specific handling.

Earth Orientation Parameters prediction is based on fitting past EOP history to build models that can be used in the near future after end of history.
The `SingleParameterFitter`

javadoc states that the weights of the EOP history entries is `e^\frac{t-t_0}{\tau}`

, and explains points far in the past before `t_0`

have small weights, hence implying `t_0`

is the fitting date and corresponds to the latest date in the history.
This is however not true, inside the code `t_0`

is the date of the first used entry, which is the fitting date minus the fitting duration. This implies that `t-t_0>0`

for all points and the points closest to the end of the sample have very large weights. In fact, rather than having weights close to 1.0 near fitting date and decreasing exponentially when we go far in the past, we have weights that are close to 1 at the beginning of the fitting interval and that grows up exponentially as we approach the fitting date.
As long as the fitting duration and `\tau`

have reasonable relative values, this is not really a problem as choosing `t_0`

either at start or end of the fitting interval just scales up all weights by some exponential constant. This however induces problems if fitting duration is very large with respect to `\tau`

as the weight will become infinite close to fitting date.

One example is to use a fitting duration of three years and a `\tau`

equal to one day. The infinite weights generate a `MathIllegalStateException`

in the curve fitting.

Fixing this just implies putting `t_0`

to the end of history, which is trivial. With this change, the fitting duration becomes essentially useless, we can just ignore it and rely on the exponential decay of the weight for points far in the past. So we could deprecate the constructor that uses a duration, have it ignore the duration and call a new constructor that does not have any fitting duration.

**Luc Maisonobe**
(3f0e83dd)
*
at
23 Nov 10:51
*

Merge branch 'issue-1278' into develop

*
... and
1 more commit
*

Earth Orientation Parameters prediction is based on fitting past EOP history to build models that can be used in the near future after end of history.
The `SingleParameterFitter`

javadoc states that the weights of the EOP history entries is `e^\frac{t-t_0}{\tau}`

, and explains points far in the past before `t_0`

have small weights, hence implying `t_0`

is the fitting date and corresponds to the latest date in the history.
This is however not true, inside the code `t_0`

is the date of the first used entry, which is the fitting date minus the fitting duration. This implies that `t-t_0>0`

for all points and the points closest to the end of the sample have very large weights. In fact, rather than having weights close to 1.0 near fitting date and decreasing exponentially when we go far in the past, we have weights that are close to 1 at the beginning of the fitting interval and that grows up exponentially as we approach the fitting date.
As long as the fitting duration and `\tau`

have reasonable relative values, this is not really a problem as choosing `t_0`

either at start or end of the fitting interval just scales up all weights by some exponential constant. This however induces problems if fitting duration is very large with respect to `\tau`

as the weight will become infinite close to fitting date.

One example is to use a fitting duration of three years and a `\tau`

equal to one day. The infinite weights generate a `MathIllegalStateException`

in the curve fitting.

Fixing this just implies putting `t_0`

to the end of history, which is trivial. With this change, the fitting duration becomes essentially useless, we can just ignore it and rely on the exponential decay of the weight for points far in the past. So we could deprecate the constructor that uses a duration, have it ignore the duration and call a new constructor that does not have any fitting duration.

**Luc Maisonobe**
(13e7bfab)
*
at
15 Nov 22:46
*

Added tutorial to plot ground tracks, in 2D and 3D.

**Luc Maisonobe**
(e91ef0dc)
*
at
14 Nov 09:02
*

Added new Catalan translations.

**Luc Maisonobe**
(7fdab84a)
*
at
09 Nov 15:15
*

Added translations in Catalan language.

**Luc Maisonobe**
(2a7c1042)
*
at
03 Nov 09:42
*

Documentation typo.

**Luc Maisonobe**
(a1c70a19)
*
at
02 Nov 20:20
*

**Luc Maisonobe**
(2c0f6384)
*
at
02 Nov 09:31
*

**Luc Maisonobe**
(dc9df985)
*
at
02 Nov 09:29
*

Fixes #1256

**Luc Maisonobe**
(dc9df985)
*
at
02 Nov 08:55
*

**Luc Maisonobe**
(a1c70a19)
*
at
02 Nov 08:55
*

Limit use of synchronization in LazyLoadedTimeScales.

*
... and
3 more commits
*

Closes #1252