[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Preparation for next release


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


Yes that solved the issue.

FYI.  I had a brand new clean Linux Mint VM that I installed the
development environment and downloaded the repo to and it produced the
exact same behaviors.


OK. I have fixed the test in the git repo.

Thanks for the report.

best regards,
Luc



On Wed, Dec 31, 2014 at 11:41 AM, MAISONOBE Luc <luc.maisonobe@c-s.fr>
wrote:



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

 My output is

for orekit-main/target/test-classes/inpop/inpop10b_TDB_
summer_1969_bigendian.dat
is:

header start epoch 1969-06-04T11:59:20.361
header end epoch 1969-09-08T11:59:20.114
GM_Ven     7.24345232861288E-10
data records: 3

I'm seeming to remember something like this happening in the past with dat
files on Windows, where git is trying to interpret it as a text file and
then injecting extra characters to be helpful. However this is a Linux
system...



I got it!

There are four files in the inpop directory. You are using the one with
TDB time scale, while I was using one in TCB time scale.

Could you look if changing at the start of the test this:

        JPLEphemeridesLoader loader =
            new JPLEphemeridesLoader(JPLEphemeridesLoader.DEFAULT_
INPOP_SUPPORTED_NAMES,
                                     JPLEphemeridesLoader.
EphemerisType.SUN);

into this:

        JPLEphemeridesLoader loader =
            new JPLEphemeridesLoader("^inpop.*TCB.*littleendian.*\\.dat$",
                                     JPLEphemeridesLoader.
EphemerisType.SUN);

would solve the issue?

best regards,
Luc






On Tue, Dec 30, 2014 at 3:47 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr>
wrote:



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

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



 I only have one file listed:



orekit-main/target/test-classes/inpop/inpop10b_TDB_
summer_1969_bigendian.dat



This is very strange. The test should work here.

There is a small standalone program called DEFile in the src/tutorials
part,
in package fr.cs.examples.bodies. Could you run this program with
arguments:

  -in /the/absolute/path/to/inpop10b_TDB_summer_1969_bigendian.dat
-constant GM_Ven

This should display the value of the constant for Venus as extracted
from
the file header.
The value should read: 7.243452440924042E-10.

Then this value is multiplied by au^3/86400^2 to get the desired units
of
m^3/s^2, which
should match 3.2485859679756975E14, as expected by the test.

If you get the correct constant but the test fails, it may be because
the
au value is wrong.
Unfortunately, INPOP ephemerides do not put AU in a constant (so we
cannot use the program
above with -constant AU as we would do in JPL epĥemerides). The AU value
is extracted from
the INPOP header directly (8 bytes at offset 2680 in the file...). You
can get it under
debugger at line 395 of JPLEphemeridesLoader.java, and it should be
1.49597870691E11
for this file (the value is really extracted at line 601 of the file,
and
multiplied by
1000 in the getLoadedAstronomicalUnit method). You can also check it
from
the command line
(except for the 1000x factor) under linux using this:

  dd if=/the/absolute/path/to/inpop10b_TCB_summer_1969_littleendian.dat
\
     bs=1 skip=2680 | od -t f -N 8 --endian=little



A simpler command is:

  od -j 2680 -t f -N 8 --endian=little \
      /the/absolute/path/to/inpop10b_TCB_summer_1969_littleendian.dat

Luc



 By the way, you can use the same method to get GM_Ven value, simply

replace the 2680 bytes
offset above with 7560.

Could you also check the integrity of the binary file? It should be
exactly 37520 bytes long
and its sha1 sum should be 4c5506e8eac1fd3f3c9b304c0e2b5cbe027dda08.
Perhaps the file did
not get considered as binary and some EOL conversion occurred on git
clone. I doubt about this
as the results would probably have been completely random.

best regards,
Luc


 On Mon, Dec 29, 2014 at 2:23 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr>

wrote:

 Hi Hank,



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

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.


 Yes, this is a known (minor) problem. I hesitate to remove the test,

which
was added
to check that some long-running pre-computation are not redone every
time
a propagation
is started. There is probably a better way to do it, but I did not try
to
find one.
We could remove the test if it becomes too cumbersome, as it really
checks
an implementation
detail.



 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 :( :


 This one is new. It probably means the test does not pull the right

file.
It may
be due to new ephemerides present in the test resources and the one
read
first
depends on the local machine (inode time stamps and such low level OS
stuff). This
could be triggered by a new checkout as the directory crawling order
may
happen in
a different order.

Could you check what is really read in the test by printing the output
of
DataProvidersManager.getInstance().getLoadedDataNames() ? If there
is a
JPL ephemerides
in the list in addition to the INPOP ephemerides, then the test should
be
tuned
to not load JPL, regardless of the files visit order in
DirectoryCrawler.
Please
do this test *without* changing your work space, as any new checkout
may
lead to
a different files ordering.

best regards,
Luc


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