Some troubles estimating RangeRate measurements from file

Orekit usage
1

Hello everyone!

Recently, I’ve encountered some troubles and I’m pleading for help if you don’t mind and have the opportunity. I tried to read some measurements into a List<RangeRate> list and then feed its elements into a BatchLSEstimator object. When I tried to run it, I just couldn’t wait for it to finish.

I thought it was some kind of performance issue on my side, so I ran the program again with a profiler. After some time, I stopped profiling, and the profiler told me that I was stuck in the getMeasurementsParametersDrivers method while trying to add drivers to parameters. I dug into the add method inside it, then dug into another add method, and got the following performance stats. I believe I’ve found a bottleneck in my program.

rangerate.zip (2.0 MB)

image
image1085×566 44 KB

Unfortunately, I have no idea what I did wrong. Could it be a flawed RangeRate creation or a poor BatchLSEstimator setup on my side?

I have attached a .zip containing my Gradle project, which uses Java 21, Orekit 12.2.1, and some other libraries (such as Lombok, Jackson, etc.). The program is supposed to read the measurements.json file from the resources.

I’d really appreciate any guidance or advice!
Thank you for your time!

2

@pascal.parraud would you mind taking a look? It may be similar to the issue you reported back then:

3

Dear @luc!

Are there any additional steps a user should take or things to track in order to properly initialize RangeRate objects for feeding them into BatchLSEstimator—beyond simply calling the RangeRate constructor? Maybe some driver initialization stuff?

I’d really appreciate any guidance or advice!

4

No, observed measurements objects are basically immutable, once constructed, nothing changes. What changes is the evaluation objects that are created on the fly as orbit determination attempts new values for the estimated parameters.

1 Like
5

Thank you for your advice!