JD to HJD converter plugin is consistently different from other tools by a small amount

[dbenn]

There is a lot of detail in https://sourceforge.net/p/vstar/bugs-and-features/680/ so we'll keep that open until the issue is addressed.

[dbenn]

It's worth noting that the current implementation of solar coordinate (geocentric longitude) computation is based upon Meeus's low accuracy method. A high accuracy method also exists (see Meeus, Astronomical Algorithms, ch 24).

[dbenn]

From the depths of the old SourceForge bug & issue tracker comes this 2019 AAVSO forum exchange: https://www.aavso.org/vstar-jd-hjd-conversion

I note also a HJD AAVSO (new) forum thread from 2024:

https://forums.aavso.org/t/how-to-correctly-calculate-hjd/811

One of the things that arises from both is that I could use or adapt already existing code. I have resisted that, perhaps in an inappropriately stubborn way, but this is also weighed against the effort involved in writing the code, not the best justification of course.

[dbenn]

What is interesting about this is that I used Cursor (an agentic GenAI variant of VSCode) to help analyse the problem. The bug identified is legitimate and I'm surprised I made that error. It was 2016 and there's been a lot of water under the bridge since then in many ways.

Here is the relevant excerpt of an interaction I had with it:

Summary of what was wrong and what was changed:

---

Cause of the ~0.5–2 second difference

The difference came from a bug in J2000HJDConverter.eccentricity().

• In Meeus (e.g. Ch. 24), Earth’s orbital eccentricity is a dimensionless number (about 0.0167).
• The code was treating it as if it were in degrees and returning Math.toRadians(eDegs), i.e. about 0.00029 instead of 0.0167.
• That value is used in the radius vector (Meeus 24.5):
  R = (1.000001018×(1−e²)) / (1 + e×cos(v)).
• With the wrong e, the denominator stayed almost 1, so R came out ~0.99996 AU instead of the correct ~0.99766 AU for the test date (Meeus Example 24.a).
• The HJD correction is −(R/c)×(cos term) in days. So a ~0.23% error in R produced a ~0.23% error in the light-time correction, i.e. about 1–2 seconds (the correction is on the order of a few minutes).

So the mismatch with the BAA HJD converter (and other tools) was due to this wrong Earth–Sun distance in the light-time term.

---

Fix applied

1. J2000HJDConverter.java

   • eccentricity(T) now returns the eccentricity as a dimensionless value (no Math.toRadians).
   • Javadoc updated to state that eccentricity is dimensionless and must not be converted to radians.

2. J2000EpochHJDConverterTest.java

   • eccentricity: Assert the returned value directly (no Math.toDegrees).
   • radius vector: Expected value updated from "0.99996" to "0.99766" (Meeus Example 24.a).
   • HJD tests: Expected values updated to match the corrected implementation (now within about 1 s of BAA where checked).

All 23 J2000 HJD converter tests pass. VStar’s JD→HJD (J2000) results should now agree with BAA and other references to within about a second, with the remaining tiny difference coming from solar model and implementation details rather than the eccentricity/radius-vector bug.

[dbenn]

Having this assistance is valuable. I've been a skeptic and have had (and still do) concerns about what GenAI is doing to us, the environmental impacts, and the importance of verification and the potential for many to ignore the need for it and blindly accept what GenAI gives it. This activity is one sweet spot though. There are also I think likely to be others that will improve both productivity and creativity.

However, we're not done. The GenAI claimed that the results were better. In some cases they were, and in other cases not. In particular, while the first 2 testHJD*() method results were improved, the last 4 were not. My next conversation in Cursor suggested a few plausible reasons relating to:

• solar coordinates
• radius vector
• position dependence
• low vs high accuracy solar model (which has been in the back of my mind since I wrote the code)

I am going to look at each. What my exchanges so far on this topic illustrate is that it is important to not blindly trust the AI, but to ask: does this make sense? It does feel a bit like a superpower though, I have to admit.

[dbenn]

The relevant extract from the transcript is:

1. Solar coordinates: geometric vs apparent

The HJD formula uses coords.getRA() and coords.getDec() — the geometric (mean) solar position — even though SolarCoords also has apparent coordinates. Meeus mentions apparent longitude λ and the code has a note that the choice for HJD is not obvious.

If BAA uses the apparent Sun position (nutation/aberration included), the small angular differences can change the cos(angle) term and thus the light-time correction, and do so differently for different sky directions.

[dbenn]

I asked this question next:

These suggestions are helpful. Especially in relation to suggestion 1, ooking at my code again, I notice that in the calculation of lambda, I am not using J2000 longitude (trueSolarLong2000), but instead trueSolarLong. Is this another bug?

The response was:

Using J2000 longitude for the Sun

Using trueSolarLong2000 when forming the apparent longitude keeps everything in J2000:

λ_J2000 = trueSolarLong2000 - 0.00569° - 0.00478° × sin(Ω)

The aberration and nutation terms (0.00569°, 0.00478° × sin Ω) are small corrections; applying them to trueSolarLong2000 instead of trueSolarLong is a reasonable approximation.

To fully stay in J2000, the ecliptic→equatorial conversion for the Sun should also use the J2000.0 obliquity (e.g. meanObliquityHighPrecision(0) or the fixed value 23°26′21.448″), not the obliquity of date.

Summary

For a J2000 HJD converter, both star and Sun should ideally be in J2000.0. That means:

1. Compute apparent longitude from trueSolarLong2000 instead of trueSolarLong.
2. Convert ecliptic to equatorial using J2000.0 obliquity so that the Sun’s RA/Dec are also in J2000.0.

[dbenn]

Mostly by way of sanity check, I asked this follow-up question:

Okay, and in the calculation of solarRA and solarDec (starting on line 195), should trueSolarLong2000 also be used instead of trueSolarLong?

The response was:

Yes. For a J2000-consistent Sun position, both solarRA and solarDec should be derived from trueSolarLong2000.

Right now they use:

• trueSolarLong (equinox of date)
• obliq (obliquity of date)

For J2000 they should use:

• trueSolarLong2000 (longitude referred to J2000.0)
• obliquity at J2000.0 (e.g. meanObliquityHighPrecision(0) ≈ 23°26′21.448″)

Same idea for the apparent coordinates: apparentSolarRA and apparentSolarDec should come from λ_J2000 (built from trueSolarLong2000 minus aberration and nutation) and J2000.0 obliquity. The obliquity-of-date correction + 0.00256° × cos(Ω) is a nutation term, and if you're going fully J2000 you’d need to decide whether to keep it and how it fits into the J2000 frame.

So the change to line 195 and below: switch solarRA and solarDec to use trueSolarLong2000 and the J2000 obliquity, and do the same for the apparent quantities if you want full J2000 consistency.

[dbenn]

I changed to code (instead of asking Cursor to create patch files this time) to use J2000 solar longitude and the results improved further. Way further. The worst difference between VStar's HJD conversion code and BAA's is in the order of 3 hundredths of a second. Some results are closer to 3 thousandths of a second delta!