Astrocal ephemeris ignores Ceres, Vesta, ...

[axd1967]

Tested with 0.21.2 fc4c6bb

When computing the ephemeris of Ceres from 2021-10-28 to 2021-11-28, the dialog (F10) remains empty for Ceres. this appears in b87b419.

I tried to update Ceres via asteroid import data; not sure the import succeeded: was Ceres finally updated?

Assuming this is an issue of outdated orbital data (but ... Ceres?) #1880 (comment) might have helped here.

• selecting an object should show the validity date range of that object as a new info line (for_wishlist)

[alex-w]

This is not a bug, this is a feature. If you want to see Ceres and other asteroids in wide range of dates then define orbit_good parameter in ssystem_minor.ini file for these asteroids (e.g. orbit_good = 5000).

[axd1967]

This is not a bug, this is a feature. If you want to see Ceres and other asteroids in wide range of dates then define orbit_good parameter in ssystem_minor.ini file for these asteroids (e.g. orbit_good = 5000).

Be aware here we are talking of predictions for the next month. So this makes the case stronger to provide some form of warning to the user (entry in logfile, a flash message, or a new line of Information, similar to #1096).

[alex-w]

Be aware here we are talking of predictions for the next month.

And?

So this makes the case stronger to provide some form of warning to the user (entry in logfile, a flash message, or a new line of Information, similar to #1096).

How exactly one, two or ten warning will help user, who do not want to define the parameter? For example log file contains the info about result of updating the orbital elements - how did it help you if you "does not see" records in the log?

[gzotti]

Update the elements. This has been the accepted solution since before the first person has complained in software of the 1990s. We estimate orbit_good to avoid printing bad data. You may always propose your working better solution as PR.

[axd1967]

As far as I can see, all 0.21.2 users are affected, am I right?

Updating the elements will not solve this issue. I tried MPCAT 1..9999 (see 23245d2#r59605156) to no avail.

[gzotti]

Now I see what's really happening. For asteroids with elements and epoch we compute last perihel date and compute orbit_good from that. For asteroids with a few years orbit this may lead to this behaviour that too much time has passed since that previous perihel. So. after all, we have to add epoch to the elements (was scheduled for "later"), and we could estimate a default orbit_good to be equal the orbit period (with all positional error dangers this implies), centered around epoch. For non-elliptic orbiters (comets), we still should keep that at ~1000 days.

For a temporary override of the fuse, set orbit_good to whichever value, about orbital period.

[axd1967]

I also tried to copy the elements from JPL as well as MPC but get strange results in both cases.

• https://ssd.jpl.nasa.gov/tools/sbdb_lookup.html#/?sstr=ceres
• https://minorplanetcenter.net/iau/MPCORB.html

[1ceres]
absolute_magnitude             = 3.54
albedo                         = 0.15
coord_func                     = comet_orbit
minor_planet_number            = 1
name                           = Ceres
orbit_ArgOfPericenter          = 73.7377
orbit_AscendingNode            = 80.26762
orbit_Eccentricity             = 0.0783941
orbit_Epoch                    = 2459400.5
orbit_Inclination              = 10.5882
orbit_MeanAnomaly              = 248.40797
orbit_MeanMotion               = 0.21429254
orbit_SemiMajorAxis            = 2.7656551
orbit_visualization_period     = 1679.9465160344398
radius                         = 337
slope_parameter                = 0.15
type                           = asteroid
orbit_good                     = 5000

[1ceresM]
absolute_magnitude             = 3.54
albedo                         = 0.15
coord_func                     = comet_orbit
minor_planet_number            = 1999999
name                           = Ceres(MPC)
orbit_ArgOfPericenter          = 73.63703
orbit_AscendingNode            = 80.26858
orbit_Eccentricity             = 0.0785011
orbit_Epoch                    = 2464400.5
orbit_Inclination              = 10.58769
orbit_MeanAnomaly              = 291.37563
orbit_MeanMotion               = 0.21424745
orbit_SemiMajorAxis            = 2.7660431
orbit_visualization_period     = 1679.9465160344398
radius                         = 337
slope_parameter                = 0.15
type                           = asteroid
orbit_good                     = 5000


[1ceresJPL]
absolute_magnitude             = 3.54
albedo                         = 0.15
coord_func                     = comet_orbit
minor_planet_number            = 1999998
name                           = Ceres(JPL)
orbit_ArgOfPericenter          = 73.73826765873966
orbit_AscendingNode            = 80.26763801181816
orbit_Eccentricity             = 0.07839201989374402
orbit_Epoch                    = 2459921.250133264627
orbit_Inclination              = 10.58819557618916
orbit_MeanAnomaly              = 247.5499723080229
orbit_MeanMotion               = 0.2142925185981219
orbit_SemiMajorAxis            = 2.982460555138589
orbit_visualization_period     = 1679.946655884585
radius                         = 337
slope_parameter                = 0.15
type                           = asteroid
orbit_good                     = 5000

I think this justifies releasing a hotfix.

[axd1967]

@gzotti consider starting a hotfix branch from 0.21.2 (eg release/0.21.2/hotfixes) and later merge to master.

[gzotti]

Six weeks to next release, and too little time to develop. Creating a hotfix release a week before next release for this small issue won't pay off.

[github-actions]

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

[github-actions]

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