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

[Alexis Robert <alexis.robert@gmail.com>]

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%).

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

>> * 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