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.