stars.txt

[t00fri]

Really no intention from my side to snipe or blame anybody.

That's how it comes across, though--I've felt personally attacked throughout the discussion of the stars data file and binary star orbits, and it's challenging at times to respond to you in a civil and constructive manner. Please think about how you might present your points in a tone less likely to offend.

+++++++++++++
How about continuing our discussions in German from time to time or in French if you prefer!?
+++++++++++++

You would soon recognize this way that using proper politeness attributes in other languages than your native one, is among the hardest challenges, notably if you happen to speak certain languages VERY fluently (as I do, I think)...

I told you and others many times that we have different patterns of "politeness embellishments". I am sure Anglosaxons also find Cham's way of arguing a little too "direct" at times. He obviously has a French (Canadian) background. I rarely have a problem with our French friends, here, for example.

Bye Fridger

PS: Yes to speak it out once more. I am still upset that in Noordwijk you did not cite your Celestia team in writing. You know what I think about this! That certainly has an effect here and there.

[symaski62]

re

HIP 375 => CCDM J00046+3416C Parallaxes mas: 6.13
HIP 455 => CCDM J00055+7617B Parallaxes mas: 6.35

[revent]

Agreed--CCDM is apparently not a reliable way to find bound pairs. There may be some other information in the data set that will help us figure out which stars are actually bound and which are merely optical doubles.

Could proper motion be used as a criterion for deciding whether the stars constitute a true binary? The proper motion is listed in both the Hipparcos catalogue and in CCDM.

Not a good idea, at least with regards to Hipparcos data. Since the PMs in Hipparcos are 'instantaneous' pm's (i.e. determined only over the ~3 year span of the Hipparcos experiment), it's entirely possible for the components of a binary to have PMs that are very different.

Actually, bad PMs are the cause of quite a few of the bad parallaxes in the Hipparcos data, because if the PM is incorrect the 'missing' part of the proper motion shows up in the parallax.

It would probably be /quite/ productive to run a comparison between the data Celestia uses and the ARIHIP catalog, since from what I understand the use of the GC and other old catalogs with HIP in constructing it improved a lot of the parallaxes.

[t00fri]

It would probably be /quite/ productive to run a comparison between the data Celestia uses and the ARIHIP catalog, since from what I understand the use of the GC and other old catalogs with HIP in constructing it improved a lot of the parallaxes.

Looks like a good idea. I glanced at the ARIHIP catalog.
We might use the improved PM's from ARIHIP to derive from the CCDM flags more reliable ones as to physical binaries

Bye Fridger

[bdm]

I'm using the standard installation for Celestia 1.4.1, and I have found that the 1.4.1 installation has two stars named Chi Dra B. One appears to orbit the Chi Dra barycenter, and the other is floating in space about 0.5 light years away.

Has this been fixed in 1.5?

[t00fri]

I am trying to arrive at a reasonable compromise for 1.5.0pre3 in this "jungle" of star.txt data and their partial corrections in revised.stc along with my visualbins and spectbins orbital data.

What I did today, is a modification of my PERL scripts for binary orbits to the following extent:

++++++++++++++++++++++
In visualbins.pl and spectbins.pl:
----------------------------------------
I first merge stars.txt with the Celestia revision file revised.stc and THEN extract the coordinates, and distances etc from the resulting data, in order not to mess around with somewhat different values of Celestia's stars and my binary orbit data.

HOWEVER:
If --despite revised.stc-- the distances still differ by more than 10%, I prefer to use Soederhjelm's and Pourbaix's original distance values.
++++++++++++++++++++++++++

These are the bad guys left over in visualbins:

Code: Select all

Distance mismatch of  19.05 % with (revised) stars.txt for HIP 20916
Distance mismatch of  14.70 % with (revised) stars.txt for HIP 40239
Distance mismatch of  21.96 % with (revised) stars.txt for HIP 71914
Distance mismatch of 560.78 % with (revised) stars.txt for HIP 85582


and in spectbins:

Code: Select all

Distance mismatch of 47.50 % with (revised) stars.txt for HIP 10644
Distance mismatch of 15.57 % with (revised) stars.txt for HIP 14328
Distance mismatch of 36.59 % with (revised) stars.txt for HIP 91636
Distance mismatch of 23.24 % with (revised) stars.txt for HIP 99473
Distance mismatch of 18.49 % with (revised) stars.txt for HIP 108917


Notably HIP 85582 has a completely wrong distance of 524 ly that remains UNCORRECTED in revised.stc. As I said, In this case I retain Soederhjelm's correct value of 79.358511 ly that is in agreement with SIMBAD.

The other three listed distances (HIP 20916, HIP 40239, HIP 71914) are probably also incorrect in stars.txt and someone with "hand editing authority" should take care of this in Celestia's star data ...

++++++++++++++++++++
Anyway, in my visualbins and spectbins data files, things will be correct.
++++++++++++++++++++

Moreover, as extensively discussed elsewhere,
http://www.celestiaproject.net/forum/viewtopic ... 18&start=0

for del Equ = HIP 104858 I use the somewhat preferrable data from spectbins.stc .

In the light of all this I shall commit tonight revised data sets for visualbins.stc and spectbins.stc along with the updated PERL scripts.

I actually noticed that my last binary PERL scripts for some reason have arrived in the wrong directory (stardb) in CVS. This I shall also correct.

Bye Fridger

[t00fri]

Respective updates are in CVS.

Have look whether something looks fishy with the binary orbits.

Bye Fridger

[Cham]

There are still lots of problems with the binaries (mostly duplicates), that I've indicated elsewhere. Many stars are in double, or have a different name while they are actually the same (see the other thread about this). Several are also having some "funky" name variations (KHI, CHI, ...) Can't the binaries be corrected and updated on CVS ?

[t00fri]

There are still lots of problems with the binaries (mostly duplicates), that I've indicated elsewhere. Many stars are in double, or have a different name while they are actually the same (see the other thread about this). Several are also having some "funky" name variations (KHI, CHI, ...) Can't the binaries be corrected and updated on CVS ?

Martin,

let me really get this "dramatized" statement of yours in proper relation!

In my two binary orbit data sets (visual and spectroscopic, respectively), there is still a handful of binaries that happened to be identical systems but carry quite different names. Hence their identity was overlooked and you kindly sorted them out quite a while ago. In addition, there was a slight clash with the Celestia naming conventions of Greek letter names relative to the original publications of these data.

Since the orbit parameters determined spectroscopically and visually turned mostly out VERY similar, one may take the present situation as an educational illustration about the (comparatively small) remaining measurement uncertainties! So it is quite instructive to observe how LITTLE the orbits of the same stars from within the two different data sets actually differ.

In summary it's all but a catastrophe! Otherwise I would have fixed these stars since a long time. The time consuming problem in this task is to find an objective criterion why to eliminate one orbit data set in favor of the other one about those few stars in question.

Given the absence of Chris L. for such a long time that blocked any further Celestia development, I did/do not feel in any kind of hurry and had/have better things to do, as you know well...

Bye Fridger

[hank]

Can't the binaries be corrected and updated on CVS ?

How would this be done? Who would do it?

I'm sure if corrected files were available there would be no problem getting them into CVS.

- Hank

[t00fri]

Can't the binaries be corrected and updated on CVS ?

How would this be done? Who would do it?

I'm sure if corrected files were available there would be no problem getting them into CVS.

- Hank

See my mail above. These refer to my datasets (visualbins & spectbins), didn't you know? These changes HAVE to be made via my PERL scripts that are in CVS. NO undocumented handicraft, please, after I worked for years to get the database properly documented...


Bye Fridger

[hank]

The time consuming problem in this task is to find an objective criterion why to eliminate one orbit data set in favor of the other one about those few stars in question.

Perhaps the duplicates could be removed to separate files (one for visual orbits and one for spectroscopic orbits), so that no data would be lost but either or both could be loaded as desired.

- Hank

[t00fri]

The time consuming problem in this task is to find an objective criterion why to eliminate one orbit data set in favor of the other one about those few stars in question.

Perhaps the duplicates could be removed to separate files (one for visual orbits and one for spectroscopic orbits), so that no data would be lost but either or both could be loaded as desired.

- Hank

The whole point is that I chose the PERL script approach, since PERL scripts represent a human readable concise documentation of ANY changes relative to the published datasets. That's why the mods have to be done via my visualbin.pl and spectbin.pl scripts in CVS. These scripts work with the original published datasets available in the net (which I have, of course). It's exactly the same strategy with my deepsky.dsc database of 10000+ galaxies. Any changes ONLY via my deepsky.pl PERL script. Etc...

I am really surprised that you seem to have no idea about this whole very important background...

Bye Fridger

[hank]

See my mail above. These refer to my datasets (visualbins & spectbins), didn't you know? These changes HAVE to be made via my PERL scripts that are in CVS. NO undocumented handicraft, please, after I worked for years to get the database properly documented...

No, I didn't recall that there were separate datasets for your binary orbits. I didn't pay much attention to the details at the time because I knew the project was in your capable hands ;-) I was of course aware that the data preparation was carefully done and documented in your PERL scripts. Presumably PERL could be used to segregate the duplicate data.

- Hank

[t00fri]

See my mail above. These refer to my datasets (visualbins & spectbins), didn't you know? These changes HAVE to be made via my PERL scripts that are in CVS. NO undocumented handicraft, please, after I worked for years to get the database properly documented...

No, I didn't recall that there were separate datasets for your binary orbits. I didn't pay much attention to the details at the time because I knew the project was in your capable hands I was of course aware that the data preparation was carefully done and documented in your PERL scripts. Presumably PERL could be used to segregate the duplicate data.

- Hank

I would say the project is still in my capable hands . Nothing changed really. Except that after Chris L. took such a long (uncommented) break, now I am upset and need a break (to "cool down") .

Same rights for everyone?

Presumably PERL could be used to segregate the duplicate data.

Of course. That's what I did already earlier. See above. But also we have to agree about the final Greek letter naming of some of the stars etc. It's just work that is straightforward for me but for the time being it has NOT top priority. Up to now I have always managed to get my required changes into CVS before a new release. Also without your new management...

Bye Fridger

[hank]

Presumably PERL could be used to segregate the duplicate data.

Of course. That's what I did already earlier. See above.

I must have misunderstood. If the duplicates are already segregated from the non-duplicates, then isn't the only question which of the files of duplicates to load by default?

- Hank

[Cham]

There are still lots of problems with the binaries (mostly duplicates), that I've indicated elsewhere. Many stars are in double, or have a different name while they are actually the same (see the other thread about this). Several are also having some "funky" name variations (KHI, CHI, ...) Can't the binaries be corrected and updated on CVS ?

Martin,

let me really get this "dramatized" statement of yours in proper relation!

Well, "many" means just that : many, as in "several". And actually, yes, there are several doubles in the binaries database. This can't be used as a "pedagical tool" to show uncertainties : it just makes the students more confused. And the problem isn't just about doubles : in many cases, Celestia itself gets confused, since some stars have the exact same name, and we get a system with three stars misplaced in a given system with some clearly wrong orbits (instead of two binaries located at approximatively the same place). There's a conflict in Celestia itself.

And there's another aspect to this problem : it gives the strong impression that ALL the star database is very unreliable and unpredictable, since some elements from it are clearly severly wrong.

So yes, to me, this situation is "dramatic" in some sense.

[t00fri]

Presumably PERL could be used to segregate the duplicate data.

Of course. That's what I did already earlier. See above.

I must have misunderstood. If the duplicates are already segregated from the non-duplicates, then isn't the only question which of the files of duplicates to load by default?

- Hank

But that's what I explained in detail above. Martin located the handful overlooked doubles, so I have a complete list. I could just add a few PERL statements rerun the scripts and the doubles would be gone. That's so trivial, not worth loosing even one sentence.

What is a non-trivial astrophysics question, however, is which dataset to cross out and which to retain. Since that selection does not work dynamically, a physics based decision is required.

This in turn requires literature research and reading of respective papers...

So please don't mix up simple coding issues and underlying non-trivial astrophysics questions.

Bye Fridger

[hank]

But also we have to agree about the final Greek letter naming of some of the stars etc. It's just work that is straightforward for me but for the time being it has NOT top priority.

Sorry Fridger, I missed that part of your previous post. So there is more work to be done. Is this task on the list for 1.5.0? If it can't be completed in time, would it be better to leave the binary orbits out of 1.5.0 entirely?

- Hank

[t00fri]

There are still lots of problems with the binaries (mostly duplicates), that I've indicated elsewhere. Many stars are in double, or have a different name while they are actually the same (see the other thread about this). Several are also having some "funky" name variations (KHI, CHI, ...) Can't the binaries be corrected and updated on CVS ?

Martin,

let me really get this "dramatized" statement of yours in proper relation!

Well, "many" means just that : many, as in "several". And actually, yes, there are several doubles in the binaries database. This can't be used as a "pedagical tool" to show uncertainties : it just makes the students more confused. And the problem isn't just about doubles : in many cases, Celestia itself gets confused, since some stars have the exact same name, and we get a system with three stars misplaced in a given system (instead of two binaries located at approximatively the same place), with some clearly wrong orbits. There's a conflict in Celestia itself.

And there's another aspect to this problem : it gives the strong impression that ALL the star database is very unreliable and unpredictable, since some elements from it are clearly severly wrong.

So yes, to me, this situation is "dramatic" in some sense.

I disagree completely here.

If the teacher understands the meaning of two datasets that carry experimental uncertainties as every decent dataset does, the students could LEARN instead of being confused! But this was not at all my point and clearly soon or later the situation will get fixed. I was just using these educational aspects to illustrate that your statements were really "dramatized" (as in many other cases as most of us know very well )

If parameters of some of the world's best datasets differ, it cannot be easily stated whether one of them is WRONG! This again depends on the inherent uncertainties. Please don't try to teach me physics and how data have to be interpreted...

Bye Fridger