Discussing addition of a collision package to Orekit

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 :slight_smile: !

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 :
LOF

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 :

  • The StateCovariance class would simply use LOF instead of LOFType but the methods would stay the same.
  • Users could easily add new definition of encounter frame.
  • This would allow my ShortTermEncounterDefinition class to output covariance in an encounter frame.
  • This would not break any API if I’m correct.

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 :

  • Both collision object are in circular orbits so their velocity are identical in norm (eq 14 in his paper).
  • The final approximation is that the probability density function is constant over all the collision circle (eq 18 in his paper)

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 :sweat_smile:

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 :smile:

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 :joy:

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

Hey everyone,

So I have now implemented the field equivalent for probability of collision methods and added their associated tests. You’ll find below an updated UML diagram of the current implementation :


I tried to simplify the links and only displayed what’s interesting. For example, only the Serra2015 class has visible links to ProbabilityOfCollision and FieldProbabilityOfCollision.

What are your thoughts ?

Cheers,
Vincent

UPDATE: The Serra2015 class has been renamed Laas2015
UPDATE 2: The StateCovariance class already has a Field version which is used in FieldShortTermEncounter

Hi Vincent,

Thank you for all this, especially the Field part!

I’m only thinking now about one thing: sometimes the short term encounter model is extended to a non spherical combined object typically polygonal (and some methods can actually handle that). So I suggest we make it extra clear in the documentation that it is not the case for ShortTermEncounterDefinition. And leave the door open for future contributions.

As the reviewer of the merge request I’ll take a closer look at the code, but folks this is maybe your last chance to make remarks or ask for stuff.

Cheers,
Romain.

Hi Romain,

I agree, I’m going to update the javadoc so this is extra clear.

Thinking about future contributions about polygonal objects, It bugs me a little as a change would mean breaking the API and so, having to wait for another major release which happens once/twice a year. I’m going to think about it and if I can easily implement a solution, then I will do so.

To everyone else, I opened a merge request yesterday that will add the collision package. We still have to wait for an update in Hipparchus to be able to implement it but it should not be a huge deal (fieldification of Erf and Gamma classes).

Also, I’m taking this opportunity to post a brief document which explains how the Patera2005 was implemented, as we’re using different inputs from the original method :
Patera_2005_implementation_in_Orekit.pdf (61.4 KB).

Cheers,
Vincent

Hi all,

Updating this thread to inform you that the collision package will be added soon. I’m making some final changes and reviews of the code so if you have any requests, now is the time to make them !

Cheers,
Vincent