stars.txt

[t00fri]

Hi all,

I committed my latest visualbins.stc and spectbins.stc binary database files, the corresponding PERL scripts and a modification of Changelog to CVS.

Bye Fridger

[Cham]

Thanks Fridger.

So, now lets move on...

[granthutchison]

Go to EPS Ind, EPS Ind A (HIP 108870) has no orbit (perhaps because EPS Ind B is a barycenter?)

Folks, I did try to leave documentation in the stc before I left.
You'll find the barycentre for the Eps Ind system (among others) is marked up with an explanation, and a hint as to how it was placed:

Code: Select all

Barycenter "EPS Ind:Gliese 845" # orbit of A & B components unknown
{
   RA 330.841091   # mass ratio 0.77:(0.04+0.03)
   Dec -56.780045
   Distance 11.824
}

For many widely separated systems we have no orbit at all. But simple physics tells us where the barycentre is. And the obvious place to put the name of the star system is on the barycentre, so nearstars.stc contains a number of barycentres, correctly placed, carrying the star system name, but with no orbits defined because no orbits are known. The components are then labelled A, B; Aa, Ab; Ba, Bb in the usual hierarchical system.
This can be changed if it's a problem.

Grant Hutchison

[granthutchison]

There's another possible solution: we can actually make the object with catalog number xxxx the barycenter instead of the A component.

When a system has a single Hip number, Simbad retrieves both the system and the A component, so either approach seems to be acceptable.
Some systems, like 61 Cyg, have a separate Hip designation for each component, so some care would be required to deal with that situation. However, the more distant the system the less likely we are to find both a good orbit and separate Hip designations.

Grant has used 'name A-B' to indicate barycenters in complex multiple systems in nearstars.stc

Not that I recall or can find. If so, it's a mistake. As I wrote in my previous post, the logical approach seems to be to assign the "pure" system name to the barycentre, and then appropriate code letters to the individual components and their sub-barycentres.

If it's desired, I'll shift Hip designations to the barycentres in nearstars.stc.

Grant

[t00fri]

There's another possible solution: we can actually make the object with catalog number xxxx the barycenter instead of the A component.

When a system has a single Hip number, Simbad retrieves both the system and the A component, so either approach seems to be acceptable.
Some systems, like 61 Cyg, have a separate Hip designation for each component, so some care would be required to deal with that situation. However, the more distant the system the less likely we are to find both a good orbit and separate Hip designations.

Grant has used 'name A-B' to indicate barycenters in complex multiple systems in nearstars.stc

Not that I recall or can find. If so, it's a mistake. As I wrote in my previous post, the logical approach seems to be to assign the "pure" system name to the barycentre, and then appropriate code letters to the individual components and their sub-barycentres.

If it's desired, I'll shift Hip designations to the barycentres in nearstars.stc.

Grant

Grant,

the changes that were done only refer to binaries that don't have a proper name, but only a HIP number. So no modifications are required e.g for 61 Cyg.

Without Chris' proposal, the barycenter was NOT selectable for those cases where there was only a HIP number and NOT a proper name. Simbad was of less importance here (it mostly worked as you wrote).

Now things really work well.

Bye Fridger

[granthutchison]

the changes that were done only refer to binaries that don't have a proper name, but only a HIP number. So no modifications are required e.g for 61 Cyg.

Well, if Hip designations are to reside on the barycentre for the practical reasons you give in some cases, shouldn't this be standardized across all the defined binary orbits?

I also wonder if you have any mechanism at present, when preparing your binary star files, to check if the secondary has a separate Hip designation before you assign the primary Hip designation to the barycentre. My recollection is that the secondaries are not very well coded in the datasets you're using for reference.

Grant

[chris]

Grant has used 'name A-B' to indicate barycenters in complex multiple systems in nearstars.stc

Not that I recall or can find. If so, it's a mistake. As I wrote in my previous post, the logical approach seems to be to assign the "pure" system name to the barycentre, and then appropriate code letters to the individual components and their sub-barycentres.

There are a few systems in nearstars.stc, for example 36 Oph. It appears that 36 Oph is the barycenter of a trinary system, and 36 Oph A-B is the barycenter of the stars 36 Oph A and 36 Oph B (although the orbits around the barycenter 36 Oph A-B aren't actually known.)

--Chris

[granthutchison]

There are a few systems in nearstars.stc, for example 36 Oph. It appears that 36 Oph is the barycenter of a trinary system, and 36 Oph A-B is the barycenter of the stars 36 Oph A and 36 Oph B (although the orbits around the barycenter 36 Oph A-B aren't actually known.

Ah, you're right, I've found them now. I'd forgotten there were a few systems in there that are usually described with (AB)C components, rather than (AaAb)B. So there is a requirement for the occasional AB barycentre, to differentiate it from the system barycentre.

Grant

[ajtribick]

Sorry to dredge this thread up again, but it seemed to have gone rather off-topic at about page 4 from the original discussion of the erroneous multiple star groupings (from CCDM listing optical doubles) into a discussion about conflicts between various binary stars files.

Meanwhile the CCDM issue seems to have been forgotten. It looked as though there was some kind of tentative consensus (round about page 3) on removing the CCDM grouping code from buildstardb.cpp but this does not seem to have happened in the intervening time.

[chris]

Sorry to dredge this thread up again, but it seemed to have gone rather off-topic at about page 4 from the original discussion of the erroneous multiple star groupings (from CCDM listing optical doubles) into a discussion about conflicts between various binary stars files.

Meanwhile the CCDM issue seems to have been forgotten. It looked as though there was some kind of tentative consensus (round about page 3) on removing the CCDM grouping code from buildstardb.cpp but this does not seem to have happened in the intervening time.

Right, that's still the plan. I haven't gotten around to modifying buildstardb.cpp yet because of other development priorities. It remains on my todo list though. If anyone wants to tackle this, the help would be most welcome.

--Chris

[ajtribick]

Ok, I'll take a look at it.

[chris]

Ok, I'll take a look at it.

You'll also notice that buildstardb.cpp contains an #ifdef'd out block of code that is the missing HD to HIPPARCOS cross index builder. This should really be a separate tool.

--Chris

[ajtribick]

It might be best to have all the star cross-index generators as PERL scripts that output a file that can then be processed by makexindex.cpp...

[chris]

It might be best to have all the star cross-index generators as PERL scripts that output a file that can then be processed by makexindex.cpp...

Or just eliminate makexindex.cpp altogether. It doesn't do anything other than convert the ASCII integers to a binary format. This could be done in the same Perl script that generates the cross index.

--Chris

[ajtribick]

Taking a look at this, there are apparently two versions of buildstardb.cpp: one in src and one in src/tools. However it looks as if neither of these is actually used to create the star databases - the format is different (I suspect this is the old version of the database builder).

So two questions: firstly, why are these files still floating around in the trunk, and secondly what is the actual code used to generate the star database?

[chris]

Taking a look at this, there are apparently two versions of buildstardb.cpp: one in src and one in src/tools. However it looks as if neither of these is actually used to create the star databases - the format is different (I suspect this is the old version of the database builder).

So two questions: firstly, why are these files still floating around in the trunk, and secondly what is the actual code used to generate the star database?

The file in src is more recent. It should be moved to src/tools/stardb and src/tools/buildstardb.cpp should be removed from the repository (it hasn't been modified since 2001.)

buildstardb generates an old format binary file. It can be converted to the new format by processing it with startextdump and then makestardb in src/tools/stardb. Both of these programs accept input from stdin, so you should be able create a file starsold.dat with buildstardb, and then run startextdump starsold.dat | makestardb > starsnew.dat.

There's a readme.txt for startextdump, makestardb, and makexindex, and nothing but a usage message for buildstardb.cpp--unfortunately, I was less thorough about this in the 'ancient' days of Celestia. The systems is far more complex than it needs to be: a single program could quite easily process the HIPPARCOS data set and write out a binary star file in the format expected by Celestia.

--Chris

[ajtribick]

Hmm... the code doesn't seem to run correctly on my system: the stellarClass gets output as 4x32-bit integers instead of being packed into a 16-bit integer.

In addition, it is clear this is NOT the code that was used to generate the star database, as it still includes the correction for the spectral type of Capella. The current versions of stars.txt and stars.dat do not include this correction (as agreed quite a while back now).

So clearly, the version of buildstardb in the SVN is not the current version!

(Since I don't know what other changes have been made along with the removal of the Capella correction, I can't just remove the relevant lines of code)

EDITED TO ADD: I've sent a PM to Grant about this matter, as he is listed on the SVN as being the author of the stars.dat and stars.txt files.

[ajtribick]

Furthermore, Celestia's README file contains an incorrect description of stars.dat. It looks like it is describing the old file format, except the description is incorrect: the old file format included both the HD and HIP catalogue numbers, while the README file lists only one catalogue number per record. (I remember trying to work out what the new file format was a while back... turns out I did it in 2005)

I've added a page describing the stars.dat file to the Wikibook here.

[selden]

Where did you put the WikiBook link which points to that page?

Presumably it would be appropriate for it to be in a section on Celestia internals, but such a section does not currently exist.

[ajtribick]

Where did you put the WikiBook link which points to that page?

Presumably it would be appropriate for it to be in a section on Celestia internals, but such a section does not currently exist.

The page was a redlink on the Catalog File Reference page.