Limited AdditionalStateProvider

Orekit development
1

Hello and happy new year!

I need to store a string (a metadata of my spacecraft) that evolves in time, while propagating.

I exactly need the behavior of AdditionalStateProvider but with a String (or even more complex object) instead of double values

Do you think we could extend the actuel AdditionalStateProvider to a parameterized GenericAdditionalStateProvider with methods as follow :

T getAdditionalState(SpacecraftState state);

Orekit could still defined the already well-known AdditionalStateProvider implementing GenericAdditionalStateProvider<Double>.

Best regards,

Anne-Laure

2

I think this would be a great addition!

1 Like
3

Hi Anne-Laure,

Why not. However, a few suggestions:

  • as far as naming is concerned, the word “state” should be left for actual continuous variables, I think the generic thing could be “info” or something
  • let’s not add any more lines of code in (Field)SpacecraftState and use class composition for instance to manage the additional stuff

Cheers,
Romain.

1 Like
4

My opinion is a bit biased since we discussed this afternoon with Anne-Laure about this new feature.
AdditionalStateProvider is a very appreciated feature of Orekit. Extending its purpose is a very nice idea.

Maybe we can directly modify the existing AdditionalStateProvider class? The update will be straighforward for user (i.e. just add <Double> to their implementation). Therefore:

  • I don’t think that the name of the classe shall be modified. A “state” could be represented by a double value, a String, etc. In fact “state” is already a generic word.
  • Any additional code will be added in {Field}SpacecraftState. The idea is just to add a generic type to the interface

Bryan

5

In the context of dynamical systems, state is kind of a keyword, it’s the vector of dependent variables. The case of user defined ones is already covered by the DoubleArrayDictionnary, and you can’t make that generic.

SpacecraftState has 18 constructors :sob:
I just think this deserves some brainstorming

Cheers,
Romain.

6

Sorry… I wanted to say “no additional code” :sweat_smile:

7

Yes, we are aware of the current complexity of SpacecraftState. Romain did raise alerts several times about this, and I agree with him.

I have no clue how to handle this, but some redesign is probably needed. We really need to think this through for 13.0.

I would suggest something: all developers start by thinking of the pros and cons and if they find they can suggest a new architecture, splitting classes, using polymorphism, using builders… Then in one or two weeks, we set up a live brainstorming online (not really an Orekit Talk, but using similar means), in order to decide something collectively.

And I really like the idea of generalizing additional data (state or other name, I don’t care).

8

Hello everyone,

I like this suggestion, the more we wait to refactor SpacecraftState, the more it will be difficult to do so.

I would like to add that if we come up with a solution that involves lots of changes, i think that it should wait for 14.0 then.

Also +1 for generalizing AdditionalStateProvider.

Cheers,
Vincent

9

+1 for generalizing the AdditionalStateProvider class too

10

Issue created : Generalize AdditionalStateProvider (#1645) · Issues · Orekit / Orekit · GitLab

1 Like
11

Thank you a lot for your replies : I am glad for the enthousiasm of each of you :heart:!

I would love to code this feature but I am a little bit overloaded at that time… we aggreed with @bcazabonne that he will contribute.

Thank you @bcazabonne :smiley:

1 Like
12

I like your idea Luc I will try drafting something.

Btw is this an Airbus contribution or a personnal one @bcazabonne?

Cheers,
Romain.

13

Airbus contribution

1 Like
14

Also, I can propose a MR next week on this new feature and we can use it as starting point to discuss

2 Likes