Hi all,
Following discussions with Maxime, it would appear that TimeSpanDragForce is obsolete? Basically now DragForce can achieve the same features. If so it should be deprecated.
Cheers,
Romain.
2 Likes
I think TimeSpanEstimatedModel may fall under the same deprecation.
We can keep the tests though, for legacy and examples of how to build a TimeSpanMapped-ParameterDriver
Hello,
By looking at the documentation of DragForce I see nothing that would suggest the possibility of including multiple Cd arcs. Could you give me an example of how to set it up? I use TimeSpanDragForce in my codes, so I’d love to know how to replace it if the class ends up getting deprecated.
I guess it is because the parameter drivers themselves can be made time dependent.
Yes, that’s exactly that.
The only difference I see is that TimeSpanDragForce allows to change the drag coefficient AND the area for each time-span
This will not be possible with time time-dependent drivers, the area won’t be changeable.
So this will be a regression, but is it that really a problem?
I don’t have any examples right now but don’t worry the change won’t happen soon (it requires a major version) and we will provide examples, at least in the tests.
Now if you think the model should stay it can also be kept. But the logic behind will probably be changed, meaning, instead of building the model with DragSensitive, it will be built with double.
What would you prefer @Emiliano ?
Oh, I wasn’t aware of this, interesting. Thanks!
Changing the area is convenient if we want to represent a change in attitude mode without going through the hassle of setting up a BoxAndSolarArraySpacecraft object and an AttitudeSequence, so I think it’s probably something worth keeping, just like having the possibility of providing an overriding attitude profile for maneuvers is convenient to avoid setting up the entire sequence.
That being said, I don’t generally change the area when using TimeSpanDragForce, just because I prefer to absorb the changes in attitude in the Cd itself, but I can see why someone would go for the area approach instead. For my use cases, the option of replacing DragSensitive with a double will work fine just fine and simplify the code, so I’m definitely ok with the change. Wouldn’t it be possible to add a new constructor to include this implementation?
Anyway, thanks for all the info. I’ll definitely take a look at the tests as soon as this gets shipped 
Hi Emiliano,
I think you could implement your own DragSensitive wrapping a base one to multiply by a factor the original dragAcceleration. I guess we could add this mechanism natively in the library.
Cheers,
Romain.
Hello, I have a doubt about a potentially missing functionality after TimeSpanDragForce got deprecated. Since TimeSpanDragForce takes multiple DragSensitive objects, we get a drag coefficient ParameterDriver for each of them. This allows to select which CDs we want to estimate and which ones we don’t.
With the new implementation, as far as I can see, there’s only one drag coefficient driver, which underneath is split into multiple segments with TimeSpanMap. So it seems like we can now only choose to estimate all of them or none of the arcs.
Am I missing something? Is there a way to specify which arcs to estimate with the new implementation?
Hi @Emiliano,
I think you are right indeed, that is something we didn’t account for.
Not to my knowledge, do you think this feature is needed/essential?
Maxime
Hello @MaximeJ,
I don’t know if I would call it essential, but I have used it in the past, when running an OD on a very long arc which included a big gap in the GNSS data. It allowed me to get an OD where the CDs were all more or less stable and where the solver did reach convergence.
Ok, I don’t know what other people on the forum think but my opinion is that we should provide something to cover this use case.
I don’t think that adding another TimeSpanMap in ParameterDriver is a good idea since there are already two (for names and values) that are supposed to be consistent with each other (same dates).
Maybe we should add an internal object containing (name, value, and flag for estimation) and use a TimeSpanMap of this object in ParameterDriver instead.
Any thoughts on this?
Cheers,
Maxime
Looking further at ParameterDriver, I think the current design is awkward (and I think I am the one to blame as I was the one who told MĂ©lina to do it this way at the time 
).
Perhaps having separate ParameterDriver and TimeSpanParameterDriver would be better.
I was considering that too but then it will require to either multiply classes (single and multiple drivers) or use generics declaration on the parameter drivers. This will introduce a lot of complexity, I think.
In any case, @Emiliano, could you please open an issue on the forge regarding your use case that will not be available anymore when TimeSpanDragForce is removed ?
Hi all,
I think we should postpone any modifications of ParameterDriver for Orekit 14.0 otherwise 13.0 is never going to be released.
Why not just remove the deprecation of TimeSpanDragForce until then?
Cheers
Romain.
I don’t think that adding another TimeSpanMap in ParameterDriver is a good idea since there are already two (for names and values) that are supposed to be consistent with each other (same dates).
Couldn’t a TimeSpanMap of ParameterDriver solve this? It would return to a state similar to TimeSpanDragForce, with multiple separate parameters being estimated, allowing the user to choose which ones to estimate. Of course I don’t really know much about the low-level implementation (since I very rarely look at it 
), so I don’t know if this would clash with methods from other classes relying on having direct access to the parameter and not the map.
In any case, @Emiliano, could you please open an issue on the forge regarding your use case that will not be available anymore when TimeSpanDragForce is removed ?
Done, it’s here
Agreed on both points.
Yes but then we would have to add classes like TimeSpanMapDragSensitive, TimeSpanMapRadiationSensitive etc. One of the purpose of using aTimeSpanMap in the ParameterDriver class was to provide a built-in function to change the values of the drivers depending on the dates.
Thanks!
Did somebody opened an issue about removing the @Deprecated annotions of TimeSpanDragForce?
Temporary restoring this class for 13.0 would be greatly appreciated!
Also a +1 to introduce in 14.0 a TimeSpanParameterDriver class. Fixing or solving parameters according to time span can appreciated in other applications, like maneuver estimation.
Bryan
Hi Bryan,
I’ve already removed the annotation.
Cheers,
Romain.
Great! Thank you!