[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 :
Hi,
Hello Alexis,
I've just released a new snapshot available here :
https://www.orekit.org/forge/attachments/download/60/orekit-20110822.apk
Thanks for this new release.
There isn't huge visible changes, but only tiny changes which should
improve the usability :
* Orbit parameters forms have been completely rewritten. They are now
standard forms and are not in a "list" style like before, this will
reduce the number of clicks needed to type data.
The new form is a really good improvement. It still uses radians
instead of degrees for input but it is definitely a better form.
By the way, I've discovered that the orbit parameters window in the
previous versions were erranous and I'm really sorry :( They sometime
required requested fields that were not even used, and so on, because
I copied the keplerian form to do the other orbit types, since it's
basically the same structure and cannot be factorized much. In this
release I've triple checked with the Orekit API if the requested
parameters match, and they should do.
I didn't check all orbit types yet, I'll do it in the next few days,
when I find time.
* 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.
Are you sure it is UTC that takes so long ? If so, it is really simple
to optimize it a lot and to almost suppress the loading time.
The idea was to create a thread, which will automatically prefetch
some often used datasets parts in the background while you're filling
in your forms.
Currently, it only loads the UTC timescale, but you can already notice
the speed improvement (if you don't fill the forms too fast). As this
is the main bottleneck for other parts on the application, you should
experience faster loading times (like the Frame conversion part, and
so on). Also, as I've seen on the SOCIS page that Orekit is not
thread-safe, it uses a mutex to lock Orekit computation parts and
release it when the background thread has finished his job. I've used
a synchronized(), but I'll switch to a java.util.concurrent.Semaphore.
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).
* 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.
* A settings panel has been added. To access it, just press your
"menu" key on the application front page, and you'll be able to change
Orekit dataset path and the default central acceleration coefficient
value.
Fine, thanks.
* 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 ?
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.
* 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!
Luc
Have a nice day :)
Alexis Robert
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.