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

Re: [Orekit Developers] New snapshot with new orbit parameters forms and eclipse detection



Alexis Robert <alexis.robert@gmail.com> a écrit :

On Tue, Aug 23, 2011 at 2:41 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:
Alexis Robert <alexis.robert@gmail.com> a écrit :
* In the original submission form, I suggested that I could study how
we could optimize things so that they could run faster on a phone ARM
CPU. However, we can see that the main bottleneck is not the actual
computation, but it is loading data sets. And loading the UTC
timescale takes ~10s and is needed each time we need an AbsoluteDate,
which is everywhere.

It seems strange to me that UTC timescale data loading is long. It is only a
few hundred bytes long and consist in a dozen dates with an associated
integer leap. What should be long is Earth Orientation Parameters, which can
be megabytes long, depending on the file format (bulletin B, finals data,
XML data, EOP 05C04 ...) and on the time span.

After timing, it's more like between 5 or 6s on my Nexus One.

If I understood correctly what the profiling report said, it seems to
be linked with the usage of the FastMath class of Apache Common Math.
When you use FastMath.log() (which is a static method), the virtual
machine will call a hidden method named FastMath.<clinit> which will
run all the static fields of the FastMath class if it's the first time
you meet this class. And in FastMath.java there is a part named "//
Initialize tables" which use FastMath.slowexp (40.8%), FastMath.expint
(39.2%) (the bottleneck of expint() seems to be FastMath.quadmult() --
95.6%) and FastMath.slowlog (18.2%).

I understand then. It's not UTC loading per se.
I know about this bottleneck. As I am also a developper of Apache Commons Math, it would be interesting to improve this. Would you mind opening an issue in the bug tracker at <https://issues.apache.org/jira/browse/MATH> ? We should discuss the problem there rather than on the Orekit lists.


zip inflating and data parsing seems to account for ~6% of this time.

Beware thread safety in Orekit is a difficult topic. The problem is really
not synchronization (this is only the tip of the iceberg), but all the
caching. So do not spend much time on this as it is very likely this will be
changed at some time in the future (more probably sooner than later, as this
is a major problem right now).

In fact I've used a mutex to ensure that only one thread will access
Orekit at a time. Meaning that if the "prefetch" thread hasn't
finished his job, the computation thread will wait until he has
finished. The idea was just to preload some data into the Orekit cache
in the background so it can be used later. Currently the prefetch
thread only does TimeScaleFactory.getUTC() and trashes the result.

* Add eclipse detection

By the way, I've used some parts of
tutorials/fr/cs/examples/propagation/EphemerisMode.java, for instance
the radius values and the occulting/occulted objects. I hope I'm not
wrong in the implementation :/ The implementation in the Android app
is here
https://www.orekit.org/forge/projects/socis-2011/repository/revisions/master/entry/src/org/orekit/android/event/EventEclipseProxy.java
(in the load() method).

I'll look at the implementation later. For now, from a user point of view,
it is almost right. The fact the results are shown in a table with AOS/LOS
labels is wrong, but this is really only a display problem.

Ok :)

* selectAllOnFocus has been put on True for the Vector3DView, so
you'll have faster data typing for x/y/z vectors
* An icon has been added and the logo shown is now correct.
* maxCheck for visibility has been risen to 60 secs
* AOS/LOS visualization should be better

So it appears you finally chose to pair events, didn't you ?

Yes :)

For ground station visibility spans, start is AOS and end is LOS, but for
eclipse spans start is eclipse entry and end is eclipse exit. I guess
start/end would be better labels. also one must be aware that for some event
types start correspond to the flag "increasing" being true, while for other
events it may be the opposite, so events pairing should be done using some
parameters stating if we are interested in the time range between
increasing/decreasing or if we are interested in the time range between
decreasing/increasing.

Currently I've used increasing for AOS and decreasing for LOS for both
events, but I'll add this parameter :)

By the way, I have just a question : I was trying to add TLE download
from the web, but don't really know if there is any public web
services to get TLE data. I've heard of Celestrak but as I don't see
any API, maybe there is an other way (or maybe I didn't look far
enough). Is there a place where I can find that ? Thanks :)

I don't know of any publicly available data with a service-like API for individual TLEs. There are web forms like celestrack, where you can download some TLEs. There are also complete files available for exemple from AGI <http://www.agi.com/resources/downloads/data/> (requires subscription). There are also some agreements and contracts between several space entities so one team can donwload files prepared by another team using authentication to access the server. In operational environments, special set ups will be the rule.

Thinking further about that, perhaps we should simply rely on copy-paste done by uther between a web browser and Orekit, and on TLE files on the sdcard (using the various identifiers to select the TLE from a large file, as already available in Orekit).

Luc


* The station selection weirdness has been removed, and when you add a
"Visibility" event, it will ask you one station (and you'll just need
to repeat the operation for the other station you want)
* The engine impulse field has been removed
* The assets/ folder in the sources have been added, so it should build
now
* A context menu has been added so you can remove events

We are sincerely impressed by your good work, thanks a lot!

Thanks :)

Alexis





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