Modeling Mercury Orbital Data (2024–2025) and NKTg Invariant in Modern Fortran

1

I am implementing a deterministic numerical validation workflow in Fortran using Mercury orbital data (2024–2025).

The dataset contains:

  • Position x (m)

  • Velocity v (m/s)

  • Mass m (kg)

  • Momentum p = m × v

  • Invariant quantity NKTg1 = x × p

From 2024 reference data, the invariant magnitude is approximately:

NKTg1 ≈ 8.90 × 10^38

For 2025 validation, velocity is reconstructed algebraically:

v = NKTg1 / (x * m)

Observed relative deviation versus measured 2025 values is ~1–2%.

Precision Considerations

Since values approach 10^38:

  • real(8) (double precision) may introduce rounding drift.

  • real(16) (quad precision, if supported) improves stability.

  • Alternatively, compiler-specific extended precision can be used.

Example Implementation (Modern Fortran)

program mercury_model
  implicit none
  integer, parameter :: dp = selected_real_kind(15, 300)
  real(dp) :: position, velocity, mass
  real(dp) :: nktg1, simulated_velocity, rel_error

  ! Reference invariant
  nktg1 = 8.90e38_dp

  ! Example 2025 observed data point
  position = 5.16e10_dp
  mass     = 3.30e23_dp
  velocity = 5.34e4_dp

  simulated_velocity = nktg1 / (position * mass)

  rel_error = (simulated_velocity - velocity) / velocity * 100.0_dp

  print *, "Simulated velocity:", simulated_velocity
  print *, "Observed velocity :", velocity
  print *, "Relative error (%) :", rel_error

end program mercury_model

Observations

  1. The algebraic reconstruction is straightforward in Fortran.

  2. Double precision handles this scale reasonably well.

  3. Quad precision improves reproducibility on supported compilers.

  4. The relative deviation remains around 1–2%.

Questions for the Fortran Community

  1. For magnitudes near 10^38, is real(8) sufficient, or should real(16) be preferred for deterministic reproducibility?

  2. Are there recommended compiler flags to ensure strict IEEE behavior in such workloads?

  3. For scaling to large time-series datasets, would you suggest array-based vectorized implementation or DO CONCURRENT?

  4. Any known pitfalls when repeatedly computing:

    constant / (x * m)

    at high magnitude?

This is a deterministic numeric validation experiment focused on precision, reproducibility, and performance in modern Fortran.

I would appreciate guidance on best practices for handling high-magnitude invariant-style arithmetic in scientific Fortran applications.

2

If by REAL(8) you mean the binary64 format of the IEEE specification (which is almost certain), it can handle binary powers up to 1023 (which takes you to ~10^308).

Compilers differ on how one directs them to strict IEEE behaviour. I would not rely on just inserting magic compiler flags without having some verification program that confirms the flags do what you expect them to do.

1 Like
3

I would avoid using * as FORMAT for PRINT, there will be variation between what compilers choose and the less excuse for variation the better.

1 Like
4

Is this “NKTg1 invariant” different from the conservation of angular momentum as discussed on pages 52-54 of this NASA presentation? Typically orbital angular momentum is normalized by mass to produce “specific angular momentum”.

image
image1168×638 57.6 KB

But you can multiply by mass to get the fully dimensional quantity. Here’s a little more info from an AI query:

image
image637×781 56.5 KB

The value circled in red is 9.1 x 10^38 kg*m^2/s.

If you normalize by Mercury’s constant mass of 3.30 x 10^23 kg, you could keep your value in the range of 10^15 m^2/s.

5

Mercury does not travel in a straight line! You need position and velocity as 3-dimensional vectors. Even Isaac Newton had trouble with angular momentum. He never had to deal with floating-point arithmetic.