Cannot find 1P/Halley in historical apparitions

[gzotti]

After the big renaming effort, the F3 search panel no longer can clearly indentify a comet in several apparitions.

Expected Behaviour

F3 search: "Halley" should list all known apparitions

Actual Behaviour

I can only find one entry for 1P/Halley which resolves to 989 N1, and another for P/Halley (1222) which does not load.

Steps to reproduce

Load ssystem_1000comets.ini, then search for Halley.

System

• Stellarium version: 23.2
• Operating system: Win11 (hopefully irrelevant)
• Graphics Card: Geforce (irrelevant)

Logfile

If possible, attach the logfile log.txt from your user data directory. Look into the Guide for its location. The logfile indicates some message around a "stupid general group" which IMHO should not exist and indicates a bug. Logfile of a previous run showed problems around a regular expression ('HALLEY(1456)'), but I cannot reproduce that now. I searched for "Halley", "Halley(1456)" and "Halley (1456)".

log.txt

[alex-w]

@gzotti did you used 1000 comets from master?

[gzotti]

No, 23.2 with the data file from its own directory. Did you change something later? (I don't usually build the SSE plugin, so just used the regular program.)

[alex-w]

Please attach data file

[gzotti]

You can use files from master or from 23.2. Result is the same. Does it work (does it list and let you you select any of the expected Halley entries) on Linux? The 1222 entry was a stored query, I reset them, now it's gone. The issue persists in master.

[alex-w]

@gzotti I can't reproduce the "group" issue on Windows too - what you did doing?

[gzotti]

• Delete USERDIR/data/ssystem_minor.ini
• start Master
• Reset last search items
• Search Halley

Result: This only finds P/Halley from 989. When I set date to e.g. 1456, Halley (in its apparition of 1456) is not displayed.

log.txt

Line 3544:

Checking for stupid General group.

[alex-w]

• Delete USERDIR/data/ssystem_minor.ini
• start Master
• Reset last search items
• Search Halley

Result: This only finds P/Halley from 989. When I set date to e.g. 1456, Halley (in its apparition of 1456) is not displayed.

Yes, I can reproduce this issue, and it's expectable due to the current implementation of search/matching the data in Search Tool.

log.txt

Line 3544:

Checking for stupid General group.

I don't see these warnings in my log

[gzotti]

Then the search/match tool must be fixed accordingly. But I am afraid there is even more. In addition to not being found via search, I simply cannot find the comet visualized in 1456, when it was reportedly observed. The 1457 comets appear as expected.

[gzotti]

How was this ever planned to work? englishName is always 1P/Halley. Making this unique (renaming to a wrong name) appears to solve the problem, i.e., show the comet, but of course runs against the idea of the recent changes. Or, better, overriding Planet::getID() and using Comet::getID(). getID() must be a unique string.

[alex-w]

@gzotti please check the Search Tool/Lists/Comets - probably the issue is deeper that we think :(

[alex-w]

How was this ever planned to work? englishName is always 1P/Halley. Making this unique (renaming to a wrong name) appears to solve the problem, i.e., show the comet, but of course runs against the idea of the recent changes. Or, better, overriding Planet::getID() and using Comet::getID(). getID() must be a unique string.

Maybe. The solution looks acceptable. Possible unique ID for comets with periodic designation is - "designation [perihelion year]" (e.g. "1P/Halley [1986]").

[alex-w]

OK, Stellarium cannot load multiple celestial bodies with same names, so, we have possible 2 solutions: a) using unique names for comets with periodic designations (example: 1P/Halley [1986], where 1P/Halley is periodic designation and [1986] is year of reaching the perihelion) b) modify the code to allow loading celestial bodies with identical names and add the hook to generate the unique proper names for comets with periodic designations

Both ways have a pluses and minuses and I prefer the way a) right now - we need update data file only (with revision the data)

[gzotti]

No need to update the data file! We have everything required to form a unique string for getID(). "<englishName> (<date_code>)". And all relevant places where englishName was tested should test getID() instead. If the search dialog receives a list of getID(), there should then be numerous entries for all entries Halley, Pons, Biela, Levy, ...

[alex-w]

No need to update the data file! We have everything required to form a unique string for getID(). "<englishName> (<date_code>)". And all relevant places where englishName was tested should test getUID() instead. If the search dialog receives a list of getID(), there should then be numerous entries for all entries Halley, Pons, Biela, Levy, ...

You're not right - please see filling secNameMap and depLevelMap within method SolarSystem::loadPlanets() - if you have 10 items for one comet, then you will get 10 records for the latest one.

[alex-w]

Please see first part of changes in branch fix/3349

[gzotti]

No need to update the data file! We have everything required to form a unique string for getID(). "<englishName> (<date_code>)". And all relevant places where englishName was tested should test getUID() instead. If the search dialog receives a list of getID(), there should then be numerous entries for all entries Halley, Pons, Biela, Levy, ...

You're not right - please see filling secNameMap and depLevelMap within method SolarSystem::loadPlanets() - if you have 10 items for one comet, then you will get 10 records for the latest one.

Indeed, here is a trap, and has always been there. Before the line secNameMap[englishName] = secname;

we must test if secNameMap already contains such entry, and give a qWarning(). And in case of comets, where problems are now to be expected, you can just use "<englishName> (<date_code>)" as key into secNameMap. This obviously requires a valid date_code for all comet entries. If a comet entry has no date_code, give a qWarning() and ignore entry.

[gzotti]

It appears to me that most entries "iau_designation" for minor planets and the two Interstellar objects should be "discovery_code". Of course, IAU acknowledges progress in knowledge, so that they would use the refined designation like "(number) name".

[alex-w]

No need to update the data file!

You’re wrong again, because many comets in ssystem_1000comets.ini file has joined designations as a name of the comet. We should split these data into separate parameters.

[gzotti]

I am speaking of the default ssystem_minor.ini. The 1000comets.ini has, as acknowledged in its header, still the old names, apart from the Halley entries. Please don't edit that now, I have just removed 6500 lines of default entries from there. After merge of #3371 it appears useful to update this file according to the latest developments.

I will have a deeper look into this myself now and try to find a solution without even more extra data or variables. The object ID is still unused (or rather, equals englishName which is not unique here). Within the program, objects should be identified unambiguously with getID(), and to the user all labels can be shown in the Infostring, but it should be enough to use the combined name+date code.

[github-actions[bot]]

Hello @gzotti!

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

[github-actions[bot]]

Hello @gzotti!

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

[pmisson]

Is this bug solved? I still cannot find the Halley rendered in 1456. I'm using version 24.2 on windows.

[gzotti]

Have you loaded the 1000comets file?

[pmisson]

My fault. It is working, thanks.