How do I replace a star which is in stars.dat?

[Chuft-Captain]

Hi,

I've noticed that many binary systems in Celestia are only represented as a single star with the B component missing. (I assume this is because of limited knowledge of it's orbital parameters).
I'd like to override the stars.dat definition of some of these with my own definition of a Barycenter with 2 stars in a .STC file, using whatever information I can lay my hands on (and a bit of artistic licence for the rest).

I want to make sure that I replace the original star with an equivalent definition, and place the barycenter at the same position as the original star, but I have no way of seeing what the current defn. is because it's not in an STC file.

Th only tool I'm aware of that can retrieve or modify the contents of stars.dat is the Mostly Harmless MySQL tool.

Is there any easier way?

Cheers
CC

[selden]

One option is to use RA & Dec values obtained from Simbad: don't worry about them being precisely what's in Stars.dat.

Another is to use the Lua EduTools, which can display the RA & Dec of a selected object.

Or you could download stars.txt from SourceForge. The star positions are specified in Celestia's internal xyz coordinate system.

[Chuft-Captain]

Thanks Selden,

Just running Celestia 1.5.0 without any changes (which presumably uses the coordinates in stars.txt/stars.dat), VV Cep seems to be correctly located in the Cephus constellation (the green marker is The Garnet Star, the red one is VV Cep):


however, if I use the SIMBAD defined RA and DEC, it ends up in Cassesopeia:


There seems to be something strange going on with the SINBAD values, or I'm misinterpreting them.

I'm not quite sure what you mean by XYZ coordinates... it seems to me that the stars.txt format:

Code: Select all

108317  329.1631006 63.62556651 8154.17488 5.10938 M2

is in equatorial format (RA,DEC,dist), because if I just plug the 329.1631006 and 63.62556651 from stars.txt straight into my STC, then it's again correctly located in Cephus and then the value of 8154.17488 explains the displayed distance of 2.5Kparsecs.

However, from what I've read, this distance seems extreme.
I know that a lot about this system is difficult to determine accurately (including distance), but from what I have read, a value of 2400 ly's seems to be more appropriate. See for example: http://www.astro.uiuc.edu/~kaler/sow/vvcep.html

Here's the STC: http://traitorsclaw.sitesled.com/projects/VV%20Cep/cc_VV%20Cep%202.stc
( I've tried to estimate reasonably realistic values for the mass-ratios, SMA, and Eccentricity, based on the limited information that's known, and I've used arbitrary values for the other 4 elements. )

Any comments, criticisms are very welcome.

PS. Here's what it would look like if Saturn was in this system (Jupiter's orbit would be engulfed by the super-giant):

Notice the difference in size between the super-giant A component (10 au's away) and the B component (at 26 au's).

[selden]

CC,

Don't forget that Celestia's STC catalogs require RA to be specified in fractional degrees, not in fractional hours. i.e. multiply hours by 15. Simbad specifies RA in hours.

I know that the values in stars.dat are in cartesian coordinates. Celestia uses cartesian coordinates internally. The change of format in stars.dat was made in order to eliminate the differences in star positions caused by different platforms' math libraries translating polar coordinates into cartesian coordinates slightly differently. That conversion now is precalculated so all platforms get the same positions. I've never looked at stars.txt, and assumed it used xyz, too. You know what making assumptions does...

I don't know why the large difference in distance, though. Celestia should be using whatever value was measured by Hipparcos. I'll have to refer you to the papers referenced on the Simbad server. I suspect one or more of them will discuss this issue.

[Chuft-Captain]

CC,

Don't forget that Celestia's STC catalogs require RA to be specified in fractional degrees, not in fractional hours. i.e. multiply hours by 15.

Well, that would explain the SINBAD discrepancy. (sinbad's 21.94419444 x 15 = 329.1629166). Celestia's value is: 329.1631006
That's close enough for me!

How do you manage to remember all the little details Selden?

Cheers
CC

[selden]

How do you manage to remember all the little details Selden?

Cheers
CC

'Cause I've answered that question over and over and over and....

note my edits to my previous post.

[Chuft-Captain]

I don't know why the large difference in distance, though. Celestia should be using whatever value was measured by Hipparcos. I'll have to refer you to the papers referenced on the Simbad server. I suspect one or more of them will discuss this issue.

Unfortunately I can't read anything but the abstracts of any of those articles. All the detailed articles I've tried to read at Springerlink for example require a logon or a purchase of the full article.

I suspect that Celestia may actually be calculating the distances based on the appmag...

Two of the most magnificent, and largest, stars of the sky lurk close together and rather anonymously within the dark interstellar dust clouds of Cepheus (the King): Herschel's Garnet Star (Mu Cephei) and the extraordinary variable and binary, VV Cephei. Both are huge red supergiants. Mu Cep stands at only fourth magnitude (4.08), VV fainter at fifth (4.91). Were it not for the dimming effects of the dust, they would respectively shine at second (1.97) and third (2.91) and might have been parts of the formal constellation

ie. If as I suspect, Celestia is calculating the distances based on the published appmag (and as far as I'm aware, the effect of dust clouds is not simulated in Celestia), then that may well explain the extra distance. (4.91 - 2.91 = 3 magnitudes difference, which could account for the extra 5-6000 extra light-years I guess)

Perhaps one of the devs would clarify whether distances are calculated from appmags, or compiled from catalogs.
(If calculated strictly from appmags without consideration for intervening dust clouds, then a lot of objects, although appearing in their correct positions in the night sky when viewed from Earth, could be many thousands of parsecs out of position)

[selden]

I suspect that Celestia may actually be calculating the distances based on the appmag...

The ~112000 stars in Celestia's stars.dat have distances which were measured by the Hipparcos satellite, which typically have errors much less than 5%, although some are more. See the Hipparcos web site for details. If you are using the 1,000,000 or 2,000,000 star Addons, however, their distances are estimates determined by using the spectrographic method, which can be much less accurate.

[Chuft-Captain]

I suspect that Celestia may actually be calculating the distances based on the appmag...

The ~112000 stars in Celestia's stars.dat have distances which were measured by the Hipparcos satellite, which typically have errors much less than 5%, although some are more. See the Hipparcos web site for details. If you are using the 1,000,000 or 2,000,000 star Addons, however, their distances are estimates determined by using the spectrographic method, which can be much less accurate.

Not using any extra stars, but that's good to know about.
Still wouldn't explain the 8154.17488 value however, as that was in stars.txt from sourceforge. Maybe it's just an error in the Hipparcos catalog. (The number of decimal points is suggestive of a "calculated" value).

Apparently Hipparcos was only able to measure parallax angles for stars up to about 1,600 light-years away, so perhaps for more distant stars such as this one, they used the spectrographic method, which would explain the discrepancy. http://en.wikipedia.org/wiki/Parallax#Computation

I assume Chris, Grant or Fridger is aware of this issue.

[ajtribick]

Usually in cases of wrong distances in stars.dat the culprit is the CCDM code which puts binary stars at the same distance, but that doesn't appear to be the case here.

Unfortunately it seems that the modifications made to the Hipparcos data (e.g. the CCDM code) are not documented.

[chris]

Usually in cases of wrong distances in stars.dat the culprit is the CCDM code which puts binary stars at the same distance, but that doesn't appear to be the case here.

Unfortunately it seems that the modifications made to the Hipparcos data (e.g. the CCDM code) are not documented.

Well, there's buildstardb.cpp, which is documentation of a sort. But, this program should be rewritten to fix the CCDM problem. Besides the adjustment for stars that it thinks are gravitationally bound, the only other adjustment is a one-off correction for the spectral type of Capella (listed in the catalog as M1.)

As for why the distance of VV Cep is so far off, there's no great mystery:

http://simbad.u-strasbg.fr/simbad/sim-i ... =submit+id

The parallax is 0.39 mas (reference is HIPPARCOS), which gives a distance in the neighborhood of 8000 light years. The error in the parallax is larger that the parallax itself, so this star should probably be rejected during catalog generation.

--Chris

[chris]

Here's a paper on the new reduction of the HIPPARCOS data set, claimed by the author to be much more accurate for all stars brighter than magnitude 8:

http://arxiv.org/abs/0708.1752

--Chris

[Chuft-Captain]

The error in the parallax is larger that the parallax itself, so this star should probably be rejected during catalog generation.

Yeah, I noticed that too.

The "good" news is...

While the various parameter ranges are unfortunately large (showing how hard it is to study such rare stars), it is clear that the supergiant (now probably fusing helium into carbon in its deep core) will "soon" blow up as a grand supernova

... This should make determination of it's position a lot more accurate!

hehe