Celestia Forums

Hi all,

after Andrew has thoroughly overhauled Celestia's stars by implementing

** the new Reduction of the raw Hipparcos data
** Floor van Leeuwen, 2007 'Hipparcos, the New Reduction of the Raw Data'
** Astrophysics & Space Science Library #350.
** available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311

with much improved parallaxes (distances), my binary orbit data need to be revisited as well, since --for consistency-- the barycenter distances, RA, Dec and the primary's spectral classes are typically taken from
Celestia's stars.txt merged with revised.stc.

Moreover, Andrew made use of the 'Modify' statement in his new 'revised.stc' file, which my visualbins.pl and spectbins.pl Perl scripts in SVN do not yet understand. Since I found some time in the train during my past days of travelling, here are my adapted Perl scripts along with the resulting improved binary orbit data files.

Everything you need for testing is contained in this archive (~2.5 MB):
+++++++++++++++++++++++
http://www.celestiaproject.net/~t00fri/images/binaries_rev.zip
+++++++++++++++++++++++

(my modified Perl scripts, along with the current stars.txt, revised.stc from SVN (r 4643), all input data files and the modified output files, visualbins.stc and spectbins.stc).


If you have Perl along with the Math::libm module installed, you can easily run the Perl scripts yourself, just by typing their names (visualbins.pl or spectbins.pl) at the console prompt.

The generated data files visualbins.stc and spectbins.stc go into Celestia's data/ directory, as usual.

The Perl scripts first of all merge all modifications from revised.stc with the stars from stars.txt and save the result in memory. Then the published data

for 163 visual binaries from

S. Soederhjelm, Astronomy and Astrophysics, v.341, p.121-140 (1999)
(http://adsabs.harvard.edu/cgi-bin/nph-b ... .341..121S)

and for 39 spectroscopic binaries from

D. Pourbaix, Astron. Astrophys. Suppl. Ser. 145, 2000, 215-222
(http://www.edpsciences.org/journal/inde ... s9259.html)

, respectively, are read in and the distances compared with the improved ones from Andrew's new analysis. There are only the following few binary star systems, where there is a more than 10% disagreement of the published binary distances with Andrew's new analysis. Here is the direct output from my Perl scripts:

visualbins.stc:
---------------
Distance mismatch of 10.5236890878469 % with (revised) stars.txt for HIP 47479
Distance mismatch of 12.1248879450477 % with (revised) stars.txt for HIP 60129
Distance mismatch of 17.7512706376436 % with (revised) stars.txt for HIP 87655
Distance mismatch of 10.4594762802037 % with (revised) stars.txt for HIP 20347
Distance mismatch of 18.645348178515 % with (revised) stars.txt for HIP 20916
Distance mismatch of 10.4700427605474 % with (revised) stars.txt for HIP 113996

spectbins.stc
--------------
Distance mismatch of 46.6639357764932 % with (revised) stars.txt for HIP 10644
Distance mismatch of 15.9196185748745 % with (revised) stars.txt for HIP 96683
Distance mismatch of 22.9161641972114 % with (revised) stars.txt for HIP 99473
Distance mismatch of 12.4605212777792 % with (revised) stars.txt for HIP 108917
Distance mismatch of 16.7844770348707 % with (revised) stars.txt for HIP 114576


Note the 46% discrepancy for the HIP 10644 (Del Tri) distance, about which we had plenty of discussion previously! I hope, Andrew has also made sure that his HIP 10644 distance is indeed better than the one published by D. Pourbaix .

For reasons of internal consistency, I have decided to give preference to Andrew's new distances over the published barycenter distances from the above two binary orbit papers in ALL cases. Analogously, I replaced the RA, DEC coordinates of the barycenter by the ones from Andrew throughout. So part of the Del Tri issues should now be resolved...

+++++++++++++++++++++++++
As I frequently wrote, I ONLY believe results of an (involved) analysis after I have seen DIRECT tests of it's results in comparison with solid measurements. This also applies to my own results, of course . Indeed, so far, direct observational tests of my Celestia binaries were still lacking (in public ).
+++++++++++++++++++++++++

So let me present two (out of many) here:

70 Oph
-------------
Note that the shown data include almost 100 years of precision orbit measurements (black dots)!

Astrometric measurements of visual double stars are done with a telescope, by precisely observing in the course of time the 'position angle' of the secondary starting from North towards East and the apparent primary-secondary distance in the skyplane. Here is a nice diagram from

http://www.asahi-net.or.jp/~zs3t-tk/index.htm

containing the precise definitions of these to crucial experimental quantities for binary systems.



The corresponding predictions from Celestia (using my 70 Oph parameters from visualbins.stc not the ones from Grant in nearstars.stc!), I have extracted as follows:

I positioned the observer very close to Earth, activated the equatorial grid, turned it around by 180 degrees to have North pointing towards the observer's "feet" in accordance with the above diagram. Then I zoomed into the 70 Oph system (SHIFT + mouse left) such that the primary-secondary distance spans a fair fraction of the screen. Next without ever changing the zoom scale again, I entered the following times, where mostly the secondary is expected to align almost in parallel to one of the grid axes:

11/1887, 10/1898, 2/1905, 11/1931, 3/1961.

Each time, I made a screen shot of the changing 70 Oph configuration. Then I used GIMP to prepare a semi-transparent overlay of the 5 color-inverted screenshots with the primary always centered. Finally I performed ONE (and only one) rescaling of the image with the 70 Oph measurements wrto the overlay results from Celestia, to match the two drawing scales.

Here is the result, demonstrating beautiful consistency with my entire binary orbit implementation. The red dots (secondary) are from Celestia. The fat black dot is the primary.




Procyon CMi
--------------------

Same procedure, perfect consistency once again:



Let me ephasize the quite different inclination of this projected orbit as compared to that of 70 Oph!

Note that Grant's nearstars.stc file is still lacking the adaptation to Andrew's new analysis.

We should discuss how to proceed with the redoubled visual/spectroscopic binaries in nearstars.stc! Besides....it would be good to compare the quality of agreement of Grant's parameters (differing somewhat from mine) with direct observations as I exemplified above! Then we can tell, which data sets are more accurate...

I'll wait for some time to get your feedback. Then I shall commit my modifications to SVN.


Fridger

I note this thread and the one on the mailing list have been very quiet, which is a shame. Haven't had time to test it yet myself, but hopefully will be able to this weekend.

ajtribick wrote:I note this thread and the one on the mailing list have been very quiet, which is a shame. Haven't had time to test it yet myself, but hopefully will be able to this weekend.

Agree. Perso I'm not enough skilled to do some test and help on the topic...

ajtribick wrote:I note this thread and the one on the mailing list have been very quiet, which is a shame.

I agree , although there has been some encouraging feedback by Chris:

Chris wrote:Very impressive! I think we need to emphasize more the capabilities of
Celestia for binary star fans. I don't know of any other software that
handles this so well. (Of course, the database is at least half of the
recipe...)

--Chris

Here is another precision measurement example for practising with a corresponding Celestia orbit test on the weekend . See my step-by-step instruction above.



Fridger

A couple of comments here: firstly, I am still unsure about whether it is a good idea to substitute in fake apparent magnitudes - missing magnitude information is regarded as grounds for eliminating the star during the star database generation process. At the very least, such stars should be flagged with a comment in the output file. Altering the code to eliminate systems with missing magnitudes removes the following:

Furthermore I am unsure whether "hiding" star names from starnames.dat is a good idea. I've definitely seen a couple of threads where people have become confused because of this.

Andrew,

thanks for looking at my revised binaries....

There are ~ 100k stars as candidates for the Celestia sky, so leaving some with bad distances out is not so dramatic, at least visually. However, if you throw away all those binary orbits (among the < 200 known candidates), where the apparent magnitude of at least one of the components or their spectral class is unknown, virtually NO binaries would be left for Celestia!

That would have made my job VERY easy


No, I dont think that is the right approach, given the fact that the full measurement of the many orbital parameters and their visualization contains a LOT of valuable information, despite some badly known magnitudes or spectral classes. In particular, since the eye is only poorly able to tell the precise magnitudes and spectral classes apart, when stars are rendered on a computer monitor.

With lacking distances (parallaxes) the story is quite different, though, since that affects well visibly the "morphology" of the local star volume and the star distribution therein.

++++++++++++++++++++++++++++
But I completely agree with you, that any lacking knowledge should be made clear in the (human readable) data files via '?' entries. This is what I have done already partly when the spectral class is unknown. I didn't do it yet for app.mag since I was originally planning to replace the generic m=5.0 value by the actual average over the data set. This is easier to do directly in the Perl script than in the code...
+++++++++++++++++++++++++++++

Since years now, my enthusiasm for getting back at my binary orbits has been enormously damped by the unsolved issue with Grant's nearstars.stc file! The nearstars collection makes me go through my binary stars each time by hand to check individually, whether Grant might have that star already in his collection (possibly under a different name) .

As I have repeatedly pointed out, the classification of binaries should be done according to the basically different physical properties of being of visual or spectroscopic type. That's how astronomers look at binaries, and correspondingly, these criteria allow for a sensible and systematic expansion of the respective databases...

Using instead distance as a filter (like in nearstars.stc) is a criterion that should be applied trivially by the distance cut-off slider we have built into Celestia anyway.

++++++++++++++++++++++++++++++++
I think it would be very sensible to give up this distance filter in an external data file, containing a mix of single and multiple stars. Instead, I strongly plea for maintaining a separate file, where all the multiple stars with more than two components ( from nearstars.stc) would be collected! There are many subtleties to consider for these complex cases, whence they would be better maintained by hand than by computer.
++++++++++++++++++++++++++++++++

Finally:

My present revision effort is another typical illustration of this unpleasant situation in the context of nearstars.stc. Instead of committing my improvements without much delay, I am lurking around without receiving feedback about the crucial issue what to do with the stars from my published input catalogs that Grant has already included in nearstars. Chris has promised to contact Grant, but nothing seems to happen since a week or so.

Fixing little code bugs seems to be much more urgent than getting Celestia's astronomical data base into good shape.

I am definitely loosing interest...

Fridger

t00fri wrote:...Fixing little code bugs seems to be much more urgent than getting Celestia's astronomical data base into good shape.

I am definitely loosing interest...

Fridger, don't say that; this confusion with star database is not a new topic (I'm not saying it's not an important one!) and we are just at the time of fix bug for a major release... If this is not in the roadmap to 1.6, let's say that this problem should be high priority for 1.6.1 or at least should be resolved before 1.7...

ElChristou wrote:

t00fri wrote:...Fixing little code bugs seems to be much more urgent than getting Celestia's astronomical data base into good shape.

I am definitely loosing interest...

Fridger, don't say that; this confusion with star database is not a new topic (I'm not saying it's not an important one!) and we are just at the time of fix bug for a major release... If this is not in the roadmap to 1.6, let's say that this problem should be high priority for 1.6.1 or at least should be resolved before 1.7...

Christophe,

this is obviously not the right approach: Andrew's revision for Celestia's stars will definitely be in 1.6. My binary orbits depend significantly on his modified star parameters. The barycenter parameters (distances!!!) for the binaries MUST be coincident with the single HIP star data base, otherwise you'd see all sorts of close-by multiple star artefacts .

Should be easy enough to understand?...

Your suggestion also points into the direction that fixing some (small) code bugs for 1.6 seems more important than getting Celestia's fundamental astronomical data base into good shape...

Fridger

t00fri wrote:

ElChristou wrote:

t00fri wrote:...Fixing little code bugs seems to be much more urgent than getting Celestia's astronomical data base into good shape.

I am definitely loosing interest...

Fridger, don't say that; this confusion with star database is not a new topic (I'm not saying it's not an important one!) and we are just at the time of fix bug for a major release... If this is not in the roadmap to 1.6, let's say that this problem should be high priority for 1.6.1 or at least should be resolved before 1.7...

Christophe,

this is obviously not the right approach: Andrew's revision for Celestia's stars will definitely be in 1.6. My binary orbits depend significantly on his modified star parameters. The barycenter parameters (distances!!!) for the binaries MUST be coincident with the single HIP star data base, otherwise you'd see all sorts of close-by multiple star artefacts .

Should be easy enough to understand?...

Right, then it's up to you guys (plural!) to meet the good timing...

t00fri wrote:Your suggestion also points into the direction that fixing some (small) code bugs for 1.6 seems more important than getting Celestia's fundamental astronomical data base into good shape...

Not the intention! Now that you point with a noob comprehensive example the problem behind this database topic, my above suggestion is clearly not a solution...
Chris??

There are quite a few entries in nearstars.stc that don't really need to be there and get in the way of the star database upgrades being applied to nearby stars. I could see it being of use if spectral type overrides are required or non-Hipparcos stars are to be added, but it could do with some radical pruning.

(It may also be worth poking around in extrasolar.stc too...)

No way to have only one file (with sections or else) to avoid checking several files which is a lost of time and also an eventual risk of doubloons?

ElChristou wrote:No way to have only one file (with sections or else) to avoid checking several files which is a lost of time and also an eventual risk of doubloons?

In my case, visualbins.stc and spectbins.stc correspond to complete refereed and published scientific catalogs, each. The two files distinguish visual and spectroscopic measurements. Each method has very well known bonuses and deficiencies. Both catalogs represent standards in binary star orbit extraction.

That's why I am sad to see them disrupted since some of the stars are included in nearstars and crossed out from my otherwise complete catalogs...

Fridger

t00fri wrote:

ElChristou wrote:No way to have only one file (with sections or else) to avoid checking several files which is a lost of time and also an eventual risk of doubloons?

In my case, visualbins.stc and spectbins.stc correspond to complete refereed and published scientific catalogs, each. The two files distinguish visual and spectroscopic measurements. Each method has very well known bonuses and deficiencies. Both catalogs represent standards in binary star orbit extraction.

That's why I am sad to see them disrupted since some of the stars are included in nearstars and crossed out from my otherwise complete catalogs...

I (I suppose we) know that, but you don't respond my question; in fact, why do we have .dat and .stc files? no way to have a single format? and then a single database?

If I remember correctly, it's been a couple of years since the issue of nearstars.stc last came up on this forum.
At that time I posted a clear statement to the effect that I did not consider the file to be "my" property, and that I was quite happy for Fridger, Andrew, Chris, or anyone else to edit it in any way they thought fit, up to and including deleting the whole thing. This was not a joke, or some sort of rhetorical device; it's the honest truth. Since extrasolar.stc has also been mentioned above, I hereby extend the disclaimer to extrasolar.stc, too.
Please, do what you want with these files.

Grant

granthutchison wrote:If I remember correctly, it's been a couple of years since the issue of nearstars.stc last came up on this forum.
At that time I posted a clear statement to the effect that I did not consider the file to be "my" property, and that I was quite happy for Fridger, Andrew, Chris, or anyone else to edit it in any way they thought fit, up to and including deleting the whole thing. This was not a joke, or some sort of rhetorical device; it's the honest truth. Since extrasolar.stc has also been mentioned above, I hereby extend the disclaimer to extrasolar.stc, too.
Please, do what you want with these files.

Grant

Thanks for the clearcut statement, Grant. In fact, I did remember what you wrote a couple of years ago, but did not want to "impose" in any way at this time. Chris wrote to me that he wanted to contact you about the issue.

I also remember your arguments about the complexity of nomenclature etc for more than two-component star systems. This point is well taken. I therefore propose to maintain such data (from nearstars etc) in a separate .stc file.

Fridger

t00fri wrote:My present revision effort is another typical illustration of this unpleasant situation in the context of nearstars.stc. Instead of committing my improvements without much delay, I am lurking around without receiving feedback about the crucial issue what to do with the stars from my published input catalogs that Grant has already included in nearstars. Chris has promised to contact Grant, but nothing seems to happen since a week or so.

Fixing little code bugs seems to be much more urgent than getting Celestia's astronomical data base into good shape.

Fixing bugs is very important. I was extremely busy last week and regret that I was unable to both look into the binary stars issue and make bug fixes. But given that this is all a volunteer effort, some more patience on your part seems due.

t00fri wrote:

ElChristou wrote:No way to have only one file (with sections or else) to avoid checking several files which is a lost of time and also an eventual risk of doubloons?

In my case, visualbins.stc and spectbins.stc correspond to complete refereed and published scientific catalogs, each. The two files distinguish visual and spectroscopic measurements. Each method has very well known bonuses and deficiencies. Both catalogs represent standards in binary star orbit extraction.

That's why I am sad to see them disrupted since some of the stars are included in nearstars and crossed out from my otherwise complete catalogs...

The issue is how do we deal with cases where the information in nearstars.stc is more complete? For example, visualbins.stc has no spectral type specified for Alpha Centauri B. Since the spectral type of this start is in fact well known, we clearly don't want to comment out the definition in nearstars.stc. Another case: visualbins.stc has an unknown spectral type for HIP 82817 B, while in nearstars.stc there is more detail: the star is actually a double, two closely-orbiting red dwarf components. References are given:



We don't want to throw away Grant's hard research in developing such a detailed model of nearby solar systems. Simply using whatever definitions are in visualbins.stc and spectbins.stc is not an option. We're going to end up with a scheme quite like what we have now, with some entries commented out of these two files. Now, I have no problem with commenting out star definitions from nearstars.stc and using the ones from visualbins.stc/spectbins.stc as long as they're at least as complete as the ones from nearstars that they replace.

I think that we should also update all the HIPPARCOS derived parallaxes and positions in nearstars.stc for the new reduction of the database. Together with some possible pruning of star definitions in nearstars.stc, this should be enough for 1.6.0, yes?

I'd rather wait until after 1.6.0 for more serious star database surgery. Perhaps we can split nearstars.stc into separate files. However, there is some logic for the distance filter because of the existence of the RECONS catalog from which it is largely derived. Maybe we want to split nearstars.stc into recons.stc and a supplementing multiples.stc? Multiples.stc would contain definitions for systems with more than two stars as well as binary systems from visualbins/spectbins where the components have missing spectral types or apparent magnitudes.

--Chris

Chris wrote:Fixing bugs is extremely important. I was extremely busy last week and regret that I was unable to both look into the binary stars issue and make bug fixes. But given that this is all a volunteer effort, some more patience on your part seems due.

As you know, my time for Celestia has also been VERY limited since last November. Instead of just vanishing from the scene, I have written repeatedly short PM's to you containing some respective schedule of mine. I think the lead programmer of a "voluntary effort" could do very well the same, right?

The issue is how do we deal with cases where the information in nearstars.stc is more complete? For example, visualbins.stc has no spectral type specified for Alpha Centauri B. Since the spectral type of this start is in fact well known, we clearly don't want to comment out the definition in nearstars.stc. Another case: visualbins.stc has an unknown spectral type for HIP 82817 B, while in nearstars.stc there is more detail: the star is actually a double, two closely-orbiting red dwarf components. References are given:

Code: Select all

# Delfosse, X. et al. (1999) "New Neighbours I: 13 new                         
# companions to nearby M dwarfs" A&A, 344, 897                                 
# (http://aa.springer.de/papers/9344003/2300897/small.htm)                     
# Mazeh, T. et al. (2001) "Studies of multiple stellar systems - IV. The       
# triple-lined spectroscopic system Gliese 644" MNRAS, 325, 343.               
# (http://arxiv.org/PS_cache/astro-ph/pdf/0102/0102451.pdf)   


We don't want to throw away Grant's hard research in developing such a detailed model of nearby solar systems. Simply using whatever definitions are in visualbins.stc and spectbins.stc is not an option. We're going to end up with a scheme quite like what we have now, with some entries commented out of these two files. Now, I have no problem with commenting out star definitions from nearstars.stc and using the ones from visualbins.stc/spectbins.stc as long as they're at least as complete as the ones from nearstars that they replace.

I think that we should also update all the HIPPARCOS derived parallaxes and positions in nearstars.stc for the new reduction of the database. Together with some possible pruning of star definitions in nearstars.stc, this should be enough for 1.6.0, yes?

I'd rather wait until after 1.6.0 for more serious star database surgery. Perhaps we can split nearstars.stc into separate files. However, there is some logic for the distance filter because of the existence of the RECONS catalog from which it is largely derived. Maybe we want to split nearstars.stc into recons.stc and a supplementing multiples.stc? Multiples.stc would contain definitions for systems with more than two stars as well as binary systems from visualbins/spectbins where the components have missing spectral types or apparent magnitudes.

--Chris

OK, this was my last attempt to get the issue straight.

While I also appreciate Grant's hard work, the Universe is clearly too big for pursuing his "personalized" way of parameter collection for ever. Yes, there may be a lost parameter here and there, but I don't see how we could proceed strategically along such lines when potentially handling hundreds more objects ... So a strategic decision is badly needed. This issue goes on now for years, each time you tend to shift it ahead, giving priority to bug fixes in the code....

Since I also don't appreciate that you decide about astrophysics matters, to which I devoted many months as a competent professional physicist, let's just forget about binaries for my part.

Fridger

ElChristou wrote:

t00fri wrote:

ElChristou wrote:No way to have only one file (with sections or else) to avoid checking several files which is a lost of time and also an eventual risk of doubloons?

In my case, visualbins.stc and spectbins.stc correspond to complete refereed and published scientific catalogs, each. The two files distinguish visual and spectroscopic measurements. Each method has very well known bonuses and deficiencies. Both catalogs represent standards in binary star orbit extraction.

That's why I am sad to see them disrupted since some of the stars are included in nearstars and crossed out from my otherwise complete catalogs...

I (I suppose we) know that, but you don't respond my question; in fact, why do we have .dat and .stc files? no way to have a single format? and then a single database?

We could convert stars.dat into an stc file. But, the binary .dat format is much more compact and quicker to load. If the 100,000+ stars in stars.dat were instead stored in an stc file, Celestia would take much longer to start up. The big advantage of the stc format is that it can store star data that the very simple .dat format cannot, such as orbit information for multiple star systems. It's also a human readable format that can contain comments with references to the sources of information on different stars.

Using a single star database wouldn't solve the problem of combining data from different sources. We'd end up having to deal with the exact same issues of data source priority in the creation of this database.

--Chris

t00fri wrote:OK, this was my last attempt to get the issue straight.

While I also appreciate Grant's hard work, the Universe is clearly too big for pursuing his "personalized" way of parameter collection for ever. Yes, there may be a lost parameter here and there, but I don't see how we could proceed strategically along such lines when potentially handling hundreds more objects ... So a strategic decision is badly needed. This issue goes on now for years, each time you tend to shift it ahead, giving priority to bug fixes in the code....

The things is that we *can* proceed with an approach similar to the one we have now and not have to throw away any data. The 'pure' approach that you advocate would mean that we'd end up with an undefined spectral type for Alpha Centauri B. Are you advocating that we do that? If yes, then your proposal is absurd. But if not, then I think we're mostly in agreement about what needs to be done, though we may disagree on exactly how many star definitions in nearstars.stc should override those from visualbins/spectbins. And if we allow nearstars's definition of Alpha Centauri B, why not other stars with a spectral type listed in nearstars but not visualbins/spectbins?

You imply that the problem is unbounded, but really, we're dealing with a very manageable data set here: multiple star systems within 25 light years of Earth. With some care, we can get binary stars right without taking a step back and throwing out good data from nearstars.stc. We're almost there already...

Since I also don't appreciate that you decide about astrophysics matters, to which I devoted many months as a competent professional physicist, let's just forget about binaries for my part.

I'm not a professional physicist, but I do have a clear understanding of all the trade-offs involved. That is all that is required.

--Chris

Chris,

Chris wrote:The issue is how do we deal with cases where the information in nearstars.stc is more complete? For example, visualbins.stc has no spectral type specified for Alpha Centauri B. Since the spectral type of this star is in fact well known, we clearly don't want to comment out the definition in nearstars.stc.

Firstly:

Grant used the RECONS -> Gliese catalog values for the alpha Centauri parameters (apart from orbits). It is well known that the series of Gliese catalog updates (1957, 1969, 1979, 1991) is mostly obsolete. Indeed, in Grant's nearstars you find K0V for alpha Centauri B, while the latest, authoritative WDS (Washington Double Star cat., 2009) quotes K1V instead.

http://cdsarc.u-strasbg.fr/viz-bin/Cat?B/wds

Hence, is the spectral type of alpha Centauri B really so well known in nearstars as you claim? My reference analysis for visualbins (Soederhjelm 1999), does not specify that entry.(Yet, the K1V star temperature is not too far away from my default G2V for '?'). Do you really believe that Soederhjelm was unaware of that OLD Gliese value in 1999? NO, there were obviously scientific reasons why he preferred to leave the entry blank!

In summary, your arguments about nearstars' higher "completeness" suffer in this case from ignoring astrophysical considerations and significant uncertainties!

Of course, it would have taken me less than ~ 30 minutes to read in either the RECONS or the WDS catalogs or both via my visualbins.pl Perl script and merge the additional entries with Soederhjelms analysis. Hence, you are arguing besides the point.

Again there are good scientific reasons why in this complex matter of multi-parameter least square fitting of binary orbits (with plenty of "hidden" constraints) one has to be VERY careful when feeding in naively "external" substitute parameters. The resulting orbits may suddenly flip into other solutions etc and consistency may get lost (This does of course not concern the spectral type, but many other parameters like e.g. mag1/mag2) .

Since I have plenty of experience with this matter (unlike you I assume), I prefer to prepare a binary data base for Celestia that is as close to a standard catalog or refereed publication as possible! However, since I created the visualbins/spectbins data base quite a few years back, I would long have performed a thorough update (see further below) , if the fate of nearstars.stc was agreed upon.

For that matter, there are very nice NEW catalogs notably on spectroscopic binaries with 70 completely determined astrometric orbits! They were only possible recently after detailed reanalysis of the HIP stars.

Here are the main references:
SB9: 9th Catalogue of Spectroscopic Binary Orbits (Pourbaix+ 2004-2009)
http://cdsarc.u-strasbg.fr/viz-bin/Cat?B/sb9
and notably
Astrometric orbits of SB9 stars (Jancart+, 2005)
http://cdsarc.u-strasbg.fr/viz-bin/Cat? ... 365#sRM2.2


Next:

I never proposed that some part of Grant's work should be thrown away! You have probably overlooked some of my relevant posts in this thread that I wrote during your recent "absence". Since Grant's multi-component orbits are no doubt on a much less safe footing than the binary ones, I want these to be separated off from the latter. In fact, since alpha Centauri is a multiple star system, it might thus be taken out of my dataset for binaries . Same for HIP 82817... But NOT 70 Oph etc...

Incidentally, I would love to see how those multi-star orbits were derived FROM MEASUREMENTS and what the actual ambiguities and underlying assumptions were! I seriously doubt that the ambiguities mentioned in the "boiler plate" were the only ones...

Finally:

Chris wrote:

Fridger wrote:Since I also don't appreciate that you decide about astrophysics matters, to which I devoted many months as a competent professional physicist, let's just forget about binaries for my part.

I'm not a professional physicist, but I do have a clear understanding of all the trade-offs involved. That is all that is required.

You are certainly able to judge the trade-offs related to what Celestia is to offer. But I doubt that you overlook the astrophysical trade-offs in depth (see e.g. above)). This is often supported by your arguments...

Since you apparently want to "keep control" also scientifically, here is a concrete alternative:

Since I release my scientific datafiles for Celestia under my good name as an experienced professional (astro) physicist, I am not ready to move away much from my position of "data purity" that I have pursued over years with Celestia. I am also getting tired of going through this sort of arguments with you each time again...

So, if you agree, we may take visualbins/spectbins completely out of Celestia and I will start up with a scientific visualization plan that I am actively considering since a while:

The plan is to initiate a separate CelestiaSci project in SVN with feedback@CelestialMatters, that is strictly based on acclaimed scientific data and solar system textures of highest standard. Among various enhancements, I then will code a dedicated utility for quick ad hoc loading and unloading of scientific catalogs, quite similarly to the clever way we did it in XEphem years ago. Besides hosting a database that conforms with MY standards, there will be a special info utility, where the complete scientific references are displayed upon clicking on the objects in question. All name conventions for DSOs will be made conform with SIMBAD via my proven batch read-out proceedure. Certainly NO reference to Wikipedia anywhere

I will work hard to invent a possibility of graphically displaying parameter uncertainties!

The result of all this will clearly have a smaller amount of more science-oriented users, but then at least, I will be able to realize the scientific part as I want it. Perhaps there are some people around here who might be interested in such a more rigorously scientific approach.

It has never been my aim to maximize the number of Celestia users at all cost...

As to the textures, I have written to you long ago about my ambitious plans (hopefully together with some of my graphics friends ) involving the direct ISIS3 mission interface and official releases like Ciclops etc. There shouldn't be any doubt that I have plenty of expertise also here...

Of course, if this plan will be realized, I would be very glad to retain close contact with the original Celestia (dev) community.

Fridger