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;
where 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.
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.