Binary Orbits Revisited!

The place to discuss creating, porting and modifying Celestia's source code.
Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 10 months
Location: Hamburg, Germany

Re: Binary Orbits Revisited!

Post #21by t00fri » 18.02.2009, 18:31

This is a general info about where we stand as to 3d orbits of binaries of highest available scientific standing:

  • Among the ~ 118000 HIP stars, 17918 are flagged as Double and Multiple Systems (DMSA).
  • 235 of them, the so-called DMSA/O have an orbital solution.
  • As to spectroscopic binaries, there are 1374 from the authoritative SB_9, the 9th Catalog of Spectroscopic Binary Orbits, excluding visuals and DMSA/C, with a HIP entry. 282 of which have detectable astrometric motion (> 5% significance). 70 (20 new ones! ) thereof have VERY reliable astrometric orbital elements, satisfying all statistical consistency constraints!


Presently, there are 39 spectroscopic orbits of this type in my spectbins.stc data file.
Clearly with time, many more (spectroscopic) binaries from within the HIP star volume may become available for scientific 3d rendering....

With visual binaries there is an analogous accounting.

Fridger
Image

chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 23 years
Location: Seattle, Washington, USA

Re: Binary Orbits Revisited!

Post #22by chris » 19.02.2009, 21:13

t00fri wrote: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!
Is there really a need to speculate about some scientific reason that the entry is blank? As far as I can see, there are no spectral types in Soederhjelm's catalog, so he apparently didn't feel they were relevant in this particular catalog. In any case, even the value from the Gliese catalog is surely much less misleading than the default G2V.

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.

No I'm not. The visual binary catalog as is it now is missing spectral types that are present in nearstars.stc. If they spectral types from another catalog can be added, then one of my problems (the other is missing names) with giving precedence to the binary definitions in visualbins.stc disappears. You're already using spectral types from HIPPARCOS for the primaries, so it seems that in principle you have not problem doing this (and in fact, you could even use HIPPARCOS's spectral type for Alpha Centauri B.)

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) .

...

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
This is already used as a source for nearstars.stc (though obviously not the entire catalog, which also contains stars more distant than the ones in nearstars.)

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

I propose the following:
1. Remove the records from nearstars.stc that are exact duplicates of ones in stars.dat
2. In cases where the record in nearstars.stc just updates a spectral type (or other info, e.g. the SemiAxes for Altair), remove the positional information and use Modify
3. Commit the versions of spectbins.stc and visualbins.stc that have been updated for the new reduction of HIPPARCOS.
4. Integrate spectral type information from another catalog into visualbins.stc; only then the star records in that file can have precedence over the ones in nearstars.stc. It would be ideal to add the star names from nearstars.stc to visualbins and spectbins, too.
5. We can investigate splitting nearstars.stc into several files:
- revised.stc for spectral type changes
- multiple.stc for systems with three or more components
- recons.stc for nearby stars that aren't in HIPPARCOS

I don't want to do step 5 until after 1.6.0 is released and we can more deliberate more carefully what makes the most sense.

--Chris

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 10 months
Location: Hamburg, Germany

Re: Binary Orbits Revisited!

Post #23by t00fri » 20.02.2009, 16:50

Chris,

chris wrote:
t00fri wrote: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?

..., the K1V star temperature is not too far away from my default G2V for '?'.

In any case, even the value from the Gliese catalog is surely much less misleading than the default G2V.

Really? Here is a little practical test for you: On the screenshot you see alpha Centauri A (big) and alpha Centauri B (small) in Celestia:


Image

Question: did I display here the correct spectral type (K1V) or my default (G2V) for alpha Centauri B?? For comparison, alf Cen A is of type G2V, i.e. equal to my visualbins default for alf Cen B ;-). While the answer is psychologically obvious, can you see much of a difference, anyway?

So I disagree that my G2V default is all that misleading, as you claimed above. What is much more misleading is that these dull blobs are to represent STARS! ;-)

But actually, there is probably a better recipe for the cases of lacking spectral types of secondaries: by default they might be set equal to the spectral class of the primary! That is at least consistent with the often available measurements for the whole binary system. For alf Cen, it amounts to the same good approximation.

No doubt, in our database, we want the best available spectral class values! Yet this little exercise was just to illustrate that a normal computer display is NOT very sensitive as to distinguishing close-by spectral types for stars... Hence like app.mags for stars & DSOs, these are not such decisive quantities for an adequate computer visualization.

Fridger ;-)
Last edited by t00fri on 20.02.2009, 18:48, edited 4 times in total.
Image

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 10 months
Location: Hamburg, Germany

Re: Binary Orbits Revisited!

Post #24by t00fri » 20.02.2009, 17:48

chris wrote:...
I propose the following:
1. Remove the records from nearstars.stc that are exact duplicates of ones in stars.dat
2. In cases where the record in nearstars.stc just updates a spectral type (or other info, e.g. the SemiAxes for Altair), remove the positional information and use Modify
3. Commit the versions of spectbins.stc and visualbins.stc that have been updated for the new reduction of HIPPARCOS.
4. Integrate spectral type information from another catalog into visualbins.stc; only then the star records in that file can have precedence over the ones in nearstars.stc. It would be ideal to add the star names from nearstars.stc to visualbins and spectbins, too.
5. We can investigate splitting nearstars.stc into several files:
- revised.stc for spectral type changes
- multiple.stc for systems with three or more components
- recons.stc for nearby stars that aren't in HIPPARCOS

I don't want to do step 5 until after 1.6.0 is released and we can more deliberate more carefully what makes the most sense.

--Chris

Chris,

here is what I might be willing to do (or not willing to do) :

1. Remove the records from nearstars.stc that are exact duplicates of ones in stars.dat
Not my business. Unless I get a generating script for nearstars.stc, I will NOT scan hundreds of star data visually and then apply hand-editing to some of them. No time available for that sort of approach. ;-)

Instead...

  • For the clearcut cases of BINARY stars in nearstars (<=> 2 components in RECONS!),
    I can easily write a Perl script to redo automatically that part of nearstars from scratch, using

    -- RECONS +
    -- Sixth Catalog of Orbits of Visual Binary Stars +
    -- 9th Catalogue of Spectroscopic Binary Orbits (Pourbaix+ 2004-2009)

    These binary orbits I would then integrate into visualbins/spectbins. That would complete things in an astrophysically sensible and clearcut manner. The nearest binaries among them can then always be retrieved in Celestia via the distance cut-off slider.

  • Next, I am willing to read in with Perl the latest 2009 WDS (Washington Double Stars), as well as the cross index from the Tycho Double Star catalog, translating between WDS names and HIP, HD, ADS... (WDS naming is a MESS!)

    Then for each binary in visualbins (HIP's), I can scan this authoritative WDS catalog for separate values of Vmag1/Vmag2 and Spect1/Spect2. These can then be checked against what is in RECONS for consistency... To implement further Tycho catalog info is more tedious, since Tycho magnitude filters are different from Johnson's...

  • ...It would be ideal to add the star names from nearstars.stc to visualbins and spectbins, too.

    Much preferably, I would apply quickly my proven batch query method of SIMBAD to read out the most important alternative star names into my Perl scripts. Just like I did it for Globulars and Galaxies already... Then visualbins AND spectbins would have SIMBAD compatible names besides HIP numbers

I think I can handle this task rather quickly, given my considerable routine with these matters.

+++++++++++++++++++++
But ONLY if we agree that the results will be part of 1.6.0!

Otherwise, I prefer to proceed right away with my above-described CelestiaSci project, where I was planning to implement these new results anyway. Before starting, I should have an idea about your planned schedule for the final 1.6.0 release.

In the context of my CelestiaSci plans I have scanned already the new/recent catalogs along with the logistics of what is needed, where to find it and how to merge things...So that time-consuming part is done already.
+++++++++++++++++++++

My proposed separation & integration of nearstars entries is clearcut and machine-bound, since the RECONS data have a column for each entry with the number of components. I would just integrate the ncomp=2 systems.

++++++++++++++++++++++
Someone will have to take care of Grant's multiple orbits and single stars in nearstars. I will not want to touch these ...
++++++++++++++++++++++

Fridger
Image

ajtribick
Developer
Posts: 1855
Joined: 11.08.2003
With us: 21 years 5 months

Re: Binary Orbits Revisited!

Post #25by ajtribick » 20.02.2009, 22:34

Well looking through nearstars.stc and extrasolar.stc has been on my todo list since revising the stars database. Might take a while before I get it done though. As for the interaction between scripted files and hand-edited data, my position is that it is better to combine the two approaches, i.e. use scripts to generate the majority of the datasets, and do some hand-editing on top of that... however in such cases it is essential to document the sources of the hand-edited parameters in detail. (As for quibbles over a difference of 1 spectral subtype... is a difference of 1 subtype between different observers really all that significant?)

There's also the issue of data and Celestia versions... problem is Celestia releases are primarily tied to the code, meanwhile the data evolves, so if a dataset is updated in the intervening time it only gets through to the majority of users (i.e. the ones who aren't downloading from the repositories) when the next code version arrives, which probably exacerbates the data/code tensions that have been mentioned upthread. In a sense it makes working on the datasets seem to be a secondary task to coding. It would perhaps be better to do minor version releases where the datasets alone are updated: the majority of the time the datasets should not be dependent on bleeding-edge code features. To take an example, let me point out that just over 50 extrasolar planets have been added to extrasolar.ssc since the release of v1.5.1. Remember: Celestia is not just the code!

Guckytos
Posts: 439
Joined: 01.06.2004
With us: 20 years 7 months
Location: Germany

Re: Binary Orbits Revisited!

Post #26by Guckytos » 22.02.2009, 10:37

Just my 2 cents on this whole topic.

If there isn't complete agreement between the different databases for stars it would in my opinion be far better to have a point of interrogation "?" standing in the Class of the star instead of something that only one or a few selected databases see as right.
And the star displayed if there is "?" in the STC could be without any problem a standard class star type as G2V, as long as it is dcumented somewhere, why and how it was chosen. Best in the Helppages.
If it chages sometime in the future then the database would have to updated of course.
I would perhaps even go as far as to say if Celestia finds a star Class "?" in its database .DAT and then a modify command in an STC wants to change that, that it inhibits it. And I would widen this rule to the visual and spectroscopic binary files.
Now I know that this would perhaps be seen as a bit hard on the rules, but I think only this is a scientific approach to the matter. Only if all (or lets say a majority) agree on the properties of a star, it will be displayed.
That also makes it probably necessary to update the star catalogues a bit more often, which wouldn't be too bad, or would it?

Best regards,

Guckytos

granthutchison
Developer
Posts: 1863
Joined: 21.11.2002
With us: 22 years 2 months

Re: Binary Orbits Revisited!

Post #27by granthutchison » 08.03.2009, 22:12

Fridger:
Since you started this thread requesting testing of your files, I have a couple of bug reports:
1) The binary Hip 73182 is present in both visualbins.stc and spectbins.stc, under different names: "HIP 73182" and "Gl 570B". This produces four stars around the same barycentre: "HIP 73182 A", "HIP 73182 B", "Gl 570B A" and "Gl 570B B", of spectral classes "K5V", "?" "M1.5V" and "M3V".
2) Your Poubaix reference at the start of spectbins.stc is as follows: http://www.edpsciences.org/journal/index.cfm?v_url=aas/full/2000/14/ds9259/ds9259.html
However, this link simply drives me back to EDP Sciences' home page at http://publications.edpsciences.org/. I presume a subscription issue is involved.
I can access the article directly at http://aas.aanda.org/index.php?option=article&access=standard&Itemid=129&url=/articles/aas/full/2000/14/ds9259/ds9259.html, however.
Perhaps others could test the various links above?

Finally, since this has already been a topic for discussion on this thread and will need to be addressed in some way, I note that there are still overlaps between your binary files and nearstars.stc. Hip 73182, Hip 84140 and Hip 88601 in visualbins.stc and Gl 570B in spectbins.stc currently damage the three corresponding systems in nearstars.stc.

Grant

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 10 months
Location: Hamburg, Germany

Re: Binary Orbits Revisited!

Post #28by t00fri » 09.03.2009, 16:54

Grant,

many thanks for your careful checks...

Generally, the binary data files I provided for testing above were intentionally NOT yet modified to coexist with nearstars.stc and with each other. For that purpose, my Perlscript finally generates comment characters ('#') and places them in front of the entries that overlap with nearstars etc. Meanwhile there is quite a long list (sigh!) ...

I did not yet want to cross my entries out too hastily ;-), since
  • the general issue with nearstars was again under discussion
  • -- unlike nearstars -- my binary data files were already corrected for Andrew's revised HIP star-distances
  • I have performed many tests of my orbits versus REAL earthbound precision orbital measurements!

As you can see from my binary data files in SVN, with the exception of HIP 84140 (thanks!), the "damaging" systems are indeed NOT contained therein.

By the way:

Since you used the RECONS data, which themselves rest a lot on the much older and mostly obsolete updates of the original Gliese catalog (1957, 1969, 1979, 1991) , I really would appreciate seing some analog comparisons of nearstars orbits with observational data, before commenting out my corresponding orbits again. Like e.g. this one, HIP 88601 = 70 Oph (that I had commented out, too): it demonstrates excellent agreement of my visualbins orbit in Celestia (red dots) with precision measurements covering almost a whole century!

Image
(The fat black dot is the primary.)

+++++++++++++++++++++
Theory is good, but real checks versus data are better!
+++++++++++++++++++++

I have never seen such crucial confirmations in case of any stars from your nearstars.stc. There is plenty of available observational data and errors can never be excluded a priori... Moreover, I would be keen to learn, whether in all cases your nearstars orbits for multiple stars ( >2) are consistent with being "hierarchical" systems, such that they can be approximately considered as a combination of binary sub-systems! Only in such cases can these complex multiple star orbits be reconstructed with reasonable confidence. We never had any hardcore physics discussion about the validity of this crucial underlying assumption...

I suppose that you agree to correct the spectral class (K0V) of your alpha Centauri B from the old Gliese catalog in accord with the latest, authoritative WDS (Washington Double Star cat., 2009) (and SIMBAD) designation of K1V.

granthutchison wrote:Fridger:

2) Your Pourbaix reference at the start of spectbins.stc is as follows: http://www.edpsciences.org/journal/index.cfm?v_url=aas/full/2000/14/ds9259/ds9259.html
However, this link simply drives me back to EDP Sciences' home page at http://publications.edpsciences.org/. I presume a subscription issue is involved.
I can access the article directly at http://aas.aanda.org/index.php?option=article&access=standard&Itemid=129&url=/articles/aas/full/2000/14/ds9259/ds9259.html, however.
Perhaps others could test the various links above?

Yes that FREE link does not exist anymore, unfortunately. Thanks for letting me know. I have only checked it initially, since I always use the original AA Suppl. paper by D. Pourbaix, via the subscription paid by my laboratory. I'll replace the link with your reference.

I sincerely hope that eventually an acceptable solution for the data in visualbins, spectbins and nearstars will arise...

Fridger
Last edited by t00fri on 12.03.2009, 09:21, edited 2 times in total.
Image

granthutchison
Developer
Posts: 1863
Joined: 21.11.2002
With us: 22 years 2 months

Re: Binary Orbits Revisited!

Post #29by granthutchison » 09.03.2009, 17:34

Fridger:
My apologies if I reported problems that don't exist in the final version of these files. There are extensive commented sections in the versions I downloaded from the links in your first post, so I assumed that the work of "commenting out" had already been done.

RECONS contains no orbit data.
The binary orbits that are common to visualbins.stc and nearstars.stc are now the same orbits from S?derhjelm: the only difference therefore relates to the difference between the Hipparcos parallax and the RECONS averaged parallax, which of course influences the absolute size of the semimajor axes. S?derhjelm's data are in fact little different from the 6th Catalogue definitions, with the exception of a switch in the sense of the plane-of-sky inclination for Hip 73182.

Other orbits have been checked against existing orbit plots just as you describe. We had some discussion about this years ago, when nearstars.stc was first created, and I recall offering examples from both Sirius and 61 Cyg. I made other checks at the time, orbit by orbit. Why would you imagine that I wouldn't have done this?

What would you like in order to be reassured about hierarchical systems? A check that the orbital definitions of "level 2" stay well within the Hill sphere defined by "level 1"? Or do you want a full dynamical simulation before accepting any multiple systems that have defined orbits from different sources?

With reference to the spectral class of ALF Cen B, I've simply preserved the extracted RECONS data for now. There's a great deal more that could usefully be done with nearstars.stc, but I'm not particularly motivated to do it, for reasons which should be obvious from this thread.

Grant

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 10 months
Location: Hamburg, Germany

Re: Binary Orbits Revisited!

Post #30by t00fri » 09.03.2009, 19:14

Grant,

thanks for explaining ...

granthutchison wrote:Fridger:
...
RECONS contains no orbit data.

YES and NO ;-) . Sorry I should have been more explicit.

The primary/secondary mass ratios are among the most crucial parameters for the (elliptical) orbit geometry, I guess you agree ;-) . These are gotten, however, in RECONS via a quantitatively most dubious mass-luminosity relation, using the absolute magnitude values from the Gliese catalog as an input! Of course, RECONS/Gliese does not contain any standard orbit parameters...

In the past, I have prepared dozens of such mass-luminosity plots, trying to reduce (in vain) the number of undetermined entries in my binary data. I suppose, I don't have to emphasize the extremely large uncertainties that such relations imply for individual star systems. In the sense of statistical averages such relations may have some use, but NOT for individual stars (being often not even of main sequence type...). Here, fluctuations may be immense, depending on parameters, like metallicity etc. My binary orbit sets are largely of astrometric type, which is quite a different class of reliability, as you know.

Because I am aware of these inherent uncertainties since a long time, I have preferred to leave some of the respective entries with an attached '?'.
Other orbits have been checked against existing orbit plots just as you describe. We had some discussion about this years ago, when nearstars.stc was first created, and I recall offering examples from both Sirius and 61 Cyg. I made other checks at the time, orbit by orbit. Why would you imagine that I wouldn't have done this?
Oh good you did it. Sorry this must have slipped my mind... Such tests are so important (and fun, too) that I would have expected you to show the results here in the forum.
What would you like in order to be reassured about hierarchical systems? A check that the orbital definitions of "level 2" stay well within the Hill sphere defined by "level 1"? Or do you want a full dynamical simulation before accepting any multiple systems that have defined orbits from different sources?
I am happy, if the a posteriori fitted relative distances are shown to satisfy a hierarchical setup in all cases... Users are simply confronted with a set of numbers in nearstars, whithout any comments about such important underlying prerequisites. Actually I am aware that most multiple star systems tend to be pretty hierarchical, so it's really a matter of presenting explicit cross checks to be really sure.

Let me finally point out that quite a few of your alternative names are incompatible with the syntax accepted by SIMBAD (e.g Luyten xyz-w, Lacaille 9352, ...). Achieving total SIMBAD naming consistency would be another goal I would be very happy to see realized...It is very straightforward to do this using the SIMBAD scripting service. All you got to do is to produce a listing of your objects ( 1 column), to define a desired output format and then to submit. The resulting lists can easily be reduced to a few name classes.

Andrew has also accepted this suggestion of mine for his HIP star analysis with Perl. My Perl-based DSO database (galaxies, globulars) is SIMBAD compatible. My binary star database is in the process of being completely revised and improved considerably, including direct Perl-based ftp downloading and merging of different standard catalogs. Of course SIMBAD compatibility holds there, throughout. This is however all part of an ambitious ongoing project of mine and probably not relevant for Celestia proper, due to quite different views between ChrisL and myself.


Fridger
Image

granthutchison
Developer
Posts: 1863
Joined: 21.11.2002
With us: 22 years 2 months

Re: Binary Orbits Revisited!

Post #31by granthutchison » 09.03.2009, 20:07

t00fri wrote:The primary/secondary mass ratios are among the most crucial parameters for the (elliptical) orbit geometry, I guess you agree ;-) . These are gotten, however, in RECONS via a quantitatively most dubious mass-luminosity relation, using the absolute magnitude values from the Gliese catalog as an input! Of course, RECONS/Gliese does not contain any standard orbit parameters...
As I said, I have used S?derhjelm's data when it is available. That of course includes the total mass and mass ratio.

t00fri wrote:Let me finally point out that quite a few of your alternative names are incompatible with the syntax accepted by SIMBAD ...
Yes, a conscious decision on my part to use the familiar names for these stars, rather than Simbad's occasionally obscure and clumsy cataloguing terms. I doubt if many users would be sympathetic to Lacaille 9352 appearing in Celestia as NAME LACAILLE 9352, or would appreciate that the elder Struve's double stars are designated STF. There's a tension between accessibility and standardization here, and I wouldn't want to sacrifice one for the sake of the other. It seems to me the situation could be easily resolved with a parser that recognized a small number of standard catalogues and the small number of ways in which such catalogue names are commonly expressed. Then the user could type and see common names, while Celestia's internal representation was standardized.

Grant

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 10 months
Location: Hamburg, Germany

Re: Binary Orbits Revisited!

Post #32by t00fri » 09.03.2009, 20:29

granthutchison wrote:
t00fri wrote:The primary/secondary mass ratios are among the most crucial parameters for the (elliptical) orbit geometry, I guess you agree ;-) . These are gotten, however, in RECONS via a quantitatively most dubious mass-luminosity relation, using the absolute magnitude values from the Gliese catalog as an input! Of course, RECONS/Gliese does not contain any standard orbit parameters...
As I said, I have used S?derhjelm's data when it is available. That of course includes the total mass and mass ratio.

BUT that was definitely missing from your references...

Also, since you included data where I quit, there must be a number of systems where indeed the shaky mass-luminosity relation was used for determining the orbit geometry? Right? How big was the percentage in nearstars, if I may ask?


t00fri wrote:Let me finally point out that quite a few of your alternative names are incompatible with the syntax accepted by SIMBAD ...
Yes, a conscious decision on my part to use the familiar names for these stars, rather than Simbad's occasionally obscure and clumsy cataloguing terms. I doubt if many users would be sympathetic to Lacaille 9352 appearing in Celestia as NAME LACAILLE 9352, or would appreciate that the elder Struve's double stars are designated STF. There's a tension between accessibility and standardization here, and I wouldn't want to sacrifice one for the sake of the other. It seems to me the situation could be easily resolved with a parser that recognized a small number of standard catalogues and the small number of ways in which such catalogue names are commonly expressed. Then the user could type and see common names, while Celestia's internal representation was standardized.

Grant

I am not sure I understood: There is a star in nearstars, whose principal name is LACAILLE 9352, which is NOT recognized by SIMBAD.

But the idea is to filter the multitude of SIMBAD names with common sense by means of software (Perl in my case) . That is a very straightforward task. But is opens compatibility with extended searches via SIMBAD and it emphasizes the crucial aspect of standardization...

Fridger
Last edited by t00fri on 09.03.2009, 21:11, edited 2 times in total.
Image

chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 23 years
Location: Seattle, Washington, USA

Re: Binary Orbits Revisited!

Post #33by chris » 09.03.2009, 20:36

granthutchison wrote:
t00fri wrote:The primary/secondary mass ratios are among the most crucial parameters for the (elliptical) orbit geometry, I guess you agree ;-) . These are gotten, however, in RECONS via a quantitatively most dubious mass-luminosity relation, using the absolute magnitude values from the Gliese catalog as an input! Of course, RECONS/Gliese does not contain any standard orbit parameters...
As I said, I have used S?derhjelm's data when it is available. That of course includes the total mass and mass ratio.

t00fri wrote:Let me finally point out that quite a few of your alternative names are incompatible with the syntax accepted by SIMBAD ...
Yes, a conscious decision on my part to use the familiar names for these stars, rather than Simbad's occasionally obscure and clumsy cataloguing terms. I doubt if many users would be sympathetic to Lacaille 9352 appearing in Celestia as NAME LACAILLE 9352, or would appreciate that the elder Struve's double stars are designated STF. There's a tension between accessibility and standardization here, and I wouldn't want to sacrifice one for the sake of the other. It seems to me the situation could be easily resolved with a parser that recognized a small number of standard catalogues and the small number of ways in which such catalogue names are commonly expressed. Then the user could type and see common names, while Celestia's internal representation was standardized.

I agree that making the parser smarter is a sensible way to handle the conflict. It probably makes sense to store the names in the standardized format recognized by SIMBAD, display the familiar names, and accept either as user input.

--Chris

granthutchison
Developer
Posts: 1863
Joined: 21.11.2002
With us: 22 years 2 months

Re: Binary Orbits Revisited!

Post #34by granthutchison » 09.03.2009, 21:49

t00fri wrote:
granthutchison wrote:
t00fri wrote:The primary/secondary mass ratios are among the most crucial parameters for the (elliptical) orbit geometry, I guess you agree ;-) . These are gotten, however, in RECONS via a quantitatively most dubious mass-luminosity relation, using the absolute magnitude values from the Gliese catalog as an input! Of course, RECONS/Gliese does not contain any standard orbit parameters...
As I said, I have used S?derhjelm's data when it is available. That of course includes the total mass and mass ratio.
BUT that was definitely missing from your references...
We seem to be at cross-purposes. I make specific reference to S?derhjelm at the head of the file. Why would I use an orbital solution based on specific masses, without using those masses? Is that really something that requires specific comment?

t00fri wrote:Also, since you included data where I quit, there must be a number of systems where indeed the shaky mass-luminosity relation was used for determining the orbit geometry? Right? How big was the percentage in nearstars, if I may ask?
The assumed masses are recorded in nearstars.stc for every orbital solution. Sources are given at the head of the file, and any more specific references supplied throughout.

t00fri wrote:
granthutchison wrote:
t00fri wrote:Let me finally point out that quite a few of your alternative names are incompatible with the syntax accepted by SIMBAD ...
Yes, a conscious decision on my part to use the familiar names for these stars, rather than Simbad's occasionally obscure and clumsy cataloguing terms. I doubt if many users would be sympathetic to Lacaille 9352 appearing in Celestia as NAME LACAILLE 9352, or would appreciate that the elder Struve's double stars are designated STF. There's a tension between accessibility and standardization here, and I wouldn't want to sacrifice one for the sake of the other. It seems to me the situation could be easily resolved with a parser that recognized a small number of standard catalogues and the small number of ways in which such catalogue names are commonly expressed. Then the user could type and see common names, while Celestia's internal representation was standardized.
I am not sure I understood: There is a star in nearstars, whose principal name is LACAILLE 9352, which is NOT recognized by SIMBAD.
Try typing "NAME LACAILLE 9352": Simbad recognizes that. Do you think it is a good idea for Celestia to call the star "Name Lacaille 9352"?

Grant
Last edited by granthutchison on 09.03.2009, 22:06, edited 2 times in total.

granthutchison
Developer
Posts: 1863
Joined: 21.11.2002
With us: 22 years 2 months

Re: Binary Orbits Revisited!

Post #35by granthutchison » 09.03.2009, 22:04

chris wrote:I agree that making the parser smarter is a sensible way to handle the conflict. It probably makes sense to store the names in the standardized format recognized by SIMBAD, display the familiar names, and accept either as user input.
That's exactly what I had in mind. :)
The next question would be how far you'd be prepared to go with such parsing, and what confusion might arise. I think GJ/Gl/Gliese is probably safe enough. There's unlikely to be confusion with Struve and STF, though the plethora of "?"s spawned by the Struves might be better avoided. But is every entry beginning "L ..." part of the Luyten catalog? Is every "G ..." a Giclas? Do you even want to get into trying to parse the Durchmusterungs? (Sorry, Fridger. Durchmusterungen.)

Grant

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 10 months
Location: Hamburg, Germany

Re: Binary Orbits Revisited!

Post #36by t00fri » 09.03.2009, 22:14

granthutchison wrote:
I am not sure I understood: There is a star in nearstars, whose principal name is LACAILLE 9352, which is NOT recognized by SIMBAD.
Try typing "NAME LACAILLE 9352": Simbad recognizes that. Do you think it is a good idea for Celestia to call the star "Name Lacaille 9352"?

Grant

Oh sorry, now I understand what you meant. Yes that is unfortunate...But SIMBAD uses the Name attribute in order to resolve ambiguities. I knew that from my galaxies already.

Fridger
Last edited by t00fri on 09.03.2009, 22:28, edited 1 time in total.
Image

granthutchison
Developer
Posts: 1863
Joined: 21.11.2002
With us: 22 years 2 months

Re: Binary Orbits Revisited!

Post #37by granthutchison » 09.03.2009, 22:27

granthutchison wrote:But is every entry beginning "L ..." part of the Luyten catalog? Is every "G ..." a Giclas?
Oh, sorry, I've got that backwards. You'd be storing the "L " and "G " forms, and the user would have the option of typing "Luyten "or "Giclas ". So that's an easy parse, just so long as users don't go crazy by typing "Luyten Half-Second" for "LHS" or "Luyten Palomar" for "LP" ...

Grant

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 10 months
Location: Hamburg, Germany

Re: Binary Orbits Revisited!

Post #38by t00fri » 09.03.2009, 22:54

granthutchison wrote:
t00fri wrote:BUT that was definitely missing from your references...
We seem to be at cross-purposes. I make specific reference to S?derhjelm at the head of the file. Why would I use an orbital solution based on specific masses, without using those masses? Is that really something that requires specific comment?

Sorry, please help me, I am feeling a bit stupid now: As far as I could make out, for visual binaries, you are only refering to the "Sixth Catalog of Orbits of Visual Binary Stars (http://ad.usno.navy.mil/wds/orb6.html)" in the nearstars header (besides RECONS). The sixth catalog is by William I. Hartkopf & Brian D. Mason, NOT by Soederhjelm, AND it does not give mass ratios or equivalently q-values. So I inferred that your mass ratios for visuals must have come from the shaky mass-luminosity relation in RECONS.

What did I overread??

Thanks, Fridger
Image

granthutchison
Developer
Posts: 1863
Joined: 21.11.2002
With us: 22 years 2 months

Re: Binary Orbits Revisited!

Post #39by granthutchison » 10.03.2009, 00:04

t00fri wrote:Sorry, please help me, I am feeling a bit stupid now: As far as I could make out, for visual binaries, you are only refering to the "Sixth Catalog of Orbits of Visual Binary Stars (http://ad.usno.navy.mil/wds/orb6.html)" in the nearstars header (besides RECONS). The sixth catalog is by William I. Hartkopf & Brian D. Mason, NOT by Soederhjelm, AND it does not give mass ratios or equivalently q-values. So I inferred that your mass ratios for visuals must have come from the shaky mass-luminosity relation in RECONS.

What did I overread??

I'm sorry, I understood that you updated from SVN very frequently, so i thought you would be looking at the current header information.
A new version of nearstars.stc has been on SVN for a week. The relevant part of the header reads:

Code: Select all

# Orbits are taken from Staffan S?derhjelm's "Visual binary orbits and
# masses post Hipparcos" A&A 1999; 34: 121-40
# (http://adsabs.harvard.edu/abs/1999A&A...341..121S), unless newer data
# have been found. If orbits don't appear in S?derhjelm, they have been
# taken from the Sixth Catalog of Orbits of Visual Binary Stars
# (http://ad.usno.navy.mil/wds/orb6.html) and the Ninth Catalogue of
# Spectroscopic Binary Orbits (http://sb9.astro.ulb.ac.be). Other sources
# appear as comments for individual star systems.

Grant

Avatar
Topic author
t00fri
Developer
Posts: 8772
Joined: 29.03.2002
Age: 22
With us: 22 years 10 months
Location: Hamburg, Germany

Re: Binary Orbits Revisited!

Post #40by t00fri » 10.03.2009, 00:15

granthutchison wrote:
t00fri wrote:Sorry, please help me, I am feeling a bit stupid now: As far as I could make out, for visual binaries, you are only refering to the "Sixth Catalog of Orbits of Visual Binary Stars (http://ad.usno.navy.mil/wds/orb6.html)" in the nearstars header (besides RECONS). The sixth catalog is by William I. Hartkopf & Brian D. Mason, NOT by Soederhjelm, AND it does not give mass ratios or equivalently q-values. So I inferred that your mass ratios for visuals must have come from the shaky mass-luminosity relation in RECONS.

What did I overread??

I'm sorry, I understood that you updated from SVN very frequently, so i thought you would be looking at the current header information.
A new version of nearstars.stc has been on SVN for a week. The relevant part of the header reads:

Code: Select all

# Orbits are taken from Staffan S?derhjelm's "Visual binary orbits and
# masses post Hipparcos" A&A 1999; 34: 121-40
# (http://adsabs.harvard.edu/abs/1999A&A...341..121S), unless newer data
# have been found. If orbits don't appear in S?derhjelm, they have been
# taken from the Sixth Catalog of Orbits of Visual Binary Stars
# (http://ad.usno.navy.mil/wds/orb6.html) and the Ninth Catalogue of
# Spectroscopic Binary Orbits (http://sb9.astro.ulb.ac.be). Other sources
# appear as comments for individual star systems.

Grant

Oha! Now I understand...thank you for clearing this up. So we are meanwhile really using the same sources apart from additional parameters. 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?

It is indeed correct that I usually update from SVN on an almost daily rate, but exactly during last week I was working hard on Celesltia.Sci, hence did not update at all ;-) . Also I did not expect such a different header to come up suddenly.

Fridger
Image


Return to “Development”