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

Re: [Orekit Developers] Earth Centered ICRF

Hi all,

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

Hi Paul,

paulcefo <paulcefo@buffalo.edu> a écrit :

Luc and Hank,

We have a B1950.0 option in Linux GTDS. If you want, I will talk to Zach Folcik about this question.

That would be great!

I have pushed to the main Orekit repository the old B1950-frame branch, and updated it to be in sync with the master branch. In order to get the branch, you can do it either from the command line or using Eclipse. Here are the instructions for those who are not used to Git branches.

From the command line, run first "git fetch" and then "git checkout B1950-frame".

From Eclipse, first select "Team -> Fetch from Upstream" in the context menu in the package explorer. Then create a local branch B1950-frame that will be a mirror of the origin repository branch with the same name by selecting "Team -> Switch To -> New branch", and create the branch using name "B1950-frame" and selecting "origin/B1950-frame" in the "remote repository" part of the list that appears when you press button "Select..." in the "Source:" section of the wizard that should appear.

The implementation of the B1950 frame used here clearly fails, as it does not match the simple test case of a NASA provided ISS orbit. The error is between 20 and 25 meters, which is really huge (I would be happy at millimeters level).

This may be due to different precession-nutation models. The implementation is performed by moving an MOD frame back from Julian date J2000.0 to Besselian date B1950.0 using Lieske and Wahr precession and nutation. Using more recent precession-nutation (MHB2000 model) gives 25 meters error. Perhaps I should use an older precession-nutation model, or simply find the fixed bias between EME2000 and B1950 and apply it without computing it.

best regards,

We have been thinking about coordinate systems lately because we are starting to port the TRAMP program for the maintenance of the GTDS binary files to Linux. Having Linux TRAMP will enable us to generate Timing Coefficient and SLP files for time intervals for which they are not currently available.

I remember this problem, and it would be definitely an improvement if we could check compatibility of Orekit-DSST and GTDS on very long term series.

We have two targets in mind: (1) historical intervals and (2) very long intervals (100 or 200 years). Item (2) relates to demonstrating the ability of the DSST to propagate usefully over very long time intervals.

best regards,


Dr. Paul J. Cefola
Consultant in Aerospace Systems, Spaceflight Mechanics, & Astrodynamics
Adjunct Faculty, Dept. of Mechanical and Aerospace Engineering, University at Buffalo (SUNY)

4 Moonstone Way
Vineyard Haven, MA 02568

508-696-1884 (phone on Martha's Vineyard)
978-201-1393 (cell)


On 10/18/2014 3:54 am, MAISONOBE Luc wrote:
Hi Hank,

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

Hello all,

Looking over the coordinate systems that are available, I can't figure out
a way to get an earth-centered (or for that matter central body centered)
ICRF coordinate system directly. I know I may just be overlooking
something. If it isn't possible, would this be something that others would
be interested in having in the Orekit FramesFactory object?

If you have a use case for this, why not?
Adding predefined frames in FramesFactory is not costly as they are
built only as needed, so we can add as much as we want.

By the way, if you have an accurate definition of what the old B1950
frame really is, this is also one frame that could be worth adding.
There is a B1950-frame branch in the Git repository, but it was never
sufficiently validated. It is also not in sync with master. If anybody
want to give a look at it, they are welcome.

best regards,


This message was sent using IMP, the Internet Messaging Program.

This message was sent using IMP, the Internet Messaging Program.

This message was sent using IMP, the Internet Messaging Program.