very wrong comet positions for eccentricities between 0.9999 and 1

[Louis Strous]

Stellarium 0.12.4 says that comet C/1680 V1 is still within 0.01 AU of the Sun, even though it reached its perihelion over 3 centuries ago.

REPRODUCTION SCENARIO:

Add the following section to ssystem.ini:

[C1680V1]
absolute_magnitude=10
albedo=1
color=1.0,1.0,1.0
coord_func=comet_orbit
lighting=false
name=C/1680 V1
orbit_ArgOfPericenter=350.6128
orbit_AscendingNode=276.6339
orbit_Eccentricity=0.999986
orbit_PericenterDistance=0.006222
orbit_TimeAtPericenter=2335019.9876
parent=Sun
radius=40
slope_parameter=0
tex_map=nomap.png
type=comet

Then start Stellarium and check the position of that comet. It is reported to be still very close to the Sun today.

DIAGNOSIS:

CometOrbit::positionAtTimevInVSOP87Coordinates treats comet orbit eccentricities >= 0.9999 and <= 1 as parabolic, but for eccentricities < 1 SolarSystem::loadPlanets calculates the mean daily motion for an elliptical orbit. If the eccentricity is >= 0.9999 and < 1, then CometOrbit::positionAtTimevInVSOP87Coordinates calculates the distance assuming a parabolic orbit, but using the mean daily motion for an elliptical orbit instead of a parabolic orbit. For C/1680 V1, the elliptical mean daily motion of 1.836e-6 is interpreted as a parabolic mean daily motion, but the correct parabolic mean daily motion would be 37.176, about 2e7 times greater. Effectively, Stellarium assumes the comet to move 2e7 times slower than it really does.

SOLUTION:

Adjust SolarSystem::loadPlanets to treat comet orbits with eccentricities >= 0.9999 and <= 1 as parabolic, consistent with what CometOrbit::positionAtTimevInVSOP87Coordinates does. See attached patch file.

[Alexander Wolf (alexwolf)]

A fix has been committed as revision 6344 of the trunk branch in Stellarium's Bazaar repository at Launchpad:
http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/6344

[Jon Seamans (silvy5)]

How coincidental!
I found this bug for the same comet last week. For an four- "9" eccentricity (0.999900) the problem showed up. I discovered a work-around by using 0.999899.
Also, I believe I verified that v11.3 does not show this problem.

Thanks, Louis. You've documented this bug very well.