Hi,
Using latest ajtribrick's catalog, I want to update "Iota Leo B" (spectral type) but I cannot !
why ?
I tried by tyc name (TYC 858-1221-2) but it didn't work.
Help...
Updated stars.dat including Gaia EDR3 data (update 2022-03-03)
There's no reason why the stars.dat file would prevent modification via the .stc file.
"It didn't work" is not useful for diagnosing the issue.
We don't know what your .stc file looks like.
We don't know what the console log looks like in Celestia, maybe it indicates errors in your file.
We don't know what other add-ons you have installed that might be overriding your changes.
"It didn't work" is not useful for diagnosing the issue.
We don't know what your .stc file looks like.
We don't know what the console log looks like in Celestia, maybe it indicates errors in your file.
We don't know what other add-ons you have installed that might be overriding your changes.
none error and none update...It didn't work" is not useful for diagnosing the issue.
OMG, you're right.We don't know what your .stc file looks like.
Code: Select all
Modify 2012210858 "New_name"
{
SpectralType "G1V"
AbsMag 5.0
}
None log file is present in the main directory (W10 64b)...We don't know what the console log looks like in Celestia, maybe it indicates errors in your file.
No another addon with these datas (after global search).We don't know what other add-ons you have installed that might be overriding your changes.
Soft: Celestia 1.6.2
PC : Intel Core i9-9900K (4 GHz) , Chipset Z390 Exp, RAM 32 Go DDR4 3000 Mhz, SSD M.2 512 Go + HDD 3 To, MSI GeForce RTX 2080 8Go - W10 64b
I lost my old user, so with us: since more 12 years
=> It is by doubting everything that everybody approaches the truth !
PC : Intel Core i9-9900K (4 GHz) , Chipset Z390 Exp, RAM 32 Go DDR4 3000 Mhz, SSD M.2 512 Go + HDD 3 To, MSI GeForce RTX 2080 8Go - W10 64b
I lost my old user, so with us: since more 12 years
=> It is by doubting everything that everybody approaches the truth !
TYC 858-1221-2 is not present in the Gaia tycho2_best_neighbour table on the Gaia archive which I use for the source selection. It's therefore not present in the stars.dat file.
The star in question is defined in visualbins.stc, where it is NOT assigned a Tycho number. The issue you report has nothing to do with this add-on, and would still occur with the base stars.dat file distributed with Celestia.
If you're going to report bugs in this stars.dat file, please check all of your .stc files first!
(Incidentally the console I was referring to is the one you see in Celestia when you press the ~ key)
The star in question is defined in visualbins.stc, where it is NOT assigned a Tycho number. The issue you report has nothing to do with this add-on, and would still occur with the base stars.dat file distributed with Celestia.
If you're going to report bugs in this stars.dat file, please check all of your .stc files first!
(Incidentally the console I was referring to is the one you see in Celestia when you press the ~ key)
TY for your return ajtribick ! 
Your second sentence has opened my eyes on a solution.
I tried to put entirely the designation and it was OK.
Your second sentence has opened my eyes on a solution.
I tried to put entirely the designation and it was OK.
Code: Select all
Modify "Tsze Tseang B:IOT Leo B:78 Leo B:ADS 8148 B:CCDM J11239+1032B"
{
SpectralType "G1V"
AbsMag 5.0
}
Soft: Celestia 1.6.2
PC : Intel Core i9-9900K (4 GHz) , Chipset Z390 Exp, RAM 32 Go DDR4 3000 Mhz, SSD M.2 512 Go + HDD 3 To, MSI GeForce RTX 2080 8Go - W10 64b
I lost my old user, so with us: since more 12 years
=> It is by doubting everything that everybody approaches the truth !
PC : Intel Core i9-9900K (4 GHz) , Chipset Z390 Exp, RAM 32 Go DDR4 3000 Mhz, SSD M.2 512 Go + HDD 3 To, MSI GeForce RTX 2080 8Go - W10 64b
I lost my old user, so with us: since more 12 years
=> It is by doubting everything that everybody approaches the truth !
-
pirogronian
- Developer
- Posts: 234
- Joined: 05.01.2018
- Age: 38
- With us: 6 years 11 months
- Location: Wrocław
- Contact:
ajtribick wrote:Here are the Python scripts for generating a stars.dat from the Gaia DR2 data
Hi ajtribick! I tried to read Your script to understand how Celestia index number is generated (for stars outside HIP and TYC) but failed (I'm not familair with Python). Could you describe it shortly? It looks like (from runtime Celestia' analysis) these numbers are dispersed rather than packed. I wonder if densly packaging of index numbers would be the best options for fast indexing code to use minimum memory.
Still formally developer, but too tired to develop. I feel sad, but Celestia is going forward despite it.
Btw, the universe is ruled by electricity.
Btw, the universe is ruled by electricity.
Well this add-on only includes HIP or TYC stars, so it's not going to be very informative about how stars outside these catalogues are represented. To figure out how non-HIP/TYC stars are handled, you need to look at the Celestia source code.
The general rules for Celestia IDs, which are represented as 32-bit unsigned integers:
0 = the Sun
1–999999 = HIP stars
1000000–0xf0000000 = TYC stars
0xf0000001 –0xfffffffe = non-HIP/TYC stars
0xffffffff = invalid ID
For TYC stars TYC1-TYC2-TYC3, the ID is computed by TYC3×1000000000+TYC2×10000+TYC1.
The stc parser generates new stars starting at ID 0xfffffffe (4294967294) and going downwards.
This approach has certain limitations, in particular most HIP stars are also TYC stars, and there's no way to represent this. Internally Celestia re-sorts the data on startup into an octree structure, so the indices are going to end up all over the place anyway regardless of whether the index is dense or not. I had some thoughts towards an implementation that addresses some of these issues (in particular, using natural keys is basically unworkable in the Gaia era) but never got around to implementing it.
The general rules for Celestia IDs, which are represented as 32-bit unsigned integers:
0 = the Sun
1–999999 = HIP stars
1000000–0xf0000000 = TYC stars
0xf0000001 –0xfffffffe = non-HIP/TYC stars
0xffffffff = invalid ID
For TYC stars TYC1-TYC2-TYC3, the ID is computed by TYC3×1000000000+TYC2×10000+TYC1.
The stc parser generates new stars starting at ID 0xfffffffe (4294967294) and going downwards.
This approach has certain limitations, in particular most HIP stars are also TYC stars, and there's no way to represent this. Internally Celestia re-sorts the data on startup into an octree structure, so the indices are going to end up all over the place anyway regardless of whether the index is dense or not. I had some thoughts towards an implementation that addresses some of these issues (in particular, using natural keys is basically unworkable in the Gaia era) but never got around to implementing it.
ajtribick wrote:If there's a catalogue listing extragalactic members of the TYC2 catalogue it'll probably be worth excluding such objects. If not, I guess it's a case of waiting to see what EDR3 looks like.
I don't feel that this is the most elegant option, but I just started experimenting with SIMBAD's TAP Service. I think it's theoretically possible to extract a list of stars that are 1) in the TYC catalogue, 2) listed as "children" of the LMC or SMC, with 3) probabilities percentages between 0 and 100.
SIMBAD might help in some cases. I do note that the first star I checked, S Doradus is not listed as a child of the LMC, so it isn't going to remove 100%.
SIMBAD might also help with the cross-match issues, although things are complicated by binary and multiple star systems. I've seen multiple cases where a HIP designation is present in SIMBAD at a higher level of the system hierarchy while Gaia designations are assigned to individual stars. In general, binaries/multiples are a complete pain to deal with which is why I didn't go down that route. It might be something I look into in more detail for future releases if I get round to doing any.
SIMBAD might also help with the cross-match issues, although things are complicated by binary and multiple star systems. I've seen multiple cases where a HIP designation is present in SIMBAD at a higher level of the system hierarchy while Gaia designations are assigned to individual stars. In general, binaries/multiples are a complete pain to deal with which is why I didn't go down that route. It might be something I look into in more detail for future releases if I get round to doing any.
I've updated the generation scripts with a much more comprehensive HIP2-Gaia DR2 cross-index, plus I'm using SIMBAD to fill in some of the blanks in the catalogue.
Since I'm now a lot happier with the cross-matching I've decided fairly arbitrarily to bump this to version 1.0.0 and drop the alpha.
Links at the start of the thread.
Since I'm now a lot happier with the cross-matching I've decided fairly arbitrarily to bump this to version 1.0.0 and drop the alpha.
Links at the start of the thread.
Amazing, bravo ajtribick ! 
Soft: Celestia 1.6.2
PC : Intel Core i9-9900K (4 GHz) , Chipset Z390 Exp, RAM 32 Go DDR4 3000 Mhz, SSD M.2 512 Go + HDD 3 To, MSI GeForce RTX 2080 8Go - W10 64b
I lost my old user, so with us: since more 12 years
=> It is by doubting everything that everybody approaches the truth !
PC : Intel Core i9-9900K (4 GHz) , Chipset Z390 Exp, RAM 32 Go DDR4 3000 Mhz, SSD M.2 512 Go + HDD 3 To, MSI GeForce RTX 2080 8Go - W10 64b
I lost my old user, so with us: since more 12 years
=> It is by doubting everything that everybody approaches the truth !
New release v1.0.1.
I've eliminated a few duplicate entries that were matched to the same Gaia ID, improved the SAO cross-index and incorporated some corrected spectral types. In particular, 19 Piscium is now included as a carbon star.
I am hoping this will be the last update until EDR3, but who knows.
Links at the start of the thread.
I've eliminated a few duplicate entries that were matched to the same Gaia ID, improved the SAO cross-index and incorporated some corrected spectral types. In particular, 19 Piscium is now included as a carbon star.
I am hoping this will be the last update until EDR3, but who knows.
Links at the start of the thread.
Hi ajtribick.
After installing the v1.0.1, I noticed very suspicious "blue stellar patches" in the Galaxy when setting the magnitude limit to 15.2. To my surprise, I determined that this new version created a large number of stars with spectral type "O". Was this intentional like, for example, the result of some estimated extinction? In the image below, the green squares mark stars of spectral type "O", with one example selected.
After installing the v1.0.1, I noticed very suspicious "blue stellar patches" in the Galaxy when setting the magnitude limit to 15.2. To my surprise, I determined that this new version created a large number of stars with spectral type "O". Was this intentional like, for example, the result of some estimated extinction? In the image below, the green squares mark stars of spectral type "O", with one example selected.
- Attachments
-
Ok, yes, you got me, I am sitting here going "mwahahaahaaa I am going to set a bunch of stars to O-type to mess with Fafers-br."Fafers_br wrote:Was this intentional
Back to being serious, I think I found the issue here: when I passed through the ASCC spectral types, a bunch of missing entries ended up being converted to "0.0" for some reason. Because of a couple of typos in the source catalogues, I interpret a spectral type beginning with "0" as "O", so this ends up spuriously converting these spectra to "O".
Fortunately the fix is fairly simple. Looks like there will be a 1.0.2...
(Spectral type for TYC 4094-2626-1 reverts to being guessed from the magnitudes, which results in it being inferred as G9)
Quick guide on how to check these kind of issues:
Go to the SIMBAD Query by identifier page, query for "alf Cas"
This brings up the entry for the star.
Near the bottom of the page there is a section called "External archives". This lists the star's entry in various catalogues.
Click the link titled Gaia DR2 418551920279473536.
Take a look at the parallax listed there (and its error). This might give you some idea of what's going on.
Note that the distances in stars.dat are not simple 1/parallax. For Gaia stars, the relevant catalogue is the Gaia Geometric Distance Catalogue, which can be queried on the Gaia Archive website.
Click Search, then select "Advanced (ADQL)".
Enter the following query
You will see a result with 1 row. There is a small icon which looks like a table, which shows a tooltip "Display top 2000 results". Click it.
Take a look at the value in the r_est column, which contains the estimated distance in parsecs.
Go to the SIMBAD Query by identifier page, query for "alf Cas"
This brings up the entry for the star.
Near the bottom of the page there is a section called "External archives". This lists the star's entry in various catalogues.
Click the link titled Gaia DR2 418551920279473536.
Take a look at the parallax listed there (and its error). This might give you some idea of what's going on.
Note that the distances in stars.dat are not simple 1/parallax. For Gaia stars, the relevant catalogue is the Gaia Geometric Distance Catalogue, which can be queried on the Gaia Archive website.
Click Search, then select "Advanced (ADQL)".
Enter the following query
Code: Select all
SELECT *
FROM external.gaiadr2_geometric_distance
WHERE source_id = 418551920279473536You will see a result with 1 row. There is a small icon which looks like a table, which shows a tooltip "Display top 2000 results". Click it.
Take a look at the value in the r_est column, which contains the estimated distance in parsecs.
- Spoiler
- The Gaia DR2 parallax for this star is really bad, probably because it's a bit too bright for Gaia to measure reliably, at least using the Gaia DR2 pipeline.