The Use of tDim in CR3BPSystem

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?

Thanks!

Hi @DenisDurand

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.

Bryan

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.

Thanks luc…