I started trying out the new Collision package in Orekit on the development branch.
First of all, thanks a lot for the great effort to implement this! I think it is a really great addition to Orekit for everyone working on space flight safety! Very nice work!
I found that some of the unit tests fail using the default settings for the Patera2005 method:
the maxNbOfEval (maximum number of function evaluation when integrating) is by default 5000. To avoid getting “org.hipparchus.exception.MathIllegalStateException: maximal count (5000) exceeded” errors, I needed to set the maxNbOfEval to 10,000 or 50,000 in some cases.
the minimalIterationCount of the TrapezoidIntegrator (which I used for integration) is by default 3. With this value, in one case Patera2005 returned a Pc of 3.742e-28, whereas a Pc of 0.04932 was expected(!). By changing the minimalIterationCount to 5, I got the expected Pc of 0.04932.
Therefore, it seems that the default settings for maxNbOfEval and minimalIterationCount are not always suitable for computing the Pc. In particular, with minimalIterationCount = 3 the calculated Pc was completely off.
I attached the Patera2005 extended unit tests: one with default settings that fails and one with updated settings that succeeds. It should work on the latest development branch. Patera2005Test.zip (30.3 KB)
Since the probability of collision is an important parameter for collision avoidance decision making, it may be wise to change the default values of the two parameters for Pc calculations to avoid unexpected errors.
What do you think?
First of all, thank you very much for trying out the ssa package. The feedback you provide is essential to make this package usable.
I have set the default settings a long time ago but i remember that Patera2005 was quite tedious as i had to tweak the parameters to find the expected results…
I will gladly take your tests and add them as unit tests inside Orekit and try to refined these settings. I am going to open an issue about this.
Coming back to inform you that a merge request has now been opened. I wanted to thank you again for providing code in addition to reporting this issue, it saved me a lot of work (currently on a leave, so I have appreciated it a lot !).
When taking a look at one of the newly added CDM, i noticed that the relative velocity at TCA was very low (<1m/s). In fact, it is the case for every test in the CARA analysis tool repository. Hence, I have one concern:
Our method should not work in this kind of low relative velocity case but we do find the same results. I have tagged @Serrof to see if he could take a look at it.
At least, I think I now understand why we needed to increase the maximum amount of evaluation by one order of magnitude.
The data might be not suited for the 2D PoC, but you can still use it and compare numerical results. That’s just validation of the implementation, not the method. I mean we’re talking about Pc2D_Foster_UnitTest.m right?