Incorrect 1P/Halley position near 1986 perihelion

[suiterhr]

Expected Behaviour

Correct prediction of the position of Comet Halley at or near 1986 perihelion.

Actual Behaviour

Issue #1: The orbital elements for comet 1P/Halley presently used as a default are seriously defective when asked to reproduce Halley's last appearance in 1986. Among other differences, the perihelion date of the real comet was Feb 9, 1986 [see Yeomans and Chodas Astron Jour v98 n3 p 1083 (Sept 89)]. The Stellarium default elements of 1P/Halley have the perihelion date of 21 Jan 1986! Stellarium shows the position of the comet on 18 Mar 1986 in Scorpius, and I know this is incorrect because I photographed it in Sagittarius. I recently downloaded a set of elements from the Minor Planet Center into Stellarium, and the revised elements are as follows"

Table: Epoch 1986 MPC revised elements matching contemporary photos, adapted to Stellarium format.

[1phalley] orbit_good = 1000 orbit_Eccentricity = 0.967277 orbit_TimeAtPericenter = 2446470.958888889 name = 1P/Halley orbit_ArgOfPericenter = 111.8657 albedo = 0.1 type = comet absolute_magnitude = 4 orbit_Inclination = 162.2422 dust_brightnessfactor = 1.5 dust_lengthfactor = 0.4 slope_parameter = 6 orbit_visualization_period = 27758.20106745674 orbit_PericenterDistance = 0.587104 dust_widthfactor = 1.5 orbit_AscendingNode = 58.8601 coord_func = comet_orbit radius = 5

The particular page where Stellarium obtained this information is, I believe, https://www.minorplanetcenter.net/iau/MPEph/MPEph.html

Again, perihelion is Feb 9 in the elements of the Table. These revised elements (orbit epoch = Feb 19.0, 1986) were tested against contemporary photos and good matches were found (my photo on 18 Mar 1986 was less than an arcminute off). The results of downloading elements from several files distributed by the same MPC and available elsewhere in Stellarium were erroneous. They show an 18 Mar 1986 position between Sagittarius and Scorpius.

The reason that the files being distributed by the same MPC use different elements from what it delivered in the ephemeris calculation service in the link above is unknown to me. Either the files are corrupted by a typo, or they refer to distant orbit epochs having little to do with the comet when it was visible. I can reproduce the JPL Small Body Database Browser (Epoch 17 Feb 1994) elements, but I have not been able to reproduce a perihelion date 18 days early.

Since it makes no sense to use orbital elements which place Halley when it was visible in the next constellation, I suggest the default elements be replaced by those in the Table.

Related Issue #2) Orbit_Epoch is not recorded with a comet's elements. Bodies should not be displayed outside of a window that is some sort of multiplier of orbit_good on either side of orbit_epoch, but I have been unable to find a parameter that would contain this information. Are all comets in Stellarium assumed to have orbit_epoch at perihelion? If so, that would explain a lot.

I have both of these issues discussed in more detail in my on-line essay https://www.bay-astronomers.org/Backissues/CometHalley.pdf

Steps to reproduce

Set the time to 1986 Mar 18. Witness the comet placed in Scorpius. The actual position is given in the following photograph. As a guide to the eye, the handle of the Teapot of Sagittarius is denoted by white lines, as is a little kite-shaped figure below the comet. Please note that the error also exists at the stellarium-web.org site.

System

• Stellarium version: <0.20.2 Windows>
• Operating system: <Windows 10 Home>
• Graphics Card: <Intel HD Graphics, 9.17.10.4459>
• Screen type (if applicable): Not Relevant -- No malfunction

Logfile

If possible, attach the logfile log.txt from your user data directory. Look into the Guide for its location.

[github-actions[bot]]

Thanks for adding your first issue to Stellarium. If you have questions, please do not hesitate to contact us.

[gzotti]

Since it makes no sense to use orbital elements which place Halley when it was visible in the next constellation, I suggest the default elements be replaced by those in the Table.

Please report this to the MPC. We are not responsible for whatever data they deliver. It should be very clear from existing documentation that you should use fitting orbital elements from a time close to the date of photography when comparing photographs. Stellarium does not model orbital disturbance by the planets or even non-gravitational effects from outgassing, solar radiation pressure or whatever.

Related Issue #2) Orbit_Epoch is not recorded with a comet's elements. Bodies should not be displayed outside of a window that is some sort of multiplier of orbit_good on either side of orbit_epoch, but I have been unable to find a parameter that would contain this information. Are all comets in Stellarium assumed to have orbit_epoch at perihelion? If so, that would explain a lot.

If you study the User Guide, Appendix D.2.2, you can see that the idea of orbit_good is to not show comets when they are beyond orbit_good days away from perihel. Currently, indeed, orbit epoch is identical to perihel. While orbit epoch should be a separate number, up to this day we have not changed that.

The value orbit_visualization_period = 27758.20106745674 should be deleted, though. This was a misunderstanding in the handling of missing data that has been found only a few weeks ago.

[alex-w]

@gzotti please read the document https://www.bay-astronomers.org/Backissues/CometHalley.pdf also

[gzotti]

The result when using Stellarium's 1000comets.ini...

This is March 18, 1986, 0:01 (UTC+1). Not the worst of matches, IMHO.

I may comment on the report later.

[suiterhr]

1000comets yields a much closer result (only about 20 arcmin away) and can perhaps be explained by a different orbit_epoch. Here MPC (ie, my Table) is compared to the elements downloaded from 1000comets (labeled 1982i-1986III). As to the results in Scorpius, your guess is as good as mine.

[gzotti]

Not a bug, because there is nothing to fix in the code at this time! Absolutely only wrong orbital elements (data).

OK, I see that for the first time: The elements in ssystem_minor.ini have been replaced in 2016 with data of which I don't know the origin. @alex-w I recommend these to be replaced by those currently existing in 100comets.ini, because I have prepared this latter file (around 2013/2014?) from a few historical catalogs, and I was able to reproduce a few photos or paintings from historical comet apparitions (e.g. Donati). I should still find my files and, having seen some more recent edits, could re-run this, just in case numbers have also been mangled since then. There is definitely zero use for orbital elements for Halley from 2016, valid for 2016, when they include a wrong perihel date.

Probably we should have element sets for Halley 1986 and (preliminary) for Halley 2061 in the default file, with appropriate perihel years in the name string (we had a request for the latter about 5 years ago. My standard answer is "come back in 2050" (after certain rediscovery, and when it becomes "interesting" again?), but maybe there are current observations and working elements? I have not followed this close enough.)

The desire for a separate "orbit_epoch" entry, and handling orbit_good just around the orbit_epoch, is also mine. However, it's much farther down on my list than many other things that I'd like to see. For now (ever since comets were added to this program), orbit_epoch=orbit_TimeAtPericenter, and orbit_good should prevent display of the comet beyond these many days from perihel. Another desire would be addition of elements for different equinoxes. (1900.0, 1950.0 or such. It's always a matter of "do I need it right now?")

It would help for development to have a few element sets for a comet in one perihel apparition, but with different orbit_epochs, though. At what point does it really make sense to have more than 1 set per apparition? (I don't care much for a comet of mag24 somewhere out next to Uranus!) Can you model e.g. Hale-Bopp with 1 set of elements accurately enough to identify it on photos taken 5 years from perihel? My guess is "yes". This is why it's not so urgent for me.

Usually after discovery there are orbital elements derived and published which are refined as observations come in, and at some point after perihel no new element sets are published as the comet falls out of interest. I wonder whether, in general, the latest published elements (with epoch maybe a few weeks after perihel) represent the earliest observations equally well as the first derived elements, or whether the orbit really has changed.

[alex-w]

OK, I see that for the first time: The elements in ssystem_minor.ini have been replaced in 2016 with data of which I don't know the origin. @alex-w I recommend these to be replaced by those currently existing in 100comets.ini, because I have prepared this latter file (around 2013/2014?) from a few historical catalogs, and I was able to reproduce a few photos or paintings from historical comet apparitions (e.g. Donati).

I fear the wrong data may be added by me when I updated orbital elements for minor bodies from MPC

[alex-w]

Probably we should have element sets for Halley 1986 and (preliminary) for Halley 2061 in the default file, with appropriate perihel years in the name string (we had a request for the latter about 5 years ago.

I don't remember this request. :( I think we may add both sets pf orbital elements for Halley comet + all Great Comets into default file from 1000comets. Is it ok for you?

[alex-w]

The desire for a separate "orbit_epoch" entry, and handling orbit_good just around the orbit_epoch, is also mine. However, it's much farther down on my list than many other things that I'd like to see. For now (ever since comets were added to this program), orbit_epoch=orbit_TimeAtPericenter, and orbit_good should prevent display of the comet beyond these many days from perihel. Another desire would be addition of elements for different equinoxes. (1900.0, 1950.0 or such. It's always a matter of "do I need it right now?")

What about real value of orbit_good parameter for Halley comet? Should we remove comet from the search and computation when comet are outside valid range?

[gzotti]

Probably we should have element sets for Halley 1986 and (preliminary) for Halley 2061 in the default file, with appropriate perihel years in the name string (we had a request for the latter about 5 years ago.

I don't remember this request. :( I think we may add both sets pf orbital elements for Halley comet + all Great Comets into default file from 1000comets. Is it ok for you?

I would put Halley 1986, and if available 2061, C/1996 B1 Hyakutake and C/1995 O1 Hale-Bopp into the default file, and a few post-2000 naked-eye highlights (McNaught, some in 2013 and now Neowise). The 1000comets list historical comets from two well-defined sources and should not be extended manually with undocumented data. In any case, elements used for Stellarium must have their epoch close to perihel, or validity must be written into the name string so that the user can guess it. orbit_good currently is centered on perihel date.

This number allows trimming off the uninteresting part of a comet's orbit, which for higher excentricities is the overwhelming part. If you can follow a comet +/-10 years around perihel, you could specify 3650. Note that the discovery name of Halley 1986 was 1982i, so less than 4 years.

orbit_good is indeed used to switch off comet rendering. This is especially helpful for periodic comets with several sets, like Halley, to avoid a comet on its 1910 orbit appear in a wrong place in the mid-1980s. Positions are always computed in the SolarSystem, therefore you should not load the full 1000comet file on weak PCs, but at least the drawing part is culled.

It is also intended to limit rendering to the more important part of a comet orbit. (actually we also have orbit_visualisation_period, but one defaults to the other, sorry I cannot remember now.)

You could test and optionally exclude from search results: static_cast<KeplerOrbit*>(orbitPtr)->objectDateValid(jde)

On the other hand, it is nice to be able to search for it and find, even if not displayed, its approximate distance, so I don't know how useful that is.

When I search for "Halley" with the 1000comets file loaded, I get a few unsorted entries from Halley, but I have to guess the spelling for the 1986 set to display that. Can we display more search results? Or will the new search behaviour change that?

[suiterhr]

I've been looking at the file CometEls.txt in the IAU Minor Planet Center, and reading the format documentation that accompanies it. It has the perihelion date of Halley at 22 Jan 1986. The orbit epoch is continually updated and the copy I looked at was 30 Aug 2020. Here is what I think is happening: 1) CometEls.txt is updated every time a new comet is discovered. 2) The orbital elements are updated to the date when CometEls.txt is modified. 3) Someone -- perhaps one of you -- runs CometELs.txt through a Stellarium format translator to add the interesting new comet and prepare a new ssytem.minor.ini. (Maybe this is an automated process.) 4) Old comets are thus given questionable historical positions when time is cranked back and they use osculation points (i.e., orbit epochs) far from the sun (the new comet is fine).

If you start using orbit_epoch and an orbit_good window around it with CometEls.txt as input, you will exclude nearly all long-period comets. What you need is a historical set of comets having orbit elements calculated near their respective perihelions.

Also we must explain why that one IAU website at https://www.minorplanetcenter.net/iau/MPEph/MPEph.html gave good results. I believe the answer is contained on the page itself. Near the bottom you can see that this page is designed to feed a number of digital planetaria. [Stellarium is not listed!] The on-line calculator must be predisposed to deliver comet data around the perihelion so the planetarium programs can use it. Another possibility: there is a radio button to turn off the perturbed orbit. With dynamical calculations turned off, it shouldn't make any difference where it is in its orbit. It will follow the ellipse like a bead on a wire.

All of this is one user's conjecture.

[gzotti]

If you start using orbit_epoch and an orbit_good window around it with CometEls.txt as input, you will exclude nearly all long-period comets. What you need is a historical set of comets having orbit elements calculated near their respective perihelions.

This should be the case for 1000comets.ini. From my notes from early 2014: elements for Halley taken directly from Yeomans&Kiang MNRAS.197..643 (1981). H10 (missing there) from Mucke: Komet Halley als säkulare Himmelserscheinung. Die Sterne 61-5/6 (1986) and extrapolated before -239. Other comets from http://spider.seds.org/spider/Comets/comets.data. (DEAD LINK :-( and http://ssd.jpl.nasa.gov/dat/ELEMENTS.COMET. In those files, where epoch is given, it is within weeks of perihel.

I think I have never analyzed the CometEls or MPEph, but have seen epoch mentioned in published printed element sets since the late 1980s. When I found the comet position code (originally developed by a former team member), I saw that there is no epoch and understood we always assume elements to be valid around perihel. I thought maybe we can add epoch handling at some later date, if there is really need for that. Many other things turned out to be more urgent. I fully agree and expect that using Halley elements for an epoch in the 1990s will yield bad results when displaying the months around its perihel. Garbage in -garbage out. The optimal orbital element set to use to analyze a photo from March 18, 1986 should have an epoch somewhere in March 10..20, 1986, but probably Dec. 1985 to June 1986 is acceptable. :-)

Sometimes you must improvise. If you remember the close asteroid fly-by on the evening of the Chelyabinsk event: I got elements from JPL Horizons for every hour during the Earth fly-by (when the orb. elements were changed by Earths gravity) and had a string of asteroids, their names indicating in which hour the position is best approximated.

[suiterhr]

I would not call the 2020 updated comet elements garbage! They will probably be a better guess for the next appearance. But I would like to advocate that you at least add the elements in my essay to a new entry called "1P/Halley 1986" in comets1000. MPC Ephemeris Service reports them for an epoch date of 19 Feb 1986 and they are nicely placed at the center of the brightest appearance. They are well documented by a report published by Yeomans and Chodas AJ v98 1083 which is, in fact, the starting place for the calculation of CometEls.txt (you can see it over near the last column where most of them refer to the Minor Planet Circular with a high number behind it). I don't know where you got the rest of the Halley entries (Owen Gingerich perhaps?), but this one is most accurate for the last pass. Another thing that would be handy is to put it high up in the list, so it is the first thing a search on "Halley" encounters.

[suiterhr]

Oops.

[alex-w]

I've updated orbital elements for comet Halley in commit 0809f74b195b188458b1da3825dbcdf22f0b6ed5 for default ssystem_minor.ini file, but I fear the "wrong elements" may be coming from MPC again...

[suiterhr]

Thanks, I would have gotten back to you before this, but I've had a bad cold (no not THAT, if tests can be believed).

Another stopgap that is possible is to point out this problem more forcefully in the manual, and say that the orbital elements of famous historical comets near their peaks are more accurate in 1000comets (I assume Halley1986 is not alone in being more accurately represented by1000comets), not in the currently updated set. For that, someone would have to check them. I would be glad to do that, at least for significant comets from the beginning of the 20th century. I propose to use perihelion time and date as the indicator, as that seems to exhibit the widest variation in recalculated sets. Another advantage is that peri t/d is independent of coordinate epoch.

Harold Suiter

On Sun, Nov 15, 2020, 8:53 AM Alexander Wolf notifications@github.com wrote:

I've updated orbital elements for comet Halley in commit 0809f74 https://github.com/Stellarium/stellarium/commit/0809f74b195b188458b1da3825dbcdf22f0b6ed5 for default ssystem_minor.ini file, but I fear the "wrong elements" may be coming from MPC again...

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/1241#issuecomment-727582060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQZQMSXNZ6XGGXTLWV4OD63SP7TNRANCNFSM4QPW4JLA .

[gzotti]

Just take the elements from the 1000comets file for the 1986 apparition. And yes, at some point, if somebody has the time for it, we add epoch to the elements and can estimate validity a bit more clearly. I would have to dig out the original list again, but it should include all relevant comets before 2000 or so with elements for some epoch close to perihelion.

[github-actions[bot]]

Hello @suiterhr!

Please check the fresh version (development snapshot) of Stellarium: https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions[bot]]

Hello @suiterhr!

Please check the latest stable version of Stellarium: https://github.com/Stellarium/stellarium/releases/latest