Re: [Orekit Developers] Preparation for next release

PS I did a clean checkout of the repository and a clean import (using the "Existing Maven Projects") setting in Eclipse Luna under Fedora 20 running OpenJDK 64-bit Server VM (build 24.65-b04, mixed mode) (java -version producing 1.7.0_71) and I have two tests failing:

DSSTPropagatorTest.testDSSTrestart() fails in certain cases. It looks like they are doing performance tests for 5 consecutive iterations and sometimes it fails to complete in a "timely enough" manner. Subsequent iterations shouldn't take more than 50% longer than the first iteration, is apparently what the test is. If it isn't regularly happening on the test servers then I would say it's not a big deal. My VM is somewhat resource constrained at this moment so that could be what's causing the issue.

JPLEphemeridesLoaderTest.testGMInpop. It appears to be a just a difference on the order of 5e6. since we are pulling gravitational constants I would think that we should be able to match to far greater precision than 1e6, much less 5e6. Maybe my intuition is off on that though :( :

java.lang.AssertionError: expected:<3.24858597E14> but was:<3.24858591760573E14>

at org.junit.Assert.fail(Assert.java:88)

at org.junit.Assert.failNotEquals(Assert.java:743)

at org.junit.Assert.assertEquals(Assert.java:494)

at org.junit.Assert.assertEquals(Assert.java:592)

at org.orekit.bodies.JPLEphemeridesLoaderTest.testGMInpop(JPLEphemeridesLoaderTest.java:114)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)

at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)

at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)

at org.junit.runners.ParentRunner.run(ParentRunner.java:309)

at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)

at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

On Mon, Dec 29, 2014 at 10:36 AM, Hank Grabowski <hank@applieddefense.com> wrote:

I see there are lots of places the BC interpolator was used and is now creating deprecation warnings. Should I create an issue in the tracker and fix them all ?

On Sun, Dec 28, 2014 at 3:40 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:

MAISONOBE Luc <luc.maisonobe@c-s.fr> a écrit :

Hi all,

Hank Grabowski <hank@applieddefense.com> a écrit :

With the new 2D interpolators in Apache Math we will probably want to make
the change to use that for the FixedTropospheric classes. The old bi-cubic
interpolator could be turning seriously wrong numbers. I have an item on
our internal JIRA for fixing that once the new math is incorporated and
then updating the test. I can break off time to do that this week or next.

Fine.

Apache Commons Math 3.4 is finally out. I have updated the dependency in Orekit
pom. The deprecated bi-cubic interpolator triggers warnings. I'll let you make the
required changes.

I have also removed all old deprecated stuff, so only the "new" deprecations introduced
by 7.0 remains. This removal also implied flattening some temporary abstract classes
in the events hierarchy, and this in turn changed EventDetector to a parameterized
interface -this is due to the return types in the fluent API). It's not a big deal and
7.0 is the good time to do that.

Ooops. No, this was a bad move. I've removed it so EventDetector is not
parameterized. In fact the fluent API belong to the implementation level,
not to the detector API level. So what have disappeared is the intermediate
class AbstractReconfigurableDetector, which was intended to be a temporary
hack. Its methods have been merged in the AbstractDetector class. These
methods do *not* belong to the top level interface.

Sorry for the noise.

best regards,
Luc

best regards,
Luc

On Tue, Dec 23, 2014 at 9:42 AM, Luc Maisonobe <Luc.Maisonobe@c-s.fr> wrote:

Hi all,

We are planning to release the next version of Orekit soon. This will be
a major release: 7.0. This version mainly includes the complete DSST
semi-analytical propagator, as the project to include short periodics
terms has been a success, and it also includes the extension to second
order derivatives for many models (Cartesian coordinates, angular
coordinates, attitude modes, ...).

I think the current status is feature-complete. We need to update to the
new version of Apache Commons Math (3.4 will hopefully been released
very soon now). This version brings corrections useful for Orekit. We
also need to remove old deprecated methods and classes, as
we can do on a major version release.

If you think anything else should be included for 7.0, please chime in.
Remember that we can introduce incompatible changes in a major release
like 7.0, but once it is out we will not be able to introduce such
changes in 7.X and will have to wait for 8.0. So if you need some
breaking new feature, now is the time to introduce it.

best regards,
Luc