Binary Orbits Revisited!

[granthutchison]

But then your multiple star orbits must be on a pretty shaky ground, since I would not know any reliable source for mass ratios except for spectroscopic data in some cases ?? Also all nearby visuals from the 6th catalogue which are not in Soedehjelm get their orbit shapes from the uncertain mass-luminosity relation?

Perhaps you've missed observing how much effort I made to track down good data. Delfosse et al., for instance, claim 2% to 10% accuracy in their mass estimations; Mazeh et al. manage around 5%. The references are in the file.
However, I'm sure better data have become available for many nearby systems in the years since I originally compiled nearstars.stc. I'd have hunted them down and incorporated them by now, were it not for the state of limbo in which nearstars.stc has long been maintained, subject to your disapproval, which isn't exactly motivating.

Grant

[t00fri]

But then your multiple star orbits must be on a pretty shaky ground, since I would not know any reliable source for mass ratios except for spectroscopic data in some cases ?? Also all nearby visuals from the 6th catalogue which are not in Soedehjelm get their orbit shapes from the uncertain mass-luminosity relation?

Perhaps you've missed observing how much effort I made to track down good data. Delfosse et al., for instance, claim 2% to 10% accuracy in their mass estimations; Mazeh et al. manage around 5%. The references are in the file.
However, I'm sure better data have become available for many nearby systems in the years since I originally compiled nearstars.stc. I'd have hunted them down and incorporated them by now, were it not for the state of limbo in which nearstars.stc has long been maintained, subject to your disapproval, which isn't exactly motivating.

Grant

Grant,

no no, I am not disapproving nearstars and certainly I appreciate your vast effort. I just feel that your selection criterion of distance (< 25 ly) tends to block quite thoroughly other sensible, systematic classifications, in particular, the classification by method of observation (astrometric, visual, spectroscopic, eclipsing,... systems).

The latter classifications are mostly used in observational astronomy and are expandable sets as measurement techniques improve. In addition, Celestia's distance cut-off slider can implement/enforce naturally and a posteriori a nearby distance constraint on any such data set.

As a more technical point, I feel that extraction work on large catalogs can best be done AND documented by means of computers, rather than via by-hand editing. I don't need to repeat this point now.

In fact, this existing deadlock also demotivated me quite a lot, and indeed I have done very little improvement work with my binary stars, until very recently for this reason. So let's hope that we shall find a good constructive workaround...

Fridger

ADDED : As a physicist I always think in terms of uncertainties involved: the classification by method of observation that I favor implies certain well-defined experimental trade-offs in each category (think e.g. of spectroscopic binaries) which are directly related to the used observational method! Hence particular, well-known aspects of the respective, reconstructed orbits remain uncertain (think of the half axis a and the orbit plane i for spectroscopics), while other aspects are particularly good (orbital parallaxes, masses, spectral types for double-line spectroscopics...). For any binary star in each such category the /same type/ of intrinsic uncertainties and benefits apply.

This creates a desired transparent situation wrto uncertainties! A clearcut implementation of of such transparency is both highly educational and of interest to scientists...

[granthutchison]

I just feel that your selection criterion of distance (< 25 ly) tends to block quite thoroughly other sensible, systematic classifications, in particular, the classification by method of observation (astrometric, visual, spectroscopic, eclipsing,... systems).

Of course, the cataloguing of specifically nearby stars has a venerable history, too: Gliese, NStars, 8pc, RECONS. And the reasoning behind nearstars.stc is exactly the same as has motivated others to make cross-sectional surveys through the various methodological catalogues you mention.
A good, exhaustive representation of local space has its own merits. It has its own educational value, and Celestia users are often knowledgeable about and expect to see our local stars in all their complexity. That completeness and complexity just isn't available from any single catalogue or feasible grouping of catalogues at present, so the idea of simply using the distance slider for a cut-off misses the whole point of generating a good model of local space.
Our local space is very small, and it represents a small fraction of the data available in various methodological catalogues. An inner 25ly cut-off is trivially easy to automate when processing large catalogues, and the small subset of data thus excluded is likewise trivially easy to include in nearstars.stc, where it can then be properly associated with other detail. I've already demonstrated how that can be made to work by incorporating the small number of orbital solutions from S?derhjelm into nearstars.stc.
Astronomers are already using both of the cataloguing philosophies we're discussing: methodological and cross-sectional. Why can't Celestia also accommodate both philosophies, provided we ensure the overlap doesn't interfere destructively?

Grant

[t00fri]

Astronomers are already using both of the cataloguing philosophies we're discussing: methodological and cross-sectional. Why can't Celestia also accommodate both philosophies, provided we ensure the overlap doesn't interfere destructively?

Grant

Grant,

what I don't see in your arguments is this: suppose I have set up the binaries according to my favoured database categories (astrometric, visual, spectroscopic, eclipsing,...), along with a separate multistar (>2) data file, say. Suppose as a subset of this much larger AND expandable data base ALL star systems from your nearstars are contained therein as well. But note the request < 25 ly was never implemented as an external selection criterion in my case...

Now I start Celestia and adjust the built-in distance cut-off slider to 25 ly. Then I should precisely recover the contents of nearstars in the remaining (25 ly)^3 volume, if nearstars was indeed complete within d < 25 ly.

++++++++++++++++++++
So what would be the special role of nearstars in such a much wider, yet "collision-free" framework?
Historical? What else?
++++++++++++++++++++

I suppose you realize that coexistence of my above defined data files with nearstars amounts not only to an effective redoubling of the star systems contained in nearstars. It notably forbids that the complete catalog information could ever exist in my categories, since in EACH one there is a subset that collides with nearstars! So the only way of making the two compatible would be mutilating complete, refereed and generally acclaimed catalogs by tediously commenting out individual entries...

Did I overlook something?

Fridger

[granthutchison]

what I don't see in your arguments is this: suppose I have set up the binaries according to my favoured database categories (astrometric, visual, spectroscopic, eclipsing,...), along with a separate multistar (>2) data file, say. Suppose as a subset of this much larger AND expandable data base ALL star systems from your nearstars are contained therein as well. But note the request < 25 ly was never implemented as an external selection criterion in my case...

Now I start Celestia and adjust the built-in distance cut-off slider to 25 ly. Then I should precisely recover the contents of nearstars in the remaining (25 ly)^3 volume, if nearstars was indeed complete within d < 25 ly.

++++++++++++++++++++
So what would be the special role of nearstars in such a much wider, yet "collision-free" framework?
Historical? What else?
++++++++++++++++++++

It would have absolutely no role, and I would be the first to dispense with it under those circumstances. I look forward to that day. But (speaking as someone who has actually done the necessary research to prepare nearstars.stc), I don't anticipate its content miraculously assembling in the near future from just a few more processes datasets. That is particularly unlikely in the current situation, when the same star systems can be generated under different catalogue names which go unrecognized until someone manually checks the data for duplicates. Your two existing "automatic" files have already produced a number of such examples.

I suppose you realize that coexistence of my above defined data files with nearstars amounts not only to an effective redoubling of the star systems contained in nearstars. It notably forbids that the complete catalog information could ever exist in my categories, since in EACH one there is a subset that collides with nearstars! So the only way of making the two compatible would be mutilating complete, refereed and generally acclaimed catalogs by tediously commenting out individual entries...

Did I overlook something?

"Tediously commenting out individual entries"? From an exponent of PERL like yourself? It seems like the work of a moment to ensure that entries above the necessary parallax threshold are automatically commented out. Simple and error-free.
And does such simple commenting count as "mutilation"? Forgive me if that looks like dramatic overstatement from where I sit. The catalogues still exist. The data still exist. The data still exist in Celestia. The data are still displayed in Celestia, if nearstars.stc is correctly maintained as I suggest. A few hash symbols have been automatically generated by a script, is all. No books have been burned.

Put it another way. Suppose it were to be agreed that some hand-editing of data is both necessary and desirable (at least in the foreseeable future) in order to produce a complete representation of nearby star systems. I suggest it makes more sense to restrict that hand-editing to a single file, suitably annotated, and to automatically filter other generated catalogues to prevent data conflicts. The filtered data will be small in number and therefore easily transferrable to the edited depository for nearby stars.

Or so it seems to me. This is all ground that has been previously covered. No doubt Chris will let us know what he thinks in due course.

Grant

[t00fri]

Grant,

"Tediously commenting out individual entries"? From an exponent of PERL like yourself? It seems like the work of a moment to ensure that entries above the necessary parallax threshold are automatically commented out. Simple and error-free.
...

That sounds indeed like a workable solution, provided you choose the identical distances from Andrew's revised stars for the barycenters. So far the filtering was rather attached to names that often didn't match. That was indeed tedious. The more tedious name-related filtering was done NOT because I was asleep , BUT because you and I used different sources (values) for the distances!

With distance filtering, the burden goes mainly to you, since YOU will have to assert that ALL binaries that I have commented out due to the simple < 25 ly cut-off, actually reappear in nearstars! This includes the naming complexity. I suppose you would also not want to follow a strictly SIMBAD compatible syntax?

So please could you let me know the precise number of stars that are contained in nearstars.
Since you don't have a script for their generation and I am too lazy to count...

No doubt Chris will let us know what he thinks in due course.

Grant

Which doesn't make things simpler... I have offered him that I take visualbins and spectbins completely OUT of Celestia! That would also solve a number of issues...

Perhaps I might add that my binary data files look completely different now on my computer, with vast improvement as to previously missing parameters: with the help of my ftp download Perl module now ALL the standard authoritative catalogs (WDS, Tycho double stars, 6th cat, 9th cat and a great, highly "complete" catalog about multiple systems <= 7 members,... !!) are scanned "online" for missing entries...

These catalogs will be part of "Celestia.Sci" that I am working on since a while.

Fridger

[granthutchison]

That sounds indeed like a workable solution, provided you choose the identical distances from Andrew's revised stars for the barycenters. So far the filtering was rather attached to names that often didn't match. That was indeed tedious.

This way the burden goes mainly to you, since YOU will have to assert that ALL binaries that I have commented out due to the simple < 25 ly cut-off, actually reappear in nearstars! This includes the naming complexity. I suppose you would also not want to follow a strictly SIMBAD compatible syntax?

Of course the burden should go to the hand-edited file-maker! How else could it work?
I'll happily (and immediately) convert to Simbad compatibility as soon as suitable parsing becomes available, so that the user doesn't need to fuss with Simbad's chosen format. Chris is evidently happy with that process in principle.

Rest assured that I have already checked through visualbins.stc and spectbins.stc (at least, the versions linked to in your first post on this thread), and can confirm that a simple cut-off at a computed distance of 25ly will do the necessary job without incurring either duplicates or drop-outs. If you wish me to check through your current versions, I can certainly do so, but I'll otherwise presume the distances have not changed.

So please could you let me know the precise number of stars that are contained in nearstars.
Since you don't have a script for their generation and I am too lazy to count...

Well, that's easy enough to do, but I'm not clear on which stars you'd like to know about. Presumably the total count isn't of interest, and I've confirmed above my willingness (and my plan) to take responsibility for the consequences of your automated deletions.

I have offered him that I take visualbins and spectbins completely OUT of Celestia! That would also solve a number of issues...

I rather thought we were reaching a worthwhile solution at the moment. Are you saying is it your intention to withhold your updated files?

Grant

[t00fri]

I have offered him that I take visualbins and spectbins completely OUT of Celestia! That would also solve a number of issues...

I rather thought we were reaching a worthwhile solution at the moment. Are you saying is it your intention to withhold your updated files?

Grant

Yes and No: I will provide a reasonable update for visualbins.stc and spectbins.stc along the lines we have discussed, and including the corrections due to Andrew's revised stars. Probably, I will leave out my SIMBAD compatible naming syntax at least for 1.6.0, since this is again a somewhat "hot" subject under discussion.

But that's NOT the highly improved data base I mentioned above. I am tired arguing with ChrisL, and I know that we are disagreeing about the data base in various respects that are essential to me. I am developing a quite different data and texture base concept along with new required code in Celestia.Sci. It's fate I'll decide about once a sufficient amount of new substance has accumulated. Let me not give too many previews before things are in a presentable stage.

Of course, I also have run my Perl scripts with the 25 ly constraint and --indeed-- things don't look bad at all . So YES, our above solution seems to be the right thing to follow up without delay...

Fridger

[granthutchison]

Of course, I also have run my Perl scripts with the 25 ly constraint and --indeed-- things don't look bad at all . So YES, our above solution seems to be the right thing to follow up without delay...

Excellent. My current version of nearstars.stc is already on SVN, and should be all that's required in the short term from me.

Grant

[t00fri]

Of course, I also have run my Perl scripts with the 25 ly constraint and --indeed-- things don't look bad at all . So YES, our above solution seems to be the right thing to follow up without delay...

Excellent. My current version of nearstars.stc is already on SVN, and should be all that's required in the short term from me.

Grant

Grant,

1) Did you now adapt your distances to Andrew's revised HIP stars?? I didn't see that yet and in the boiler plate of your latest nearstars I still read

"In particular, the distances given are derived from RECONS's weighted average parallaxes, rather than pure Hipparcos data."

I thought we have now agreed to use generally Andrew's revised HIP stars for the barycenter for the HIP binaries.

2) Your namings are quite unfortunate in a number of cases wrto SMBAD:
You tend to place Luyten xyz-vw first and Gliese xxx second. SIMBAD, however resolves Gliese xxx while Luyten is entirely unknown. You have always placed Luyten first, which I consider suboptimal...

Same with Struve xxx and Gliese xxx. Struve xxx is entirely unknown to SIMBAD.
GJ xxx is also known which you tend to place second, too.

Fridger

[granthutchison]

1) Did you now adapt your distances to Andrew's revised HIP stars?? I didn't see that yet and in the boiler plate of your latest nearstars I still read

"In particular, the distances given are derived from RECONS's weighted average parallaxes, rather than pure Hipparcos data."

I thought we have now agreed to use generally Andrew's revised HIP stars for the barycenter for the HIP binaries.

No, I hadn't agreed to do that, since my primary parallax source is the RECONS catalogue. What I pointed out was that a 25ly cut-off for your data according to Andrew's Hipparcos distance is also a 25ly cut-off for my RECONS data. There are no drop-outs or duplications between the two datasets, if you simply chop your data off at 25 light years. The two datasets merge seamlessly. There is, in fact, only one failure in the perfect overlap between my list and Andrew's list: the faint system Hip 14101 has a high parallax from RECONS (it is catalogued as RECONS 4), which brings it inside 25ly; Hipparcos places it more distant. I'm not aware of any orbital solutions for this system, but of course it's something to watch out for.

2) Your namings are quite unfortunate in a number of cases wrto SMBAD:
You tend to place Luyten xyz-vw first and Gliese xxx second. SIMBAD, however resolves Gliese xxx while Luyten is entirely unknown. You have always placed Luyten first, which I consider suboptimal...

Same with Struve xxx and Gliese xxx. Struve xxx is entirely unknown to SIMBAD.
GJ xxx is also known which you tend to place second, too.

OK, it certainly makes sense to switch these around. I'll do that, and also perform a general check to see if I can give Simbad-recognized names primacy.

Grant

[t00fri]

1) Did you now adapt your distances to Andrew's revised HIP stars?? I didn't see that yet and in the boiler plate of your latest nearstars I still read

"In particular, the distances given are derived from RECONS's weighted average parallaxes, rather than pure Hipparcos data."

I thought we have now agreed to use generally Andrew's revised HIP stars for the barycenter for the HIP binaries.

No, I hadn't agreed to do that, since my primary parallax source is the RECONS catalogue. What I pointed out was that a 25ly cut-off for your data according to Andrew's Hipparcos distance is also a 25ly cut-off for my RECONS data. There are no drop-outs or duplications between the two datasets, if you simply chop your data off at 25 light years. The two datasets merge seamlessly. There is, in fact, only one failure in the perfect overlap between my list and Andrew's list: the faint system Hip 14101 has a high parallax from RECONS (it is catalogued as RECONS 4), which brings it inside 25ly; Hipparcos places it more distant. I'm not aware of any orbital solutions for this system, but of course it's something to watch out for.

...
Grant

But are you sure that you don't call for visible inconsistencies this way? In the limit when the HIP star resolution is low, Andrew's HIP distances and coordinates are always used. But then what happens in the transition region when the resolution is good enough to make out two stars? The distance switches to your preferred value which may well be different from Andrew's etc...

Fridger

[granthutchison]

But are you sure that you don't call for visible inconsistencies this way? In the limit when the HIP star resolution is low, Andrew's HIP distances and coordinates are always used. But then what happens in the transition region when the resolution is good enough to make out two stars? The distance switches to your preferred value which may well be different from Andrew's etc...

I don't understand what effect you're invoking here, sorry.
I have made a star-by-star comparison to ensure that every entry in Andrew's current stars.txt with a computed distance of less than 25ly also appears in my list. (They all do.)
I have made a star-by-star comparison to ensure that every entry in my list also appears in stars.txt with a distance under 25ly. (All but one do, as mentioned above.)
I have made a star-by-star check of your visualbins.stc and spectbins.stc to ensure that all systems which would be "commented out" because of distance <25ly appear in my nearstars.stc. (They all do.)

Grant

[ElChristou]

Perhaps guys you should do a release to get some help and feedback on cross checking...

[granthutchison]

Perhaps guys you should do a release to get some help and feedback on cross checking...

Yes, I think we're probably close to doing that. We just need to convince ourselves that there are going to be no seams, first.

Grant

[t00fri]

But are you sure that you don't call for visible inconsistencies this way? In the limit when the HIP star resolution is low, Andrew's HIP distances and coordinates are always used. But then what happens in the transition region when the resolution is good enough to make out two stars? The distance switches to your preferred value which may well be different from Andrew's etc...

I don't understand what effect you're invoking here, sorry.
I have made a star-by-star comparison to ensure that every entry in Andrew's current stars.txt with a computed distance of less than 25ly also appears in my list. (They all do.)
I have made a star-by-star comparison to ensure that every entry in my list also appears in stars.txt with a distance under 25ly. (All but one do, as mentioned above.)
I have made a star-by-star check of your visualbins.stc and spectbins.stc to ensure that all systems which would be "commented out" because of distance <25ly appear in my nearstars.stc. (They all do.)

Grant

We might be misunderstanding each other. Let me take a well known example to illustrate my point:

HIP 88601 = 70 Oph
===============

Andrew's stars.txt gives:

d = 16.580266 ly

RA = 271.363386197 deg
Del = 2.502439053 deg

Your latest nearstars has instead
for the barycenter:

d = 16.644 ly
RA = 271.36375
Del = 2.5000000


So both distances and coordinates are somewhat different. Hence I would say that somewhere between being infinitely far away from 70 Oph and being very close there must be a jump, since in the former case Andrew's data are used while on close distance the somewhat different ones from nearstars are used.

In my case both are IDENTICAL.

Fridger

[granthutchison]

So both distances and coordinates are somewhat different. Hence I would say that somewhere between being infinitely far away from 70 Oph and being very close there must be a jump, since in the former case Andrew's data are used while on close distance the somewhat different ones from nearstars are used.

Can you tell from the code at what point this "jump" should take place?
It doesn't seem to be in evidence experimentally: nearstars.stc produces the exact RECONS distances for all its stars when viewed from Earth (and therefore one travels smoothly towards the various binary systems without discontinuity). I've now just tried some quite extreme experimentation, using nearstars.stc to move selected binaries 1000ly away from their Hipparcos positions, and flying to them from various angles, and I don't seem to be able to produce the effect you're concerned about.

Grant

[selden]

It is my understanding that if one uses an STC file to define a Star, using a valid HIP index number (as is done in nearstars for 88601 70 Oph A) , then the definition in the STC file replaces the definition of the star with that HIP number which was in stars.dat. In other words, Celestia is using the values seen in nearstars.stc, not the values which were taken from stars.txt. As a result, there is no run-time discontinuity in the distance.

Note that I am writing about when one specifies the HIP number by itself at the beginning of the STC line. Specifying the HIP number within a quoted Star name field iacts differently and leads to much confusion.

[t00fri]

It is my understanding that if one uses an STC file to define a Star, using a valid HIP index number (as is done in nearstars for 88601 70 Oph A) , then the definition in the STC file replaces the definition of the star with that HIP number which was in stars.dat. In other words, Celestia is using the values seen in nearstars.stc, not the values which were taken from stars.txt. As a result, there is no run-time discontinuity in the distance.

Note that I am writing about when one specifies the HIP number by itself at the beginning of the STC line. Specifying the HIP number within a quoted Star name field iacts differently and leads to much confusion.

Many thanks, Selden,

for pointing this out. After 7 years of Celestia there are still things to learn . Indeed, according to my cross checks you appear to be right. So Grand can stick with his preferred distances and I could in principle have taken those from Soenderhjelm's or Poubaix's catalog instead of Andrew's stars.

Nevertheless, a database inconsistency remains. Q: what are the earthbound distances & coordinates of 70 Oph and the other binaries in Celestia? A: that depends in which file you are looking . Not quite perfect...

Fridger

[granthutchison]

It is my understanding that if one uses an STC file to define a Star, using a valid HIP index number (as is done in nearstars for 88601 70 Oph A) , then the definition in the STC file replaces the definition of the star with that HIP number which was in stars.dat. In other words, Celestia is using the values seen in nearstars.stc, not the values which were taken from stars.txt. As a result, there is no run-time discontinuity in the distance.

This was my understanding, too, and I've therefore carefully associated all the Hipparcos stars in nearstars.stc with their corresponding Hip numbers in the way you describe above. Further experimentation is so far failing to produce any discontinuities of the sort Fridger describes.

Grant