Fix proper motion equation in Star1/2 and Pulsar #3982
Conversation
|
Great PR! Please pay attention to the following items before merging: Files matching
This is an automatically generated QA checklist based on modified files. |
|
This is unfortunately most likely wrong. See Appendix Table C.4. dx0 and dx1 are proper motion in the star zone's axes, not Δα / Δδ I am pretty sure a good solution would lie in re-running the star catalog creation program (and finally documenting it!) and fixing both PM values, taking cos(δ) into account for encoding so that it is not needed for decoding. To check final results, compare e.g. Arcturus 5.000BC with Cartes du Ciel (see paper mentioned in User Guide Appendix F.2). Do not compare with Gaia, this is apples&pears. |
|
@gzotti I know what the user guide said. I Don't believe it too initially but somebody must have fixed the catalog at some point. The Take the catalog HIP 8268 has pmra=16.958 mas/yr, pmdec=-7.812 mas/yr while catalog is pmra=174 x0.1mas/yr, pmdec=-73 x0.1mas/yr HIP 9117 has pmra=66.089 mas/yr, pmdec=9.661 mas/yr while catalog is pmra=645 x0.1mas/yr, pmdec=88 x0.1mas/yr HIP 6593 has pmra=4.641 mas/yr, pmdec=3.706 mas/yr while catalog is pmra=46 x0.1mas/yr, pmdec=44 x0.1mas/yr See it for yourself: |
|
Actually now think and look at the code a bit more, I think this PR and the current implementation in Stellarium are both doing correct thing but simply in different coordinates systems. BUT it is slightly better numerically to compute RA/DEC in its native spherical coordinates (hence slight improvements in this PR assuming Gaia DR3 is the ground truth) than rectangular coordinates (the current implementation in Stellarium). I have seen similar problem when I was trying to do numerical integration under a Kepler potential. Numerical integration under rectangular coordinates does not have energy conservation while under spherical coordinates almost do conserve energy (jobovy/galpy#363 (comment)). (I am only a bit confident the following are correct) I think thats why both |
|
A quick comparison for few stars for date 3000-01-01 12:00:00 (UTC+07:00) when aberration and nutation are disabled in Stellarium (atmosphere is off). Arcturus
Vega
Polaris
Barnard's star
Megrez
Caph
Deneb
Albireo
Spica
Stellarium 24.3 is showing proper motions as in SkyChart, but using values as from this PR. P.S. Looks like we should regenerated Star1/2 catalogs for updating proper motion data from new reduction of HIP catalog (2007A&A...474..653V) |
|
Yes, while better, something still seems to be off. Compare Cassiopeia at 10,000 BCE between this PR and SkyChart:
Especially Caph and η Cas seem to be considerably off in the Neolithic. |
This is a result of application of different values of proper motion of stars |
Other than different PM in RA/Dec, you mean? SkyChart uses 3D corrections, which might make it difficult to use for a fair comparison. |
SkyChart uses PM data from HIP catalog and Stellarium uses PM data from XHIP catalog. |
|
Which catalogs were actually processed (URL) to create our star catalog? And which programs from the util subdir have been actually used for this after 2006? (HipJ1991ToJ2000.pl, HipJ1991ToJ2000.v2.pl, HipJ1991ToJ2000.v3.pl, ParseHip*.C, MakeCombinedCatalogue*.C?) Which of these programs must be applied to which data files to create our current star catalogs? This process looks like a trade secret despite open-source code. Is there any README file, Makefile, other docs which describe the process? Does it work on Linux only? Sorry I simply cannot take two weeks of vacation to investigate, and my weekends are booked likely until next year. It is just not good to replace a flawed solution with a possibly easy fix (just cos(δ) the PM values as needed while creating the catalog) by a solution that replaces PM by whatever similar values the encoded values may look like. Currently the InfoString values for PM are taken from an extra file, which was IMO a kludgy fast solution. It should be possible to restore catalog values from decoding the star entry and undoing the cos(δ), then remove the InfoString-required extra PM file. It is also not good to compare against Gaia results. Just decode the position as encoded in our catalog and compare to the original value from ESA's Hipparcos data files which were used to create it. Once this process is understood, we can actually improve by
|
Ouch... The latest scrips and data for preparing a HIP data you can found here + MakeCombinedCatalogue.v4.C (differences with version 3 is other paths to NOMAD catalog and version of generated file) + Parse*.C files. |
|
Thank you. Is the solution then just to modify MakeCombinedCatalogue: ReadHipTycFile() and modify pm_ra and pm_de by multiplying with cos(dec)? I have not thought through the whole process (and have still no time to setup the catalog creation chain without clear instructions), but if that was the lacking component, just try it here. (Also in ReadNOMADFile()) This will be processed into the Zone/triangle vectors then. Then again, create accessor methods to retrieve catalog PM values from the known triangle zone vectors and respective zone coordinates, then get rid of the PM extra file (hip_pm.dat). |
|
@Atque can you add 24.3's output to the Cas animation to see what really has changed? |
|
I am trying to help and am experimenting with new catalogs. I have this branch here: https://github.com/henrysky/stellarium/tree/new_star_catalog. You can take a spin and tell me waht you think. I did not commit the catalog to the branch nor editing the star catalog config file so you have to download them here to replace those in the branch manually from https://www.astro.utoronto.ca/~hleung/shared/stellarium_new_catalog/trial0/. The python script/notebook and corresponding Gaia archive ADQL query that generate the catalogs are also in there. The new catalog is a combination of Hipparcos-2 and Gaia (no Tycho and NOMAD). Since Hipparcos-2 supposedly complete down to vmag=7.5 and Gaia complete down to vmag=17ish without bright stars (Vmag<6?). That branch of Stellarium also show Gaia DR3 source_id for faint stars. To compare @alex-w Skychart data, those are stars bright enough not be observed by Gaia so the proper motion in my experimental catalog are from HIP-v2 for a fair comparison. My catalog directly store RA/DEC 4 bytes each with 1 mas resolution and pmra/dec 4 bytes each with 1 uas/yr resolution, but kept the original catalog zone scheme and place bright star first & faint star last within each zone. Arcturus
Vega
Polaris
Current data model for my new catalog. For data type 0
For data type 1
Gaia DR3 does provide better v-mag even if it does not measure v-mag. See Figure 5.39 here: https://gea.esac.esa.int/archive/documentation/GDR3/Data_processing/chap_cu5pho/cu5pho_sec_photSystem/cu5pho_ssec_photRelations.html. The inferred V-mag from G-mag and Gbp-Grp only has scatter of ~0.03mag. While it does provide only reasonable good B-mag for most star. For example, Barnard's stars has Gbp-Grp=2.8 which translate to B-V=2.5 (but should be around 1.7). Barnard's stars is in the grey area in the figure that does not have good B-mag estimation. |
|
OK, that looks interesting! What about comparing around 2000BC, and (I have not looked into your code) how is runtime (framerate) affected? |
|
@gzotti I think framerate feels like the same as usual on my M3 macbook but I am no expert. For 2000BC, -2000-1-1 Arcturus
Vega
Polaris
Just another sanity check my experimental catalog, using PanStarr-1 as background for high proper motion stars HIP 1338 Stellarium (
Stellarium 24.3 place HIP-1338 not quite accurately at the position with the correct date or not. |
|
That new branch seems to correspond much better to SkyChart's values. Not sure I did anything wrong or if it's because this is WIP, but I get a few mag 0 stars scattered across the sky (e.g. just beside the Big Dipper):
Also, many stars seem to be blueish. I see no performance difference across the millennia. It is great to have magnitude decimal values that don't always end in 0 or 5. |
|
@Atque Yes it is WIP. Many star has 0 mag because they Don't have V-mag in Hipparcos-1/2 nor they have G-mag and BP-RP from Gaia DR3 to estimate their V-mag . So 0 mag is filled for them currently. Many star are blue-ish because all of the stars in the catalog are assigned spectral class B(e) because WIP. But thanks for letting me know! |
|
The table above gives RA/Dec etc as such. Do you still use the fast vectors or compute vectors on the fly? EDIT: Also the already limited usability on RPi3 will then likely be over. |
|
@gzotti compute vectors on the fly. I have also added 3D astrometry propagation in a new function |
|
Well, if you change the format of files then why not to do add a radial velocity also to make a correct 3D proper motion? |
|
Would that not require full 3D work? (parallax-->distance, angular PM-->linear PM, 3D PM, recreate angular coordinates.) Could that be vectorized (e.g., OpenCL)? |
|
I will make a more polished works in the next few weeks and make another PR for comments & performance considerations (I Don't think I will put performance as a top priority for now as a prototyping). Thanks everyone for checking and suggestions. I guess this PR can be closed? Because it seems to be a bad idea to proper motion equation in its current state. |
|
Yes, I think the original PR here is technically flawed as described, but your new catalog looks much more interesting. When all data are available (mag, color, ...), we will have a thorough look. I would like to keep at least minimum catalog for RaspberryPi3 (1GB RAM) which is why I am slightly concerned about the obviously higher memory footprint (and maybe higher CPU load). In the worst case we might still have to support both catalog formats. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Maybe the first step towards supporting several catalogs? |
|
Maybe, but what for, exactly? All catalogs will have to support HIP numbers, given their additional use in all skycultures. If this new development runs as smoothly as the current one on all platforms, we can toss the old one. The current dense packing however, with only delta position vectors relative to zone center, is really well designed. (It's to be kept if RPi3 and similar "minimal systems" does not support the new format. Or do something like allowing to discard Gaia number when loading the higher levels.) |
|
The whole 6D (3D position and 3D velocity) astrometry propagation is working now! They are fully propagated when you select a star to display information string, so not only RA/DEC but proper motions & radial velocity & parallax also properly calculated at epoch T. Otherwise only 3D position are computed (from 6D astrometry) for every stars with full 6D astrometric solution to reduce computation (so new pmra, pmdec, parallax, radial velocity are not computed actually if a star is not selected). For stars without full 6D astrometry, only pmra, pmdec are used to compute RA/DEC Catalogs are still in work-in-progress (many stars still with wrong magnitude and with wrong spectral classes). But the new prototype catalogs with radial velocity added for data type 0 catalog are at: https://www.astro.utoronto.ca/~hleung/shared/stellarium_new_catalog/trial1/. The snapshot you can try and works at least for now is At least for Arcturus at BC10000, we are in agreement at 0.01 deg! But Skychart did not update the PMRA/PMDEC/Parallax/Radial Velocity at time T but stellarium now does (in case someone want to know the full 6D astrometry of Arcturus 12000 years ago with stellarium)!
An interesting object to look at is Barnard's Star with this new funcationality. Its information string properly shows its closest encounter to Earth at around year 11727 with zero radio velocity and very high proper motions and higher parallax as one expects at the closest encounter. 
|
|
Do you actually show the parallax shift when drawing the stars? Or only for the selected? |
|
@gzotti If you are asking about the annual parallax effect, then the answer is no (the code is there but not doing anything). Because the effect is so small even for proxima centeuri, maybe good to keep the code for educational purposes but waste of cpu time IMO. Here is a video showing Proxima centeuri movement (parallax + proper motions) if it has parallax angle 100 times what it has in real life (i.e. 100 times what it is showing in the info string in the video). Untitled.movIf you are asking about if drawing the brightness of stars took time-varying parallax into account because the stars move closer/further, the answer is also no. But the latest commit of the P.S. I just realize the parallax to proxima centeuri is wrong in the catalog, because it's parallax of 768.0665 * 100 (in 10 uas unit) is larger than the max value of uint16 used in the catalog, but the effect being small still stand. |
|
The distance to Proxima is also wrong. It is given at 28.94 ly, which is almost ten times larger than the accepted value of 4.2 ly. Also, I noticed stars are not drawn with their changed magnitude (Zeta Herculis is a great example in 100,000 AD), but remains the same despite the infostring giving a more correct value. |
|
Pity. It may not be relevant for 98% of users who are just stargazing today's skies. But for those either researching prehistory (and want "all" stars in view at their correct locations) or teaching/explaining just those effects, it would be great if this could still be done, admitted with certainly slower frame rate. Both effects, brightness change by distance change, and the parallax motion (with option to increase it e.g. upto 100x), would be most welcome. So, there should be a flag in the Sky settings "Show proper motion/parallax: Selected star only/All stars (slow)". Not sure about the best solution of the uint16 problem. How much do we lose if you just divide all by 4 (or 10 or whatever required to avoid such overflow) for storage? This is what was done in the previous catalog to exploit the available bits. Or even log() it, so that close objects are more accurate. (But the call is probably too costly to be really beneficial.) |
|
I agree with Georg. Stellarium is a tool for observation, but also and above all a great, highly visual tool for teaching and archaeoastronomy. If you can do it, it would be really interesting. Perhaps you could add a checkbox for long-term calculations and warn users that the reaction is less real-time. |
|
Probably the brightness change poses a problem given the brightness cut-off as drawing criterion. It would require finding the largest of all brightness changes ±100.000 years from J2000 and then setting a higher catalog-brightness cutoff to begin with, checking current magnitude of all stars another time before actually drawing. Again, I think this is acceptable for those on stronger PCs with this demand for spanning millennia, as long as framerates remain interactive. If too demanding, inhibit the accurate calculation during mouse interaction or zooming. And then again, vectorizing with OpenCL or so could be a way to speedup. |
|
You can try the latest commit https://github.com/henrysky/stellarium/tree/f238e5c8e43a3e1a3c9959a35fcc0d5e7d58c298. This new trial version of star catalog also took computational performance into consideration, so not to do that many expensive trigonometric operations in Stellarium. The star catalog for that commit is at https://www.astro.utoronto.ca/~hleung/shared/stellarium_new_catalog/trial2/. Spectral types are added but I am still dealing with binary stars (I think at least ~2000 of them brighter than 9 mag are missing). @Atque The latest commit also draw the stars in respond to changing magnitude in the future/past. The brightness cut-off issue mentioned by @gzotti is taken care of (at least I think so) @gzotti I think the parallax effect can be another wishlist issue/PR after the new star catalog. Most stars currently in the missing stars plugins (https://github.com/Stellarium/stellarium/blob/master/plugins/MissingStars/resources/missingstars.json) should not be missing anymore without the plugins. |
|
@henrysky Just a notification - after creating a new stable star catalog the version of parts should be increased (e.g. |
Good news! This plugin was added as temporary solution and it can be removed after introducing new catalog. |
|
@henrysky Great work. Are you intending for binary stars to orbit oneanother, or is that out of the reach of this work? |
|
A quick check the new branch in Windows - Stellarium can't read the new format of catalogs :-/ |
|
@alex-w What is the error message? Did you use that specific commit in my comment? I've re-arranged the star catalog code a bit since that commit (https://github.com/henrysky/stellarium/tree/f238e5c8e43a3e1a3c9959a35fcc0d5e7d58c298) for the data struct memory alignment. @Atque I think it is out-of-reach but sure can take a look if I have time. Althought in the context of the new star catalog, my opinion is binary/multiple stars system maybe should not have their position updated from proper motion or 6D astrometry because it will just yield wrong result. |
Part 1: Part 2: I think you should open a new pull request (as a draft at the moment) and close this one as outdated. |
The garbled message here, "╬Єърчрэю т фюёЄєях", is "Отказано в доступе", i.e. "Access denied". Is your file actually accessible? |
Yes, of course. The main problem here is no stars in the sky :) P.S. I'll check it in linux tonight, but before I see no problem for new star catalog branch |
|
@alex-w I had the same problem using @henrysky 's latest commit, but the one he linked works fine. @henrysky Proper motion for double stars ought not be ignored completely, otherwise Alpha Centauri will be off a fair bit in a few hundred years. Maybe hiding the other component would be possible, so that they don't drift apart. |
|
For this the components would have to be marked as belonging together, maybe in an external file. The optimal solution would be to have WDS entries with well-enough known orbits completely taken out and handled separately, showing their orbits around a mutual centre of gravity at catalog position (or at least secondary orbiting around primary). This can be done as next improvement and would be simply awesome for binary observers. When we know what to do to create a star catalog (documented working toolchain and public catalogs), it may be simple enough to then just recreate another copy of this new catalog without these WDS entries. (Just that all HIP indexing and search has to be adapted to all star subclasses etc.) |
|
Hi all, the latest commit has included the new star catalogs and catalog config file for testing in the branch (so you can download in stellarium for the extra star catalogs all the way down to mag~18 hosted on my department web server so be careful not to repeatedly download the catalogs unneccessarily). This version of catalogs have ~220 millions stars in total, color of the stars are fixed (so most of them are not blue-ish anymore), and B-V color are now computed from synethetic photometry with ~4TB of Gaia low-resolution spectra. Please take a look and report any issues/comments/suggestions! Thanks! I will upload the code to generate the new catalog here: https://github.com/henrysky/stellarium_star_catalogs. Give me a few days to organize. I am closing this because it is superseded by #3992 |
Description
This PR fixes the issue of reading proper motion for the main catalog and issue of errorous calculation of RA/DEC with proper motion (equation is wrong).
My understanding of the past issue regarding proper motion is that the pmra/pmdec values in the catalog can not be decoded properly(?). But it seems to me the catalog proper motion are simply pmra and pmdec in the unit of 0.1 mas/yr. I've picked a few HIP stars and seem to check out.
Now this PR simply read the pmra/pmdec from the catalog and use it to calculate RA/DEC at any date. IMO this is a good temporary solution until new catalog arrives.
I kept the extra proper motion data in the repository but they are not used to display nor calculation.
Fixes #85 (issue), #1061 (partially)
Screenshots (if appropriate):
Type of change
How Has This Been Tested?
Nutation, Abberation and atmosphere are turned off!!
Compared to SIMBAD on high proper motion stars Proxima Centauri and Barnard's star.
On the issue of Proxima Centauri from #1061, here are the comparison
On 1 Jan 2000
so Proxima Centauri is off by RA/DEC +4.64s/+6.34s to begin with between Stellarium catalog and Gaia DR3 regardless if proper motion is done correctly.
on 22 Apr 2020
Another case: Barnard's star. Its J2000 RA/DEC on 2000-Jan-1 are very accurate already in stellarium.
On 19 Nov 2024
The display of proper motions seems fine, just a bit off due to using old ata compared to precise Gaia.
Test Configuration:
Checklist: