Hi Romain,
thank you for your review and your links !
I’ll keep you updated if i make other significant changes.
Best regards,
Vincent
Hi Romain,
thank you for your review and your links !
I’ll keep you updated if i make other significant changes.
Best regards,
Vincent
Hi there,
I was thinking. An important yet a bit obscure part of the short term counter model is the time interval of interest. In theory it needs to be small enough that the relative motion is indeed nearly rectilinear. However in practise for ease of computation it is extended out to infinity so that the integral becomes bivariate instead of trivariate, the argument being that the added contribution is negligible. This should be at least documented in the javadoc, but maybe also reflected via an attribute time interval? Actually several authors have proposed formulas to evaluate the critical length of the rectilinear validity. Coppola’s one is relatively simple and used by NASA CARA so it could be a good addition to Orekit.
Cheers,
Romain.
Hey Romain,
I will enhance the javadoc regarding the consequences of the nearly rectilinear encounter hypothesis as you suggest and look into Coppola’s formula to see how we could implement it.
Ideally, i would like to keep the current implementation of the several methods already there as it is so this may lead to the creation of a new package dedicated to this kind of model. What do you think ?
Best regards,
Vincent
Hi Vincent,
I was more thinking as having Coppola’s formula as a static method (or something of the sort) in the short term encounter model. The rationale being: it is true that if the user has already decided to use this model, they don’t need to estimate the time interval during which relative motion can be considered rectilinear. However if they wish to assess whether or not it is reasonable to apply this model on a particular case, they could compute this quantity and for example compare it to the orbital periods of the two objects, as if if the interval length is not negligible compared to them, it is probably not a good idea to use the 2D collision probability. Does that make sense?
Cheers,
Romain.
Alright, i did not understand it that way at first ! In that case that should be easy to implement and very informative to the user indeed. We could specify in the javadoc an order of magnitude of the ratio between the computed time interval and the shortest orbital period, between both objects, for the assumption to be reasonable ? I would say around 5% but you must have a more precise idea of said ratio ?
Cheers,
Vincent
Hi Vincent
I would actually refrain from giving specific values. Coppolas formula is just one among others. The rectilinear motion is just one assumption among the short term encounter model ones. And there is no consensus in the literature as to when to use it or not.
Cheers,
Romain
Hi Romain,
Alright, in that case i will specify that it is up to the user to determine if the assumption is valid or not given the output of the method and the orbital period of both objects.
Speaking of the method, i am currently implementing it inside the ShortTermEncounterDefinition
class as it seems more fit for the job (it already computes everything related to the conjunction). As it also serve as an input for the probability computing methods, I think it will make more sense to the user to get the duration before actually computing the probability.
As always, thank you for your insight !
Vincent
Hi everyone,
To keep you updated, I recently opened the issue #979 regarding the addition of this collision package and I’m planning to propose the following architecture (not everything is shown, but the essential features are presented) :
Thanks to the suggestion of @Serrof, I added a method in ShortTermEncounterDefinition
to compute Coppola’s estimation of the duration of the encounter. Unfortunately, I also planned on adding the Patera 2005 method (reference available here), but it is still failing on some tests so I will try to look into it.
A field version has also been started but I must finish other things before completing it. Hence, it will also be added later on.
Finally, I may try to use the StateCovariance
class instead of the simple RealMatrix
for the covariance but that is still to be determined.
What do you think ?
Hi @Vincent !
The architecture looks good.
I have a question, is it possible to have a link between the already existing class PocMethodType
and your new enum?
It could be interesting for people writting CDM using Orekit.
I think it is a really good idea!
Bryan
Hey @bcazabonne !
Thank you for your thoughts, i totally forgot that there was PocMethodType
, i’m going to make something similar to what is already done with LOF. We might get a null if the method is not implemented in Orekit yet.
Also, i’m going to add the possibility in StateCovariance
to change a frame to a LOFType
as if it was an inertial frame (no use of the jacobian as we recently added). This is how it is commonly done it seems.
Vincent
Hi @Vincent,
thanks again for your work!
Perhaps maximum probabilities (usually obtained by scaling covariance matrices or aspect ratios) deserve their own AbstractClass/Interface?
On another note, I understand from our offline discussion that you dropped Foster because Hipparchus does not have multivariate integration scheme. While I do not mind ditching this historical, brute-force approach, we could definitely benefit from N-D integral computations, so maybe it is worth opening an issue on Hipparchus’ repo.
Cheers,
Romain S.
Hi @Serrof, thank you for your thoughts and it should be me thanking you for your help on this.
Regarding maximum probabilities, I’m not sure if we really need another interface and/or abstract as the covariance scaling could be done when creating an instance of ShortTermEncounterDefinition
or even with StateCovariance
(by adding a scale() method perhaps ?). However, if you feel that it should be done then your wish is my command !
Indeed, it is definitely something that should be in Hipparchus and could be helpful for many other things in the future. I’ll do it asap.
To keep everyone updated and as @Serrof said, the Foster1992 method will unfortunatly dropped for now as i could not make the code clean enough with what is currently available in Hipparcus. However, i managed to fix Patera2005 so It’s really not a bad trade.
I’m currently implementing the recently added StateCovariance
instead of the previously used RealMatrix
.
I’ll keep you updated.
Cheers,
Vincent
I realized that if I want to implement StateCovariance
cleanly in the collision package, I must find a way to express the covariance in a custom encounter frame. Moreover, different encounter frame are used in the literature so the solution needs to be generic and simple.
To solve this, I propose the following :
I omitted the field version and all the existing LOFTypes but you get the point… The proposed solution would add a LOF
interface that would be implemented by the already existing LOFType
enum and by a new EncounterFrameType
class. This way :
StateCovariance
class would simply use LOF
instead of LOFType
but the methods would stay the same.ShortTermEncounterDefinition
class to output covariance in an encounter frame.I would like to hear your thoughts about this @Serrof @bcazabonne.
EDIT: I switched from an enum to a class for the EncounterFrame
as it depends on the instance.
Hi Vincent
Regarding covariance scaling (individual or combined objects), the thing is that as the name implies it is the maximum value over a domain (than can be bounded or not), analytically or numerically obtained. Same goes for the aspect ratio. And you can also vary the angle actually. So all in all there are many ways to compute maximum probabilities. I’m not super clear on Alfriend’s approach tho. Could you describe it please (here or in private message)?
About the local orbital frames, I’m afraid I’m not familiar enough yet with the StateCovariance class to give you a timely answer. I’ll try to get back to you soon.
Cheers,
Romain
Hi Romain,
If I understood it correctly, the relevant assumptions to go from Foster1992 to Alfriend’s formula that are the followings :
Then, to obtain the Alfriend1999Max probability of collision method, Alfriend multiplies the covariance by a coefficient KSquared = MahalanobisDistanceSquared / 2 which is found to be maximizing the value of Pc.
Do you have some papers where I could see other types of covariance scaling ? I’m still very lacking, so I’m afraid I will not see the problem as well as you do.
Take your time on the StateCovariance class, I’m going to post another slightly more detailed UML diagram about this.
Cheers,
Vincent
Hey everyone,
I have been polishing the collision package and I wanted to keep you uptaded on the current implementation of the collision package.
First, you’ll find below a (huge) uml diagram of the current implementation :
I’ve tried my best to keep it simple while showing all the links and associated functionalities.
I guess that the new significant addition is the implementation of the LOF
interface. This was needed to define custom encounter local orbital frames and use them inside StateCovariance
.
Also, I deeply modified, ShortTermEncounterDefinition
which can now accept user defined encounter local orbital frame. The user can also choose which collision object (primary or secondary) should be at the origin of the encounter local orbital frame.
I’m happy to tell you that everything is tested and I currently have a code coverage of 99%.
I would be happy to have some feedback on this as this is beginning to be quite something
Wish everyone a good weekend !
Cheers,
Vincent
Hi Vincent,
I don’t see Coppola’s formula for the time interval. Is that because the diagram was already too big (same question for the Field implementation of everything)? As they are several formulas out there it should probably inherit from some sort of interface or abstract class.
So in the end nothing made it to Hipparchus I presume? It’s a shame in my opinion as the short term encounter model has nothing orbital about it but I understand if it is too constraining.
About maximum probabilities, there are references for analytical ones (so also approximated and sometimes intimately linked to a given standard method) for example in K. Chan’s book, Klinkrad’s book or one of the paper of Alfano often cited for so-called dilution (I will edit this post with mode details about these citations). For numerical ones it’s less documented but I know for a fact that some operators use them. This is part of the problem about collision risk, everyone kind of does its own thing tho so it’d hard to come up with a generic framework.
Out of curiosity how do you think Monte Carlo approaches to probabilities would fit in within the current architecture?
Thanks again Vincent for all the work!
Cheers,
Romain.
Hi Romain,
You can see Coppola’s formula for the time interval in the methods of ShortTermEncounterDefinition
(computeCoppolaEncounterDuration). If other methods are needed, i think i will do as you say and make a specific class for this.
Unfortunatly the Field version will be implemented afterwards but don’t worry as I already started to work on it. I also wanted to have a more stable architecture of the basic version before translating everything into Fields.
If you think that other methods for maximum probability of collision deserve to be implemented then I will do as you suggest. The architecture shall be able to interface with them, i could also create a specific class for maximum probability of collision computing methods as you suggested some time ago.
Regarding your question about the Monte Carlo approach, i would have to think about it but it would be very interesting to implement it (we may even use fields for this !).
Thank you for your review as well
Cheers,
Vincent
My bad for not seeing Coppola’s formula!
And sorry for insisting on the Field version lol but this is a cornerstone of Orekit for me and it paves the way towards derivatives-based optimization, which leads again to maximum collision probabilities. As a matter of fact any standard method can be used in a numerical exploration over its continuous parameters to look for maximum values. Last but not least, maneuvers can be designed to optimize over a metric such as PoC. In short creating a so-called collision package is opening the Pandora box
Romain.
Don’t worry about that, I clearly agree that the Field version is undeniably needed. It will be implemented and used for maneuver optimization !
Have a nice week,
Vincent