Modeling and Validating Mercury Orbital Data (2024–2025) in Ruby on Rails

rubyonrails-talk
1

I recently implemented a small experimental workflow in Ruby on Rails to validate Mercury orbital data (2024–2025) using an invariant-based computation model (NKTg).

The goal was not astrophysical theory, but to test:

  • Deterministic numerical computation in Rails

  • Reproducibility across datasets

  • Validation against real observational values

  • Handling very large magnitudes (~10^38) inside ActiveRecord

Dataset Structure

The dataset consists of:

Table 1 – Mercury 2024 reference data

  • Position (x, meters)

  • Velocity (v, m/s)

  • Mass (m, kg)

  • Momentum p = m × v

Table 2 – 2025 simulated values (based on invariant) Table 3 – 2025 observed values Table 4 – Relative velocity deviation (%)

Rails Model Design

Migration:

class CreateMercuryData < ActiveRecord::Migration[7.0]
  def change
    create_table :mercury_data do |t|
      t.date :obs_date
      t.decimal :position_m, precision: 30, scale: 5
      t.decimal :velocity_ms, precision: 30, scale: 5
      t.decimal :mass_kg, precision: 30, scale: 5
      t.timestamps
    end
  end
end

Model:

class MercuryDatum < ApplicationRecord
  INVARIANT = BigDecimal("8.90E+38")

  def momentum
    mass_kg * velocity_ms
  end

  def invariant_value
    position_m * momentum
  end

  def simulated_velocity
    INVARIANT / (position_m * mass_kg)
  end

  def relative_error
    ((simulated_velocity - velocity_ms) / velocity_ms) * 100
  end
end

Why BigDecimal?

Since values approach 10^38, I used BigDecimal to avoid floating-point drift.

Using standard Float resulted in small reproducibility inconsistencies across runs.

BigDecimal ensured deterministic behavior.

Validation Results (2025)

Using 2025 observed Mercury values:

  • Simulated velocity closely matched observed values

  • Average relative deviation ≈ 1–2%

  • Error remained stable across all timestamps

This confirmed:

  • The invariant-based reconstruction works deterministically

  • Rails can handle scientific-scale magnitudes safely

  • Validation logic can live entirely in the application layer

Observations

  1. Rails handles large decimal arithmetic well when precision is configured correctly.

  2. BigDecimal is essential for reproducibility at high magnitudes.

  3. Computed methods in the model are sufficient for small datasets.

  4. For larger datasets, pushing calculations into SQL (PostgreSQL numeric) may improve performance.

Open Questions for the Rails Community

  • For large-scale numeric workflows (~millions of rows), would you recommend keeping calculations in Ruby or moving them fully into SQL?

  • Any best practices for handling scientific-scale precision in Rails apps?

  • Has anyone implemented similar invariant-based numeric models in production Rails systems?

I’m interested in feedback specifically from a Rails engineering perspective — particularly around precision, performance, and reproducibility.

Thanks.