Binary Orbits Revisited!

[granthutchison]

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 .

Very much like the real world, then.

Grant

[t00fri]

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 .

Very much like the real world, then.

Grant

Grant,

in my case of visualbins and spectbins the Perlscript checks on any > 10% discrepancies of the ("native") distances given by Soederhjelm and Pourbaix, respectively, compared to Andrew's revised HIP data.

I find these cases with distances larger than 25 ly:

visualbins:
--------------

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:
-------------
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

Hence in these 10 cases there is a substantial discrepancy and one should inject an astrophysical criterion which distance value (the "native" one or Andrew's) is the more reliable one.

Since I learned from Selden that using the "native" distances in Celestia does not create a visible clash, I wonder whether it might not be more consistent to generally return to distances and coordinates as given in the Soederhjelm and Pourbaix papers, respectively!? Notably for the "astrometric" subsets this may well be better. After all, these analyses are based on overall fitting solutions with proper motions split off from orbital motion etc.

What do you think?

How big would the largest discrepancies between your RECONS distances and those from Andrew be?? From where do you take the barycenter coordinates? Also from RECONS or from Soederhjelm if available? Can you astrophysically justify your choice?

Fridger

[granthutchison]

For the 91 Hip stars Andrew lists at <25ly, the RECONS data are generally, as one might expect, well within 1%. Only two stars have discrepancies over 10%: the binary Hip 1242 (19%) and the solitary, faint dwarf Hip 85605 (27%). S?derhjelm in fact provides a solution for Hip 1242, but makes specific mention in the text that his own parallax estimate may be too low.

Since the astrometric orbit solutions rely on generating a closed ellipse in order to split out the effects of parallax and proper motion and thereby to define a barycentre, I think I believe the same as you perhaps reasoned when you originally decided to go with Andrew's Hip data rather than the "native" estimates: that the RA, Dec and plx likely have a small impact on the calculated plane-of-sky orbital parameters, and can to some extent be dissociated from the orbit solutions without great violence being done.

Grant

[t00fri]

For the 91 Hip stars Andrew lists at <25ly, the RECONS data are generally, as one might expect, well within 1%. Only two stars have discrepancies over 10%: the binary Hip 1242 (19%) and the solitary, faint dwarf Hip 85605 (27%). Soderhjelm in fact provides a solution for Hip 1242, but makes specific mention in the text that his own parallax estimate may be too low.

Grant

Partial cross posting??

OK, but since I am dealing with > 25 ly objects and thus with smaller parallaxes, the ambiguities aggravate. Any suggestion about the preferrable choice: Andrew's HIP distances or Soederhjelm distances?

Another ambiguity: In visualbins, there is often lacking info about the spectral type, notably of the secondary. So some educated guess seems unavoidable.

So far I have bluntly interpreted these "?" cases as G2V. However, perhaps, a slightly better alternative is to assume the SAME spectral type for both components equal to the corresponding joint spectral type given in HIP. What do you think?

As I have shown above, computer monitors are not very sensitive platforms for distinguishing close-by spectral types...

Fridger

[granthutchison]

Partial cross posting??

Yes, I realized I hadn't responded to your point about choosing parallaxes and RA/dec, and went back to edit. My edit doesn't help with your decision, though, I think.

As to the spectral classes, would you not come closer on average to "reality" if you used the calculated mass from your dataset to estimate a main-sequence spectral class?

Grant

[t00fri]

Partial cross posting??

Yes, I realized I hadn't responded to your point about choosing parallaxes and RA/dec, and went back to edit. My edit doesn't help with your decision, though, I think.

As to the spectral classes, would you not come closer on average to "reality" if you used the calculated mass from your dataset to estimate a main-sequence spectral class?

Grant

Well that's what I have been exploring for weeks quite a while ago.
I suppose you were thinking of combining a Hertzsprung-Russel luminosity<-> colour diagram
with an empirical mass - luminosity law like typically

[tex]L \propto M ^{3.5}[/tex]

whence one gets a mass <-> colour relation.

Here is one of many plots I did with Soederhjelm's stars (focus on the one on the rhs. It's an extended mass - luminosity behaviour with color classes fitting smoothly in ):

CLICK for BIG!

lumi-mass-col.jpg

However, my conclusion was that for /individual stars/ this approach is pretty hopeless, while as statistical average there may be some use. For individual stars the fluctuations are often huge.
I made dozens of such plots. If you are interested....let me know.


My previous argument of equal spectral types for both components, gets at least the "sum" of both colors right. As long the mass ratio m2/m1 = O(1) (which is frequently the case) also the colors should be similar, according to such qualitative above mass-colour relations. That's what is behind that argument...

Fridger

[granthutchison]

However, my conclusion was that for /individual stars/ this approach is pretty hopeless ...

But isn't the question whether this method is more or less hopeless than the alternatives? That's something that could be quantified with some statistical analysis.
Simply assigning a spectral class of G2V is the equivalent of drawing a horizontal line across a graph which has a clear diagonal trend, so it seems a poor option.
As for your other suggestion, I imagine there are data available to allow a plot of primary v. secondary spectral class. My guess is that in such a plot there would be a correlation line that did not include the origin of the graph: the secondaries would be on average cooler than the primaries, because on average of lower mass and lower luminosity.
In medicine we're quite used to comparing predictive models for scattered data using statistical techniques; I imagine the same techniques are used for astronomical data.

Grant

[t00fri]

However, my conclusion was that for /individual stars/ this approach is pretty hopeless ...

But isn't the question whether this method is more or less hopeless than the alternatives? That's something that could be quantified with some statistical analysis.

That's precisely what I was investigating some time ago. I have also stated already the main result: in a statistical sense, applying to a large number of stars, such relations are usable. However the fluctuations (variance) around the average are so large that for individual stars such relations are effectively worse than other simplistic Ans?tze.

I still think that with a simple behaviour like [tex]color_{1,2} \propto m_{1,2}^\gamma; \gamma > 1[/tex] and [tex]m_1/m_2[/tex] near 1 (say 1/2 <= m1/m2 <= 2) in a majority of Soederhjelms stars, one expects also color1 near color2 in a majority of cases (where [tex]\gamma >1[/tex] helps, but it's precise value is not important. Unfortunately, I cannot test this expectation with Soederhjelm's visual binaries, since he does not give any colors at all...But this could be looked at with binaries from WDS. Perhaps I'll do that...

Simply assigning a spectral class of G2V is the equivalent of drawing a horizontal line across a graph which has a clear diagonal trend, so it seems a poor option.
As for your other suggestion, I imagine there are data available to allow a plot of primary v. secondary spectral class.

Yes, but plotting primary v. secondary spectral class is neither successful (i.e an acceptable narrow variance correlation), since it depends strongly on the masses, the distances and "material" like metallicity.... Normal visual binaries are so far apart that besides gravity there are little interactions. Hence there should be little colour correlation due to the binary nature of the system. The situation may be different for eclipsing binaries though...

My guess is that in such a plot there would be a correlation line that did not include the origin of the graph: the secondaries would be on average cooler than the primaries, because on average of lower mass and lower luminosity.

What I am trying to say is that I do NOT intend to start using very rough "handicrafted" models with UNCLEAR uncertainies that mainly make the situation less transparent. In such cases, I prefer oversimplified yet clearly reproducable workarounds. If I would fiddle some involved relations that noone could ever quantitatively reproduce, the idea of data purity would really get lost. In addition I showed that visually there is quite a range of spectral types that can hardly be distinguished on a monitor.

In medicine we're quite used to comparing predictive models for scattered data using statistical techniques; I imagine the same techniques are used for astronomical data.

Grant

Statistics in my field of quantum physics is daily routine. In astrophysics I notice a number of "statistical" analyses that better had not been performed

Fridger

[chris]

What I am trying to say is that I do NOT intend to start using very rough "handicrafted" models with UNCLEAR uncertainies that mainly make the situation less transparent. In such cases, I prefer oversimplified yet clearly reproducable workarounds. If I would fiddle some involved relations that noone could ever quantitatively reproduce, the idea of data purity would really get lost. In addition I showed that visually there is quite a range of spectral types that can hardly be distinguished on a monitor.

Your argument that spectral types are almost indistinguishable is based on a very poor example image. In it, only the star textures were visible. If you look in celestia.cfg, you'll see that the same texture is assigned to both G and K class stars, so you'd expect these stars to look identical close up in one of the legacy render paths. The halo color (and the color of stars seen at a distance) does differ noticeably among stars with different temperatures. Here's a screenshot of Alpha Centauri A and B with Celestia's 'realistic' star colors mode activated:

alfcen.png

--Chris

[t00fri]

What I am trying to say is that I do NOT intend to start using very rough "handicrafted" models with UNCLEAR uncertainies that mainly make the situation less transparent. In such cases, I prefer oversimplified yet clearly reproducable workarounds. If I would fiddle some involved relations that noone could ever quantitatively reproduce, the idea of data purity would really get lost. In addition I showed that visually there is quite a range of spectral types that can hardly be distinguished on a monitor.

Your argument that spectral types are almost indistinguishable is based on a very poor example image. In it, only the star textures were visible. If you look in celestia.cfg, you'll see that the same texture is assigned to both G and K class stars, so you'd expect these stars to look identical close up in one of the legacy render paths. The halo color (and the color of stars seen at a distance) does differ noticeably among stars with different temperatures. Here's a screenshot of Alpha Centauri A and B with Celestia's 'realistic' star colors mode activated:

alfcen.png

--Chris

But don't you agree that despite some slight visible differences, these are NOT "foreground" features in a visualization of binary systems on a monitor. I would love to insert perfect values everywhere for the spectral types, but they are simply NOT available in many cases. Before inserting incorrect ones without a visible warning sign, I still prefer a '?'. Using the system spectral type from HIP for both components is presumably a decent AND transparent workaround for now, at least for systems with m1/m2 near 1.

I also do NOT agree with the RECONS philosophy to use shaky mass-luminosity relations for fixing the crucial orbit geometry (a2/a1)! In his 'nearstars.stc', Grant used these mass ratios from RECONS, too, until a week ago, and now fortunately has switched to the mass ratios and further parameters given in Soederhjelms paper that I used from the beginning.

Fridger

[granthutchison]

What I am trying to say is that I do NOT intend to start using very rough "handicrafted" models with UNCLEAR uncertainies that mainly make the situation less transparent ...

My apologies. I'm afraid I didn't understand that you were asking a rhetorical question. I presumed you wanted suggestions when you asked me what I thought. Since I spend my days having to make really important decisions based on multiple regression analysis of rather scattered data, that's the sort of thing I tend to think about.

I also do NOT agree with the RECONS philosophy to use shaky mass-luminosity relations for fixing the crucial orbit geometry (a2/a1)! In his 'nearstars.stc', Grant used these mass ratios from RECONS, too, until a week ago, and now fortunately has switched to the mass ratios and further parameters given in Soederhjelms paper that I used from the beginning.

To be fair, Fridger, I recently increased the number of astrometric mass ratios used in nearstars.stc by incorporating Soderhjelm's data. There were from the outset a number of carefully referenced binary solutions using astrometrically determined mass ratios in that file. And, to be fair again, Soderhjelm's data turned out to make little difference to the mass ratios of the affected systems. For whatever reason, RECONS's mass-luminosity relationships seem to have worked pretty well in these cases.

Nearstars.stc has the potential to improve steadily, if permitted.

Grant

[t00fri]

What I am trying to say is that I do NOT intend to start using very rough "handicrafted" models with UNCLEAR uncertainies that mainly make the situation less transparent ...

My apologies. I'm afraid I didn't understand that you were asking a rhetorical question. I presumed you wanted suggestions when you asked me what I thought. Since I spend my days having to make really important decisions based on multiple regression analysis of rather scattered data, that's the sort of thing I tend to think about.

I suppose you will apply these statistical results NOT to individuals but draw conclusions valid on average only for LARGE samples...If you look at my above figures, that are drawn using Soederhjelm's binaries, you can judge yourself that many individual stars deviate badly from the average best-fit line, which I would have (incorrectly) used for any such individual star...
Using it, I could be easily wrong by several color classes!

For whatever reason, RECONS's mass-luminosity relationships seem to have worked pretty well in these cases.

Yes, Grant, you (and RECONS) might have been lucky. Perhaps RECONS were also tacitly using other sources for the "dropouts"... The mass-luminosity relations employed by RECONS have not been made public (as far as I can tell), such that everyone is able to assert the inherent uncertainties against real star samples. These MUST be large in general! The reproach I have with such approaches is that NO believable estimate for the resulting errors is given. Without knowing how uncertain the results are for individual binaries, they are not very valuable, unfortunately. Scientific methodology does not only consist in producing numbers, but MUCH more importantly, in presenting convincing arguments about how reliable these numbers are.

Fridger

[granthutchison]

I suppose you will apply these statistical results NOT to individuals but draw conclusions valid on average only for LARGE samples...

Perhaps you'd rather not know this ...
If you ever receive advice from a doctor on a particular course of treatment (something as "simple" as the management of a raised cholesterol, or as complex as the management of a life-threatening acute illness), then you will likely be receiving individual advice based on population analysis of the kind we're discussing. You'll be advised on the basis of your position in a risk calculation based on population studies using multiple regression analysis of several well-scattered biological variables. The doctor, in other words, will be estimating your spectral class from your mass and luminosity.

The mass-luminosity relations employed by RECONS have not been made public (as far as I can tell) ...

From the bottom of the RECONS table:

(11) the estimated mass (in units of the Sun's mass) is based upon the Mv value and the empirical mass-luminosity relations of Henry and
McCarthy (1993) and Henry et al. (1999) ...

Grant

[t00fri]

I suppose you will apply these statistical results NOT to individuals but draw conclusions valid on average only for LARGE samples...

Perhaps you'd rather not know this ...
If you ever receive advice from a doctor on a particular course of treatment (something as "simple" as the management of a raised cholesterol, or as complex as the management of a life-threatening acute illness), then you will likely be receiving individual advice based on population analysis of the kind we're discussing. You'll be advised on the basis of your position in a risk calculation based on population studies using multiple regression analysis of several well-scattered biological variables. The doctor, in other words, will be estimating your spectral class from your mass and luminosity.

Actually, since many years I have an interest in such statistical investigations in medicine and notably in their reliability . Fortunately, having been mostly healthy so far, I never required concrete application of such results. The basic problem is of course that the stochastic variables refer to most complex human beings each with a different history, rather than to dead matter. In turn, it seems almost impossible to avoid (hidden) correlations among some of these variables! If stochastic variables are however subject to constraints (<=> correlations) the fundamental "limiting theorem" of statistics does not even hold for VERY large samples...

Decorrelating a particular statistical study seems close to impossible from my perspective at least

Thanks for reminding me of the mass-luminosity reference on the RECONS page. I was aware of the footnote, but rather interpreted that reference more as a general one about mass-luminosity relations. I'll check...

Fridger

PS: Since we were making nice progress through our ongoing discussion, I have meanwhile put together a neatly improved visualbins / spectbins dataset, taking a number of features from my more advanced Celestia.Sci project. It has fully SIMBAD compatible name syntax, plenty of alternate names, uses Andrew's star distances and implements a distance cut-off below 25 ly etc. Hence ZERO interference with nearstars

There is still the option, which sets of catalog names I should retain for Celestia proper? Suggestions?

For now, I selected only a few for reasons of length:

1) <3 letter greek[index=1,2]> <3 letter constellation> ; (e.g. MU1 Boo, MU2 Boo, EPS Cet,...)
2) < 1-2 digit number> <3 letter constellation> [A|B] ; (e.g. 51 Boo A, 51 Boo B, 83 Cet,...)

If existing then 1) and 2) are always leading and kept both.

3) GJ xxx
4) LHS xxxx
5) p. WDS Jxxxx+-xxxx (I feel the authoritative WDS entries for visual binaries should be listed)
6) HIP xxxxxx
7) HD xxxxxx
8 ) SAO xxxxx

Further frequently appearing options are LTT xxxx, NLTT xxxxx, NSV xxxxx. CCDM ....

Incidentally, why did you hide the HIP numbers from nearstars displays in Celestia!? After all Celestia stars are based on HIP and you got plenty of HIP stars in nearstars...

[ajtribick]

Incidentally, why did you hide the HIP numbers from nearstars displays in Celestia!? After all Celestia stars are based on HIP and you got plenty of HIP stars in nearstars...

They are hidden? I haven't noticed this... an example of a system where this occurs?

[t00fri]

Incidentally, why did you hide the HIP numbers from nearstars displays in Celestia!? After all Celestia stars are based on HIP and you got plenty of HIP stars in nearstars...

They are hidden? I haven't noticed this... an example of a system where this occurs?

Of course this only refers to the barycenter, which however is most directly related to a corresponding effective single HIP star at large distance:

This results with nearstars upon typing: 70 Oph <enter>



The HIP, HD and SAO numbers are displayed, however, when typing

70 Oph A <enter> or 70 Oph B <enter>.

In case of visualbins/spectbins, I display the HIP/HD/SAO numbers for the barycenter,
Here in my new visualbins with SIMBAD compatible naming syntax, typing

83 Cet <enter> gives this


typing 83 Cet A <enter> gives this


typing 83 Cet B <enter> gives this


Hence in my case the HIP numbers don't display for the A, B components. These are also NOT part of the HIP catalog in many cases.

Fridger

[granthutchison]

There are a couple of things going on there.
One is that Simbad often associates the Hip catalogue number with the A component only; 70 Oph is a little unusual in that the pair has a Hip number while the components do not. Compare, for instance, GJ 15, in which the Hip number is associated with the A component alone. Querying on a Hip number most commonly takes you to the page of the A component, with or without a note associating the B component.
My other concern is that Simbad does not recognize the existence of A&B components to Hip numbers: typing in "HIP 88601 A" returns an error, not 70 Oph A. This makes a barycentric label a little awkward to propagate through the binary.

Grant

[t00fri]

There are a couple of things going on there.
One is that Simbad often associates the Hip catalogue number with the A component only; 70 Oph is a little unusual in that the pair has a Hip number while the components do not. Compare, for instance, GJ 15, in which the Hip number is associated with the A component alone. Querying on a Hip number most commonly takes you to the page of the A component, with or without a note associating the B component.
My other concern is that Simbad does not recognize the existence of A&B components to Hip numbers: typing in "HIP 88601 A" returns an error, not 70 Oph A. This makes a barycentric label a little awkward to propagate through the binary.

Grant

Grant,

Yes I am aware of various irregularities of SIMBAD as concerns multiple stars. Still I think my notation (that I have arrived at together with ChrisL quite some time ago) is more consistent with SIMBAD than yours in nearstars.

SIMBAD is NOT a specialized database for multiple stars, hence no surprise that things are far from perfect as to individual components...

I agree that HIP numbers do NOT admit additional A or B component labels in SIMBAD. That's why I associate the HIPs with the binary's barycenter that is neither A nor B. Moreover, physically, the barycenter indeed represents the proper large distance "focus point" for the respective single "star" entry in the HIP catalog. In contrast, you associate the HIP number generally with the A component in the display, which is asymmetric for no physical reason.

In some (hierarchical) cases of wide double stars, where the A and B components are themselves double, SIMBAD correctly associates A and B components with existing separate HIP numbers.

E.g.

HIP 75411 ===> MU1 Boo:51 Boo A
HIP 75415 ===> MU2 Boo:51 Boo B

corresponding to the two HIP numbers for the wide A and B components there are also two binary barycenters, realizing the hierarchical composition of this quadruple system. Incidentally, SIMBAD prints out mu.01, mu.02 instead of the Celestia notation MU1, MU2. But the latter is also SIMBAD compatible. This notation is implemented in my new visualbins in perfect accord with SIMBAD at the barycenter level. The 4 components
are then in Celestia 51 Boo A A, 51 Boo A B, 51 Boo B A and 51 Boo B B. Non-capital second letters would be better though...This component notation is not SIMBAD compatible.

Yet the important Bayer-Flamsteed notations have also confusing aspects:

On the one hand,
E.g.

HIP 88601 ===> 70 Oph (and GJ 702, ADS 11046 AB,...)
i.e. again in proper notation for the 70 Oph barycenter

Yet the A and B components are kept also separately in SIMBAD (as you noticed above), but are NOT associated therein with any HIP number (unlike your A componets in nearstars).

70 Oph A and 70 Oph B

are also differentiated consistently via other labels, e.g. GJ 702 A, ADS 11046 A versus GJ 702 B, ADS 11046 B. Just as I do it in visualbins.

However, consider e.g.

HIP 2762 ===> 13 Cet (and the aliases GJ 23, ADS 490 AB, ...

13 Cet A, is separately recognized without a HIP number (but along with GJ 23 A, ADS 490 A,...), unlike your notation.

13 Cet B is NOT resolved this time! Too bad

Still 13 CetB is resolved but leads you to the system barycenter page since any letter after Cet is chopped off. Hence 13 CetX is also resolved into 13 Cet.

Even worse, e.g.

HIP 12390 ===> 83 Cet OK for the barycenter, BUT

83 Cet A and 83 Cet B are BOTH refused as SIMBAD search entries...
(83 Cet X is still accepted, since X is chopped off.)

My studies have shown that some alias entries are kept in SIMBAD with A and B components properly distinguished, like GJ xxx and GJ xxx A, GJ xxx B or ADS xxx and ADS xxx A, ADS xxx B, while others have merely a component related notation LHS 458 = 70 Oph A and LHS 459 = 70 Oph B.

The WDS notation is unfortunately also complex and exists in separate versions, since it's RA/Dec based...

I suppose I shall mainly concentrate on alternative catalog labels that support the A and B component addition syntax. Otherwise the effort becomes unsensibly high...
I'll retain the WDS entries however because of the WDS catalog's improtance/reference character.

I am sure you will spot further exceptions to these SIMBAD regularities I was discussing here

Fridger

[granthutchison]

Well, by confirming my observation that Simbad isn't particularly consistent you're certainly not encouraging me to rush into adopting Simbad's catalogue usage as standard.

To me, the most compelling reason to revert the Hip number to the barycentre is to fix the name displayed when the star system is viewed from a distance. At present we see "Sirius A" and "Procyon A" in the sky as viewed from Earth. If I move the Hip numbers to the barycentres, we should get "Sirius" and "Procyon" back.

Grant

[t00fri]

Well, by confirming my observation that Simbad isn't particularly consistent you're certainly not encouraging me to rush into adopting Simbad's catalogue usage as standard.

I think here it is important to keep the involved proportions in mind: SIMBAD altogether is a tremendously useful data base that was started already ~60 years ago! Albeit being not specialized for double stars and indeed exhibiting a few " notational quirks", SIMBAD nevertheless makes a lot of standardized info available for further investigations about MANY star systems of interest! Just think of the great ALADIN plotting applet that I use heavily in case of doubt about some components of multiple star systems and their notations! So altogether, it's VERY important to notationally connect to SIMBAD.

Hence I definitely don't share your reservations here.

Clearly, there are a number of notational complications, since there are several (equivalent) notations for multiple star components of complex systems in use ( B-> Ba, Bb , BC-> B, C ...). SIMBAD being a huge database, sometimes mixes these up. But so what! If we are as good as SIMBAD we can be proud!

I undertook quite some Perl efforts to disentangle things in my star component parser. I am sure I overlooked accounting for some odd cases here and there. That's why I will make my new binary star .stc files available for testing VERY soon. The situation is particularly tricky, since visualbins often contains only a binary subsystem of a considerably larger system with more stars. Therefore from that limited perspective, the notations MUST be sometimes confusing, despite being formally correct.

My view is that it is NOT my part to fiddle the best of all possible notations. Rather, I want to display the notation that is used in authoritative catalogs. So people can connect easily to other literature...

To me, the most compelling reason to revert the Hip number to the barycentre is to fix the name displayed when the star system is viewed from a distance. At present we see "Sirius A" and "Procyon A" in the sky as viewed from Earth. If I move the Hip numbers to the barycentres, we should get "Sirius" and "Procyon" back.

Grant

Sorry, I didn't get this. I always have

< popular starname> in the barycenter with HIB/HD/SAO numbers following
<popular starname> A for the primary component display
<popular starname> B for the secondary component display

After all Sirius A and Sirius B exist...

Fridger