I’m having difficulty grasping the use of tDim in the CR3BP system. In the method CR3BPSystem.getRealAPV(), we find:
final double duration = apv0.getDate().durationFrom(initialDate) * tDim / (2 * FastMath.PI);
The method “durationFrom” returns seconds, and tDim is in seconds (or seconds per 2PI radians, making the presence of 2PI in the denominator more confusing), so would that not produce a “duration” in the units of seconds^2 (seconds squared), or worse: seconds^2 per 4PI^2 radians squared?
It looks like there is something wrong. First, there is an issue is in the Javadoc of the
CR3BPSystem#getTdim() method. the Javadoc says that
tDim is in seconds. However, according to the equation you highlighted, it can’t be in seconds. If
duration is in seconds (what it is expected to be), so
tDim must be in radians. However,
tDim equation in CR3BP model is given by
tDim = 2 * FastMath.PI * dDim / vDim;
dDim is in meters and
vDim in meters per seconds. So,
tDim is in seconds radians and
duration is in seconds^2.
What it is also strange is the multiplication per
2 * FastMath.PI because each time
tDim is used, it is then divided per
2 * FastMath.PI …
Unfortunately I’m not an expert of CR3BP model and I’m not able to say if it is normal or not… Maybe somebody with more expertise can help you better than me.
Mathematical background can be found on pages 24 and 25 of 1.
Thanks for the document, which I believe makes it clear that the normalized parameters are dimensionless, including duration. What I find awkward is that the normalized, non-dimensional duration is being used in conjunction with AbsoluteDate methods, so that AbsoluteDate instances don’t represent actual instances in real time, but are placeholders for the endpoints of a normalized duration. Am I seeing this correctly?
Yes you are right.
This is the reason why we have open issue 877.
But as this is an incompatible change, we cannot implement this before next major version,
which will be 12.0 and is not scheduled yet.