`calculate_planets`: ~18″ p95 drift vs VedicRishi where another Swiss Ephemeris binding agrees to ~1″ — need help understanding the difference

[Hari-Bonda]

Hi, thanks for shipping this library — the Wasm-first packaging fits Cloudflare Workers perfectly so we adopted it across our sidereal-astrology site. We're now in a parity audit against VedicRishi (json.astrologyapi.com) and a second open-source Node.js Swiss-Ephemeris binding, and we'd love help interpreting the results.

What we ran

• @fusionstrings/panchangam v0.2.1 (same numbers on v0.2.0)
• 200 random cases, dates 1925–2025, 30 cities (lat −40° to +60°, lon −150° to +150°), 5 ayanamsa modes
• Same case set sent to:
  1. @fusionstrings/panchangam via p_julday(year, month, day, utc_hour, 1) → calculate_planets(jd, mode)
  2. VedicRishi /v1/planets/ — industry baseline used by most KP/Vedic apps
  3. A second Node.js Swiss-Ephemeris stack — mivion/swisseph (canonical Node binding to the upstream Swiss Ephemeris C library, v0.5.17) wrapped via rish-0-0/astroreha v1.1.5. Different binding to the same Swiss Ephemeris algorithm.

Results — Lahiri ayanamsa (mode 1), 200 cases, p95 |Δ| in arcsec

Planet	panchangam vs VR	mivion/swisseph vs VR	panchangam vs mivion/swisseph
Sun	18.5″	1.9″	19.0″
Moon	41.5″	28.9″	33.1″
Mars	18.1″	3.2″	19.8″
Mercury	18.8″	6.4″	22.9″
Jupiter	17.8″	0.9″	18.0″
Venus	18.5″	4.2″	19.7″
Saturn	18.1″	0.5″	17.9″
Rahu	17.9″	0.1″	17.8″
Ketu	17.9″	0.1″	17.8″

Means hover near zero for both implementations — so this isn't a systematic ayanamsa offset, it's spread. Pattern is identical for Raman (mode 3) and Krishnamurti (mode 5). True Citra (mode 27) shows a separate +55″ systematic offset which is a different issue (likely different True-Citra formula).

The pattern that surprises us: the other Swiss Ephemeris implementation reproduces VedicRishi to 0.1″ on Rahu/Ketu (mean node) and 0.5–1″ on Saturn/Jupiter, while @fusionstrings/panchangam shows ~18″ p95 on every planet. Whatever is causing the spread looks specific to your library, not Swiss Ephemeris in general.

Minimal reproducer

import { p_julday, calculate_planets } from '@fusionstrings/panchangam';

// 2026-05-11 00:00:00 IST → UT 2026-05-10 18:30
const jd = p_julday(2026, 5, 10, 18.5, 1);
const sun = calculate_planets(jd, 1).find(p => p.name === 'Sun');
console.log(sun.longitude);
// panchangam   → 25.97303°  (Aries 25°58'23")
// VedicRishi    → 25.97139°  (Aries 25°58'17")  Δ = +5.9″
// `mivion/swisseph` stack → 25.97142°            Δ = +0.1″ from VR

Our current workaround (Moon)

While debugging, I added a manual correction in our wrapper: after calling calculate_planets, I shift the Moon longitude by +(ΔT_seconds × 0.549″/sec) / 3600° using a local IERS ΔT table (1900–2100). With this patch:

• Without it: Moon mean Δ vs VR ≈ −11″, p95 ≈ 39″, max ≈ 60″
• With it: Moon mean Δ vs VR ≈ +15″, p95 ≈ 41″, max ≈ 51″

So the correction moves us in the right direction (closes a ~26″ gap) but overshoots by ~14″ — implying the real internal ΔT use inside calculate_planets is between "treats jd as TT" and "treats jd as UT", or the correction needs a different scaling. The mivion/swisseph stack matches VR without any wrapper-level patch — its swe_calc_ut applies ΔT internally and the output is correct out of the box.

For Sun / Mercury / Venus / Mars / Jupiter / Saturn / Rahu we apply no manual correction — the values come straight from calculate_planets. That's the column shown as "panchangam vs VR" in the table above (still ~18″ p95).

Our approach so far

1. Time conversion: parse local birth time + timezone offset → UTC decimal hour → p_julday(year, month, day, utc_hour, 1). Handles day wraparound when UTC crosses midnight.
2. Planet positions: calculate_planets(jd, mode) straight out, no transformation, used as-is for Sun/Mars/Mercury/Venus/Jupiter/Saturn/Rahu.
3. Moon: manual arc-second correction (described above) before consuming the longitude.
4. Ketu: derived as Rahu + 180° (mod 360).
5. KP custom variants (kp_new, kp_straight_line, kp_kullar): compute the panchangam Lahiri sidereal output, then add a custom adjustment (Lahiri_ayanamsa − our_KP_ayanamsa). Works for non-Rahu planets; for Rahu it produces a mean-node value (matches the mivion/swisseph stack) while VedicRishi returns true-node for KP_NEW — that's a known third-party divergence we accept.
6. Outer planets (Uranus / Neptune / Pluto): use calc_ut(jd, SE_URANUS, …) directly, subtracting the ayanamsa value. This path works correctly — agrees with VR to within ~1″ on those.

What we'd love help with

We need our charts to reproduce VedicRishi-style output to within ≤1–2″ across these five ayanamsas. We're stuck because:

1. We can't tell if we're calling calculate_planets wrong (TT vs UT semantics on the JD argument), or if the spread is inherent to your wasm build.
2. The Moon workaround works directionally but overshoots — we'd like the underlying mechanism documented so we can apply the right correction (or have the library apply it).
3. Outer planets via calc_ut agree with VR to ~1″, but calculate_planets for the main 7 shows ~18″ — strongly suggests calculate_planets uses a different internal path.

Specific questions:

1. What does calculate_planets(jd, mode) treat jd as — TT or UT? (i.e., does it call swe_calc or swe_calc_ut internally?)
2. Which Swiss Ephemeris data set is the wasm compiled against — DE441 / Moshier / built-in? This affects last-arcsecond agreement.
3. Is the ~18″ spread expected, or does it indicate a config issue on our side?
4. Could you expose a calc vs calc_ut distinction so downstream apps can pick the convention that matches their reference software?
5. For mode 27 (TrueCitra) — which Spica/Citra formula is implemented?

I can share the full CSV (200 cases × 5 ayanamsas × all planets, signed Δ vs each reference) if it helps reproduce. Thanks!

[Hari-Bonda]

Update — root cause found, workaround works

We did some more digging directly into panchangam.js and panchangam.d.ts, plus side-by-side probes against the mivion/swisseph stack. Sharing what we found so it might save you debugging time.

Finding 1: calculate_planets(jd, mode) is equivalent to swe_calc(jd, planet, tropical) − swe_get_ayanamsa(jd)

Specifically:

• It treats the input jd as TT, not UT (i.e., it's wrapping swe_calc, not swe_calc_ut — no ΔT applied).
• It uses naive ayanamsa subtraction, not the Swiss Ephemeris SEFLG_SIDEREAL flag (which does a proper 3D rotation in the ayanamsa reference frame).

Verified by exact-arithmetic check at JD = 2461171.27083333 (2026-05-10 18:30 UT):

• panchangam.calculate_planets(jd, 1) Sun: 25.8815444867°
• mivion.swe_calc(jd, SUN, tropical): 50.1068120517°
• mivion.swe_get_ayanamsa(jd): 24.2252675682°
• Manual subtraction: 50.1068120517 − 24.2252675682 = 25.8815444835°
• Match within ~0.01″ (numerical noise) ✓

Both behaviors compound to give the ~18″ p95 drift vs VedicRishi we reported in the issue.

Finding 2: calculate_planets has a useful side-effect — it sets the global sidereal mode

When we tried calling calc_ut(jd, planet, SWIEPH | SPEED | SIDEREAL) directly, we got Fagan-Bradley values (≈3179″ off Lahiri) because the underlying Swiss Ephemeris state still had sid_mode = 0 (the default).

But if we call calculate_planets(jd, mode) first and discard the result, the global sid_mode is set internally, and subsequent calc_ut(..., SIDEREAL) calls return the right ayanamsa frame.

So the workaround is a tiny two-step:

import { p_julday, calculate_planets, calc_ut, Constants } from '@fusionstrings/panchangam';

const jd = p_julday(year, month, day, utcHour, 1);
calculate_planets(jd, mode);                                              // prime sid_mode (discard return)
const FLAGS = Constants.SEFLG_SWIEPH | Constants.SEFLG_SPEED | Constants.SEFLG_SIDEREAL;
const sun = calc_ut(jd, Constants.SE_SUN, FLAGS);                         // sidereal-correct

Result after applying the workaround (same 200 cases, all 5 ayanamsas)

Planet	calculate_planets p95 vs VR	calc_ut + SIDEREAL after priming	mivion/swisseph p95 vs VR
Sun	18.5″	2.3″	1.9″
Mars	18.1″	1.5″	3.2″
Mercury	18.8″	3.8″	6.4″
Venus	18.5″	2.7″	4.2″
Jupiter	17.8″	0.5″	0.9″
Saturn	18.1″	0.4″	0.5″
Rahu	17.9″	0.1″	0.1″
Moon	41.5″	31.0″	28.9″

The workaround closes the gap for every planet on Lahiri / Raman / Krishnamurti / KP New down to within a few arcseconds of both VR and mivion/swisseph. On a few cases we're actually tighter than mivion — nice.

What we'd love to see from the library

1. Documentation / clarification: it's surprising that calculate_planets is using swe_calc (TT input) and naive subtraction rather than swe_calc_ut + SEFLG_SIDEREAL. Is that an intentional API choice, or a bug worth fixing? If intentional, calling that out in the README would have saved us a day of investigation.
2. Expose swe_set_sid_mode: the global side-effect of calculate_planets is convenient but fragile (we have to remember to prime before every batch of calc_ut calls). A direct binding would let downstream code be explicit.
3. Fix calculate_planets itself (or add a flag/option) so it internally does swe_calc_ut(... | SEFLG_SIDEREAL). That would make the library match every other Swiss-Ephemeris-based KP/Vedic implementation out of the box — no workaround needed.

Remaining items (not blocked by the above)

• True Chitrapaksha (mode 27): still ~+55″ systematic offset vs VR even with the workaround. The swe_get_ayanamsa(jd) value for mode 27 itself differs from VR — likely a different Spica/Citra formula. Would still appreciate confirmation on which definition mode 27 implements.
• Moon p95 ≈ 31″: this is consistent across our workaround and mivion/swisseph and is dominated by lunar-acceleration / ΔT precision differences between Swiss Eph builds. Probably irreducible without using identical ephemeris data files.

[Hari-Bonda]

Follow-up — even simpler fix exists, but it depends on which VR endpoint you want to match

Quick correction to my previous comment. I went and checked which VedicRishi endpoint the legacy KP software ecosystem actually uses, and the picture is more nuanced than I made it out to be — VedicRishi exposes two endpoints that give different KP_NEW outputs for the same input, and our two candidate fixes each match one of them.

Same input, two different VR responses

Input: 2026-05-11 00:00 IST, Hyderabad (17.385°N, 78.4867°E), KP_NEW

Endpoint	Sun	Moon	Rahu	Internal method
/v1/planets	25.9713°	306.3120°	311.7159° (true Rahu)	calc_ut + SEFLG_SIDEREAL (proper 3D rotation)
/v1/kp_horoscope	25.9730°	306.3138°	311.1644° (mean Rahu)	calc_ut + naive tropical − ayanamsa subtraction

The legacy KP software ecosystem (and our -software-legacy page) uses /v1/kp_horoscope. The Rahu difference is the giveaway: kp_horoscope returns mean Rahu (matching every traditional KP software), while /v1/planets returns true Rahu.

Two equally-valid fixes

Variant D (calc_ut + SIDEREAL flag, after priming sid_mode via calculate_planets): ≤4″ p95 vs /v1/planets. Closer to modern Swiss Ephemeris convention but ~7″ behind every legacy KP display.

Approach B — much simpler — just shift the JD argument forward by ΔT / 86400 days when calling calculate_planets:

import { p_julday, calculate_planets } from '@fusionstrings/panchangam';

const jd = p_julday(year, month, day, utcHour, 1);
const deltaT_seconds = getDeltaT(year);                          // IERS table, e.g. 70s for 2026
const planets = calculate_planets(jd + deltaT_seconds / 86400, mode);

That's the whole patch. No calc_ut, no flag juggling, no swe_set_sid_mode. With this one-liner, on the canonical case above:

Planet	VR /v1/kp_horoscope	Approach B	Δ
Sun	Ar 25:58:23	Ar 25:58:22	−1.1″
Moon	Aq 06:18:50	Aq 06:18:49	−1.2″
Mars	Pi 29:41:33	Pi 29:41:32	−1.3″
Mercury	Ar 21:24:38	Ar 21:24:37	−1.2″
Jupiter	Ge 26:14:00	Ge 26:13:59	−0.7″
Venus	Ta 25:56:37	Ta 25:56:36	−0.8″
Saturn	Pi 16:04:48	Pi 16:04:47	−1.1″
Rahu	Aq 11:09:52	Aq 11:09:51	−0.9″

All within 1.3″ — visually identical in any chart UI. Same result for Lahiri, Raman, Krishnamurti, KP_NEW.

What this tells us about calculate_planets's contract

Putting both findings together, the implicit contract of calculate_planets(jd, mode) is:

"Given a Julian Day treated as TT (terrestrial time), return sidereal positions computed by swe_calc(jd, planet, tropical) − swe_get_ayanamsa(jd) (i.e., naive ayanamsa subtraction)."

Both of those are surprising vs swe_calc_ut + SEFLG_SIDEREAL (which is what mivion/swisseph callers, and /v1/planets, typically do). Calling them out in the README would prevent everyone from rediscovering this independently. A user with a UT JD just has to add getDeltaT(year) / 86400 before calling — but only if they know to.

Suggestions (refined)

Same as before plus one more:

1. README clarification — document that jd is treated as TT (not UT) and that ayanamsa subtraction is naive (not Swiss-Eph SIDEREAL flag). This is the single most important documentation fix.
2. A jd_ut variant — calculate_planets_ut(jd_ut, mode) that adds ΔT internally before calling the existing code path. Trivial wrapper, ~3 lines, no breaking change.
3. Expose swe_set_sid_mode — useful for the calc_ut + SIDEREAL flag use case (Variant D).
4. Keep mean Rahu as the default for calculate_planets — that's what every KP and most Vedic software uses; /v1/planets's switch to true Rahu in some contexts is the outlier. (Confirming this is the current behavior for SE_MEAN_NODE — just want it to stay that way.)

Would also be useful to know whether you'd consider changing calculate_planets's semantics to take UT input directly. That would be a minor breaking change for downstream users like us who've already patched around it, but cleaner long-term — every other Swiss Ephemeris consumer (including mivion/swisseph and VedicRishi internally) expects UT input.

[fusionstrings]

Thanks @Hari-Bonda for putting time on this, much appreciated.
Please feel free to raise a PR / fork this repo. I might not be able to look into it before the weekend.

[Hari-Bonda]

Closing the loop — sorry for the noise, and thank you

Apologies for the thread getting long. We've finished the investigation and shipped a fix on our side, so here's a short wrap-up in case it helps the next person hitting this.

What we ended up doing: in our wrapper around calculate_planets, we shift the JD forward by getDeltaT(year) / 86400 days before calling. One-line change:

const planets = calculate_planets(jd + getDeltaT(year) / 86400, mode);

That's it. No library change needed.

Result across 1000 random cases (1925–2025, 30 cities, KP_NEW):

Planet	Within ±2″ of VR	Within ±5″
Sun	99.9%	100%
Mars	99.6%	100%
Jupiter	99.8%	100%
Saturn	99.9%	100%
Rahu / Ketu	100%	100%
Venus	94.1%	100%
Mercury	80.5%	100%

Moon stays ~15″ off VR /v1/kp_horoscope (looks like they use a Moon model we can't reach from Swiss-Eph alone) — but this is the same residual every Swiss-Eph implementation has against VR, so it's not on the library.

Thank you for @fusionstrings/panchangam — the wasm-first packaging genuinely made our Cloudflare Workers deployment easy, and the API is clean. The two suggestions from the comments above (README clarification that calculate_planets takes TT input + does naive subtraction, and an optional calculate_planets_ut variant) would just save future users from rediscovering this — entirely your call whether they're worth doing.

I've opened #9 with a small README-only note covering just the naive-subtraction observation (strictly framed as external testing, not a claim about internals) in case it's useful — feel free to close it if you'd rather not merge.

Feel free to close this if there's nothing more to follow up on. Thanks again!