Oh, I didn't know that. Then it seems my alternative is not actually an improvement but just a compromising for speed by scarifying some accuracy.
Any possible to achieve the same speedup but keep the accuracy in FastMath.pow
?
After some profilings, I found we can increase greatly the speed of Taylor propagation of TLE sets using SGP4 model. This is helpful in a Monte-Carlo simulation like a particle filter. I didn't test on other numerical Taylor propagators, but I GUESS the improvement will be similar. There may also be other operations that can be optimized for integers but I didn't dig into that much.
Modifications are made to org.hipparchus.analysis.differentiation.DSCompiler#taylor(double[], int, double...)
, I'm not sure if it's proper to submit an issue here since it's mainly related to TLE propagation...
* By replacing the `FastMath.pow` calling by a naive power for-loop, we can increase the speed of DSCompiler greatly.
* In my case: 6.14s --> 1.46s
*
* Specific modifications are:
* Modify `org.hipparchus.analysis.differentiation.DSCompiler#taylor(double[], int, double...)`:
* Change this (line 3316 in commit-ea873ba0df8c7a3705f251a27711ac4696aae84b):
* term *= FastMath.pow(delta[k], orders[k]) /
* CombinatoricsUtils.factorial(orders[k]);
* To:
* for (int jj = orders[k]; jj > 0; jj--) term *= delta[k];
* term /= CombinatoricsUtils.factorial(orders[k]);
Attached is an example I used to test the performance. Work_05_speedup_taylor.java
Sorry for the late reply, was busy catching the SciTech2022 deadline...
@bryan Thanks for the quick fixing. It works at my end now.
@luc @bryan Thanks for explanations of serialization in JAVA. I'm still kinda new to this but learnt a lot from your insights and sources. My situation is that I need to save data in MATLAB simply using the save
MATLAB command, which requires serialization being implemented. For this situation, I'm not sure if there is an alternative or workaround if all serialization support has been removed in the future, but for now everything just works smoothly!
Hi @bryan ,
Thanks for the quick fix.
Based on your explanation, I suppose the bug I reported has been solved.
I'm new to these two methods: writeReplace
and readResolve
during the serialization. I've got two further questions:
TLE
class to a ExtendedTLE
class. I guess I need to write my own write and read methods, correct?After I serialize a group of TLE sets to a file, when I try to load back the data, it gives the error that null
encountered.
The following line seems to be the problem, where the bStarParameterDriver
doesn't have a meaningful default value during the deserialization process.
// org/orekit/propagation/analytical/tle/TLE.java:192
private final transient ParameterDriver bStarParameterDriver;
After defining my own TLENoBStarDriver
class by only overriding the original getBStar()
method, the error had gone.
// add a private field
private final double bstar;
// include this in the constructor
public TLENoBStarDriver(String line1, String line2) throws OrekitException {
super(line1, line2);
this.bstar = this.getBStar();
}
// then override the super().getBStar()
@Override
public double getBStar() {
return this.bstar;
}
Is there any more "formal" way to fix it? And I don't need to adjust bStar in my work.