[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] Roadmap for next version
Le 30/01/2015 13:34, Hank Grabowski a écrit :
> As far as major new architectural features I think this looks like a
> solid set. While there are some additional smaller features I can think
> of, none of them rise to that level. That is especially true if the
> last point about being able to use it in more complicated gravitational
> environments (Lagrange points were specifically mentioned, but I imagine
> Cis-Lunar propagation with high fidelity gravity models would also be
> available with that too.
>
> For me the biggest thing outside of features, but I would put at the
> same level of importance as the new features, I would consider
> investigating is performance. For certain things, like TLE propagation,
> it seems very fast. For others it seems that it can get stuck in a
> grind rather quickly. These may involve larger architectural changes
> since a lot of the time is probably spent in Apache Math not in the
> Orekit proper code. Some of it may be how we've designed the algorithms
> around the Apache Math code. Others could be inefficiencies in the
> Apache Math library itself.
You are right, we should have a pass on performances. We mentioned it
below with respect to switch from interpolation to extrapolation using
the higher orders derivatives we now have for frames transforms, but it
would be worth looking in many other parts for performances bottlenecks.
best regards,
Luc
>
> Hank
>
> On Wed, Jan 28, 2015 at 10:04 AM, MAISONOBE Luc <luc.maisonobe@c-s.fr
> <mailto:luc.maisonobe@c-s.fr>> wrote:
>
> Hi all,
>
> Now that 7.0 is finally out, it is time to think about next version.
>
> Here are some of the thoughts from the CS Toulouse team. We would like
> to discuss about it and hear about other ideas from the rest of the
> Orekit community.
>
>
> Orbit Determination
> -------------------
>
> This is the evergreen lacking feature in Orekit, which corresponds
> to issue number 1 in our tracker
> <https://www.orekit.org/forge/__issues/1
> <https://www.orekit.org/forge/issues/1>>.
> There is already a contribution from Telespazio in the Orekit labs
> <https://www.orekit.org/forge/__projects/orbit-determination-__telespazio-s-contribution
> <https://www.orekit.org/forge/projects/orbit-determination-telespazio-s-contribution>>,
> but it needs some work to be merged into Orekit core (design is not in
> line with Orekit standards, measurements types are not object
> oriented, ...).
> We know several other users did develop their own orbit determination
> systems (I am aware of at least four other implementations), but
> none have been
> contributed to Orekit.
>
> We think some low level building blocks should be made available in
> Orekit
> so users can easily create full-fledged orbit determination systems.
> We already
> have some of these blocks. One such block is the full integration of
> state
> transition matrices as well as partial derivatives of state with
> respect to
> model parameters in the numerical propagator (implemented using
> variational
> equations). Another block is the least squares adjustment of initial
> orbit
> used in propagator conversion. It would be nice to also provide a
> proper Measurement
> interface with several Orekit-provided implementation for
> traditional measurement
> types (range, range-rate, angular, 3D point) and perhaps more exotic
> ones (double-range
> turn-around measurements, angular measurements of ground references
> extracted from
> on-board remote sensing, ...). It should be possible to include
> biases at different
> levels (for example at ground-station level where it would be
> different for all ground
> stations or at spacecraft level where it would be shared among all
> measurements of
> the same type). It would also be nice to be able to go through
> maneuvers and even
> to calibrate maneuvers. Perhaps loading CCSDS tracking data messages
> (CCSDS 503.0-B-1)
> should be included too, just as we already support other CCSDS
> standards.
>
> Of course, the goal is not to implement everything up to
> mission-specific loading of
> meta-data like special measurements formats, calibration or
> pre-processing features,
> but only to provide at Orekit level the general purpose parts and
> standard-compliant
> parts with some high-level API.
>
> We would like to have orbit determination for both the numerical
> propagator and the
> DSST propagator which is now complete.
>
> Low-thrust
> ----------
>
> Low-thrust was not already registered in the issue tracker, but we
> are considering
> it right now. Modeling the thrust itself is not a problem at all, it
> is just another
> force model with some specificities. What is more challenging is
> computing a maneuver
> that allows to reach some predefined target: a longitude rendez-vous
> for low thrust
> orbit raising for geostationary LEOP, a planet or asteroid fly-by
> for interplanetary
> scientific missions. This is completely different from traditional
> maneuvers which
> can be computed by an initial guess using analytical models and
> impulse maneuver
> approximation followed by numerical optimization. Computing useful
> low-thrust maneuvers
> relates to optimal control with both the attitude law and the thrust
> amplitude being
> part of the control law to be found. Depending on the case, the
> amplitude may be continuous
> or simply on/off as in bang-bang control which often arise in
> minimum-time problems.
> About 20 years ago, the method of choice for solving this kind of
> problems were
> indirect methods, with a Two-Point Boundary Value Problem and using
> shooting methods
> to solve it. It seems these methods are droped and the current trend
> is more about
> direct method and more precisely Ross-Fahroo pseudospectral methods.
>
> Neither methods are available in Apache Commons Math nor in Orekit,
> so we would need
> to add them. I first thought about a three stage process,
> implementing first a TPBVP
> solver in Apache Commons Math, then some interfaces for optimal
> control still in
> Apache Commons Math, and last using this framework in Orekit. I know
> think it would be
> more efficient to directly look at Ross-Fahroo for the low-thrust
> problem, i.e.
> merge all three steps into one for a specific problem and not the
> general case.
>
> Acceleration clean-up
> ---------------------
>
> This task belongs more to day-to-day maintenance of the library, but
> it is related
> to the API, so worht discussing here. During the vote for the
> release of version 7.0
> on the PMC list, there were some issues about the current API as it
> mandated providing
> dynamics in some places were it looked kinematics only should have
> been sufficient. Some
> last minutes changes were made to solve this, but it was not
> possible to fix all issues.
> We clearly missed some feedback a few months ago when the feature
> was introduced. The focus
> shifted to solving the Eackstein-Hechler problem but the feature API
> was probably neglected.
> We think it is worth asking again to the community to review the
> current API and to discuss
> all together about what to do.
>
> A foolow-up of this discussion should be to use the new feature more
> thoroughsly in the
> library.
>
> One expected benefit would be to improve again some frame
> transforms. We are
> already quite fast as we use interpolation in the most costly
> transforms (mainly nutation
> computation with the MHB2000 model for IERS conventions 2003 and
> 2010), but in some cases
> this is not sufficient. For example in some specific use in the
> Rugged terrain-to-sensor
> mapping library, we observed that we spent quite some time in the
> interpolator, and we
> had to use another layer and replace n-points interpolation with
> 1-point extrapolation with
> a higher density sample as extrapolation (i.e. method shiftedBy())
> was faster than
> interpolation. Adding angular acceleration in the samples at
> FramesFactory level would
> allow us to retrofit this trick into Orekit for everyone's benefit.
>
> Another expected benefit would be to allow propagating oribts in
> non-inertial frames
> or to integrate orbits in frames not located at central body,
> included cases without
> a main central body (Lagrange points ...).
>
> Infrared and Albedo radiation pressure
> ------------------------------__--------
>
> Two force models identified a long time ago are still missing in
> Orekit: infrared
> radiation pressure from central body and albedo radiation pressure
> from central body.
> It would be nice to finally include them. Beware that this can
> ranged from very simple
> to more complex depending on the model used.
>
>
> What does the community think about thess tasks? Do some of you
> already have something
> that could be contributed to Orekit? Would some of you want to work
> on this?
>
> best regards,
> Luc
>
>