Binary orbits incompatible with radial velocities
Binary orbits incompatible with radial velocities
Hoping I'm making a silly mistake here...
It looks like the binary orbits we've got in Celestia are incompatible with radial velocity measurements.
According to Pourbaix et al. (2002), around 2000 the radial velocity of Alpha Centauri B was positive relative to the system velocity and decreasing, viceversa for A. Since radial velocity is positive for objects moving away from the star, this implies that in 2000, Alpha Centauri B was located further from the solar system than Alpha Centauri A  I have verified this by generating the expected radial velocities for this system given the Pourbaix et al. (1999) orbital elements used in visualbins.stc. In Celestia, it is Alpha Centauri A that is further away at this time. As a second check, I took a look at which way Alpha Centauri B was travelling during periastron: in Celestia it appears to be travelling away from the solar system, while the RVs show that it is moving towards the solar system during periastron.
Same goes for Gamma Persei when checked against the radial velocities in SB9: the RVs indicate that when component B passes through periastron it has a strong negative velocity (i.e. coming towards us), in Celestia it is receding from us during periastron.
As far as I can tell, it seems that the orbit conversion has been taking the zaxis of the coordinate system to be pointing in the wrong direction.
(Exoplanetary orbits on the other hand appear to be fine)
It looks like the binary orbits we've got in Celestia are incompatible with radial velocity measurements.
According to Pourbaix et al. (2002), around 2000 the radial velocity of Alpha Centauri B was positive relative to the system velocity and decreasing, viceversa for A. Since radial velocity is positive for objects moving away from the star, this implies that in 2000, Alpha Centauri B was located further from the solar system than Alpha Centauri A  I have verified this by generating the expected radial velocities for this system given the Pourbaix et al. (1999) orbital elements used in visualbins.stc. In Celestia, it is Alpha Centauri A that is further away at this time. As a second check, I took a look at which way Alpha Centauri B was travelling during periastron: in Celestia it appears to be travelling away from the solar system, while the RVs show that it is moving towards the solar system during periastron.
Same goes for Gamma Persei when checked against the radial velocities in SB9: the RVs indicate that when component B passes through periastron it has a strong negative velocity (i.e. coming towards us), in Celestia it is receding from us during periastron.
As far as I can tell, it seems that the orbit conversion has been taking the zaxis of the coordinate system to be pointing in the wrong direction.
(Exoplanetary orbits on the other hand appear to be fine)
 t00fri
 Developer
 Posts: 8772
 Joined: 29.03.2002
 Age: 17
 With us: 17 years 4 months
 Location: Hamburg, Germany
Re: Binary orbits incompatible with radial velocities
Andrew,
thanks for looking into this issue. Exactly 5 years ago, when I committed my binary orbits, I had checked the used coordinate definitions carefully. Moreover, years later, I scrupulously reconstructed the projections of MANY orbits onto the skyplane within Celestia and compared the results with direct binary star observations. The agreements were practically perfect. Qualitatively, I cannot see right away how a mixup of +z and z would have remained unnoticed in these tests. Unfortunately, Chris seems busy and hence ALL my respective orbitimages are unreachable for now (being part of my shatters.net account that he did not yet transfer to the new server). I wrote him 2 mails, but he is only marginally reactive these days.
On the other hand, given Celestia's untransparent coordinate documentation in 2005, such a sign error can perhaps not be excluded. One should also take into consideration that my checks took place before lots of coordinaterelated changes have been introduced in the code by Chris, including frames and "all that". I have never seen a clearcut crosscheck that guarantees the identity of "before and after".
I certainly would be grateful for possibly more direct crosschecks against measured data.
I cannot imagine that after interchanging +z and z in my Perl code for the orbits, the resulting orbit projections onto the skyplane would look identical! Hence by comparing with the published earthbound orbit observations, an independent judgement should be possible.
Unfortunately, I am also very busy these days and thus can't spent much time with this right now.
Fridger
PS: 5 years ago, I also compared my transformation from the skyplane to the Celestia frame with the results from the EXEL program by Grant Hutchison. The agreement was perfect. The derivation of our rotation formulae was done independently, though...
thanks for looking into this issue. Exactly 5 years ago, when I committed my binary orbits, I had checked the used coordinate definitions carefully. Moreover, years later, I scrupulously reconstructed the projections of MANY orbits onto the skyplane within Celestia and compared the results with direct binary star observations. The agreements were practically perfect. Qualitatively, I cannot see right away how a mixup of +z and z would have remained unnoticed in these tests. Unfortunately, Chris seems busy and hence ALL my respective orbitimages are unreachable for now (being part of my shatters.net account that he did not yet transfer to the new server). I wrote him 2 mails, but he is only marginally reactive these days.
On the other hand, given Celestia's untransparent coordinate documentation in 2005, such a sign error can perhaps not be excluded. One should also take into consideration that my checks took place before lots of coordinaterelated changes have been introduced in the code by Chris, including frames and "all that". I have never seen a clearcut crosscheck that guarantees the identity of "before and after".
I certainly would be grateful for possibly more direct crosschecks against measured data.
I cannot imagine that after interchanging +z and z in my Perl code for the orbits, the resulting orbit projections onto the skyplane would look identical! Hence by comparing with the published earthbound orbit observations, an independent judgement should be possible.
Unfortunately, I am also very busy these days and thus can't spent much time with this right now.
Fridger
PS: 5 years ago, I also compared my transformation from the skyplane to the Celestia frame with the results from the EXEL program by Grant Hutchison. The agreement was perfect. The derivation of our rotation formulae was done independently, though...
 t00fri
 Developer
 Posts: 8772
 Joined: 29.03.2002
 Age: 17
 With us: 17 years 4 months
 Location: Hamburg, Germany
Re: Binary orbits incompatible with radial velocities
Andrew,
I just checked quickly the distances from Earth of alf cen A and B, respectively. I noticed that on Jul 4th, 2000 the difference only occurs in the 3rd digit(!):
alf cen A: d= 4.3652 ly, alf cen B: d=4.3647 ly.
Therefore, I hope that in your investigations you took into account the (given) uncertainties of the resulting orbital solutions for alf cen?
As I wrote, I only have little time for now, and I might have been too fast with my crosschecks.
Fridger
I just checked quickly the distances from Earth of alf cen A and B, respectively. I noticed that on Jul 4th, 2000 the difference only occurs in the 3rd digit(!):
alf cen A: d= 4.3652 ly, alf cen B: d=4.3647 ly.
Therefore, I hope that in your investigations you took into account the (given) uncertainties of the resulting orbital solutions for alf cen?
As I wrote, I only have little time for now, and I might have been too fast with my crosschecks.
Fridger
 Hungry4info
 Posts: 1133
 Joined: 11.09.2005
 With us: 13 years 11 months
 Location: Indiana, United States
Re: Binary orbits incompatible with radial velocities
t00fri wrote:alf cen A: d= 4.3652 ly, alf cen B: d=4.3647 ly.
This would be favourable for distinguishing the radial velocity of the two components.
I loaded up Celestia and checked for July 2000, and found ? Cen B to indeed be moving toward Earth and ? Cen A moved away. As well as ? Cen B moving away from the Solar System during perihelion.
Edit:
Taking the RV data from Endl et al. (2001), ? Cen B shows blueshifting representative of the star approaching Earth at increasing speeds, whereas in Celestia at the same time, ? Cen B is shown slowing its approach toward Earth. The RV slope in the Endl et al. data is negative, whereas a positive slope would be expected from Celestia's reperesentation of the system.
So I confirm ajtribick's finding.
Current Setup:
Windows 7 64 bit. Celestia 1.6.0.
AMD Athlon Processor, 1.6 Ghz, 3 Gb RAM
ATI Radeon HD 3200 Graphics
Windows 7 64 bit. Celestia 1.6.0.
AMD Athlon Processor, 1.6 Ghz, 3 Gb RAM
ATI Radeon HD 3200 Graphics
Re: Binary orbits incompatible with radial velocities
Fridger  I am not performing checks on the absolute distances from Earth but on the positions relative to the system barycentre. From the RV curves it is possible to determine which component is closer or further away, without needing to take absolute distance into account. One thing I suspect may lead to easier confusion with regard to zcoordinates is that the system provided by Grant's spreadsheets appears to take +z as being in the direction from the star to Earth, while the radial velocity measurement takes +z as the direction away from Earth.
Hungry4info  Thanks for the independent check.
Proceeding further, definitely the orbital plots would be useful. If we are in the situation where only the zaxis needs to be flipped, from the ThieleInnes constants it is clear that the transformation to make to the orbital elements (before converting to the ecliptic frame) is ???+180°, ???+180°.
Hungry4info  Thanks for the independent check.
Proceeding further, definitely the orbital plots would be useful. If we are in the situation where only the zaxis needs to be flipped, from the ThieleInnes constants it is clear that the transformation to make to the orbital elements (before converting to the ecliptic frame) is ???+180°, ???+180°.
 t00fri
 Developer
 Posts: 8772
 Joined: 29.03.2002
 Age: 17
 With us: 17 years 4 months
 Location: Hamburg, Germany
Re: Binary orbits incompatible with radial velocities
ajtribick wrote:Fridger  I am not performing checks on the absolute distances from Earth but on the positions relative to the system barycentre. From the RV curves it is possible to determine which component is closer or further away, without needing to take absolute distance into account. One thing I suspect may lead to easier confusion with regard to zcoordinates is that the system provided by Grant's spreadsheets appears to take +z as being in the direction from the star to Earth, while the radial velocity measurement takes +z as the direction away from Earth.
Are you saying that Grant's and my +zaxis disagrees with the +zconventions in Celestia or not? I suppose there is consistency. You then seem to suggest that due to a differing zaxis convention for the radial velocity in the respective scientific literature , the parameter transformations ???+180°, ???+180° relative to the given data tables should have been used?
Proceeding further, definitely the orbital plots would be useful. If we are in the situation where only the zaxis needs to be flipped, from the ThieleInnes constants it is clear that the transformation to make to the orbital elements (before converting to the ecliptic frame) is ???+180°, ???+180°.
Well I hope it won't be long until I get again access to all my orbitchecks.
Meanwhile, I found two examples of my testimages on my harddisk:
Procyon:
========
70 Oph:
======
+++++++++++++++++++++++++++++++++++++++++
Apparently, in view of existing uncertainties, the agreement with observations is perfect! This amount of precision seems improbable, if my Perl script had mixedup +z and z or if I should have taken ???+180°, ???+180°. Note that I am comparing here Celestia's results with the cleanest and most direct kinds of binary orbit measurements!
+++++++++++++++++++++++++++++++++++++++++
In the original Pourbaix paper, errors were given explicitly for ALL orbital parameters. My first question would be whether it is excluded to reverse the radial velocity configuration for 2000 by exploiting these uncertainties at the 1 sigma level?
My impression so far was that the compatibility of the original, published orbit solutions (that I used) with the new radial velocity data were examined only later (2002). Compatibility seems far from being automatic! Since there are measurement uncertainties and systematic errors involved, it is not a priori obvious to me whether the compatibility of the original fit solutions can be expected at all? The fits are multiparameter minimizations in the presence of uncertainties. This setting may easily imply non  unique results...
Fridger
PS: To avoid misunderstandings, would it be possible that you describe concisely the numerical tests that you did for reaching your claims?
Re: Binary orbits incompatible with radial velocities
I've just done the comparison of ? Andromedae: the skyplane orbits definitely match, including orbital direction. Of course matching the skyplane orbits can be done for two configurations, you need the RVs to resolve the degeneracy between the two which are related by ???+180°, ???+180°. This is certainly outside the 1? parameter range for the orbits.
Regarding radial velocities: the Pourbaix et al. (2000) paper referenced in spectbins.stc is explicitly devoted to combining spectroscopic and visual orbits, and mention they rejected some orbits because of radial velocity data issues. So clearly they are taking into account the radial velocities.
Unfortunately it doesn't help that there seem to be several conventions for the coordinate systems used between various papers: for example the paper I used to compare the orbital plot of ? Andromedae (Pan et al., 1992) quotes ?=77°, ?=104°, i=105°, as opposed to Pourbaix et al. (2000) who give ?=257°, ?=284°, i=105°. Both sets of elements give the same skyplane plot, including orbital direction. Given the choice of coordinate systems, and the convention about which component of the system the ? is given for (none of which are usually stated in the papers themselves), it seems quite easy to run into difficulties!
Indeed as far as I can make out, Pourbaix et al. (2000) are using a lefthanded coordinate system, with +x in the direction of increasing declination, +y in the direction of increasing right ascension, and +z away from Earth, and quoting ? for the secondary. Celestia elements on the other hand are righthanded, and the change between the two is not being accounted for in the transformation. (Incidentally the exoplanets work because we don't need to match skyplane orbits, leaving us free to choose whether ? refers to the star or the planet without breaking anything.)
Haven't looked at S?derhjelm yet, given the degeneracy involved in 3D matching of skyplane orbits I am not sure it is particularly worthwhile for visual binaries...
Regarding radial velocities: the Pourbaix et al. (2000) paper referenced in spectbins.stc is explicitly devoted to combining spectroscopic and visual orbits, and mention they rejected some orbits because of radial velocity data issues. So clearly they are taking into account the radial velocities.
Unfortunately it doesn't help that there seem to be several conventions for the coordinate systems used between various papers: for example the paper I used to compare the orbital plot of ? Andromedae (Pan et al., 1992) quotes ?=77°, ?=104°, i=105°, as opposed to Pourbaix et al. (2000) who give ?=257°, ?=284°, i=105°. Both sets of elements give the same skyplane plot, including orbital direction. Given the choice of coordinate systems, and the convention about which component of the system the ? is given for (none of which are usually stated in the papers themselves), it seems quite easy to run into difficulties!
Indeed as far as I can make out, Pourbaix et al. (2000) are using a lefthanded coordinate system, with +x in the direction of increasing declination, +y in the direction of increasing right ascension, and +z away from Earth, and quoting ? for the secondary. Celestia elements on the other hand are righthanded, and the change between the two is not being accounted for in the transformation. (Incidentally the exoplanets work because we don't need to match skyplane orbits, leaving us free to choose whether ? refers to the star or the planet without breaking anything.)
Haven't looked at S?derhjelm yet, given the degeneracy involved in 3D matching of skyplane orbits I am not sure it is particularly worthwhile for visual binaries...
Re: Binary orbits incompatible with radial velocities
Quick summary of the mathematical details I am using:
The ThieleInnes constants are given by
A = a(cos ? cos ?  sin ? sin ? cos i)
B = a(sin ? cos ? + cos ? sin ? cos i)
F = a(cos ? sin ?  sin ? cos ? cos i)
G = a(sin ? sin ? + cos ? cos ? cos i)
The orbital position in the untransformed orbit by
x = cos E  e
y = ?(1  e?) sin E
Where E is the eccentric anomaly. Then in the sky plane the displacements are
X = Ax + Fy
Y = Bx + Gy
If we make the transformation ???+180°, ???+180°, it is clear that the ThieleInnes constants are unchanged, resulting in the exact same skyplane orbit. (This is the difficulty in identifying the ascending node of the orbit.)
Radial velocity on the other hand is given by
dZ/dt = K(cos (? + ?) + e cos ?)
Where ? is the true anomaly and K is the semiamplitude. Therefore when making the change ???+180° you invert the radial velocities, allowing identification of the ascending node.
All this is derivable from the rotation: first rotate about the Zaxis by ?, then about the Xaxis by i, then about the Zaxis by ?.
Now in matching the radial velocities, the measurements take positive V as movement away from Earth, so in the transformations you and Grant produced, we have to equate V=dZ/dt. However the Pourbaix et al. (2000) orbital elements give the required velocities by taking V=dZ/dt, hence the issue.
The ThieleInnes constants are given by
A = a(cos ? cos ?  sin ? sin ? cos i)
B = a(sin ? cos ? + cos ? sin ? cos i)
F = a(cos ? sin ?  sin ? cos ? cos i)
G = a(sin ? sin ? + cos ? cos ? cos i)
The orbital position in the untransformed orbit by
x = cos E  e
y = ?(1  e?) sin E
Where E is the eccentric anomaly. Then in the sky plane the displacements are
X = Ax + Fy
Y = Bx + Gy
If we make the transformation ???+180°, ???+180°, it is clear that the ThieleInnes constants are unchanged, resulting in the exact same skyplane orbit. (This is the difficulty in identifying the ascending node of the orbit.)
Radial velocity on the other hand is given by
dZ/dt = K(cos (? + ?) + e cos ?)
Where ? is the true anomaly and K is the semiamplitude. Therefore when making the change ???+180° you invert the radial velocities, allowing identification of the ascending node.
All this is derivable from the rotation: first rotate about the Zaxis by ?, then about the Xaxis by i, then about the Zaxis by ?.
Now in matching the radial velocities, the measurements take positive V as movement away from Earth, so in the transformations you and Grant produced, we have to equate V=dZ/dt. However the Pourbaix et al. (2000) orbital elements give the required velocities by taking V=dZ/dt, hence the issue.
Last edited by ajtribick on 10.07.2010, 11:31, edited 1 time in total.
 t00fri
 Developer
 Posts: 8772
 Joined: 29.03.2002
 Age: 17
 With us: 17 years 4 months
 Location: Hamburg, Germany
Re: Binary orbits incompatible with radial velocities
It means that my results for Celestia do NOT generate any observable discrepancy, except if radial velocity measurements are considered in addition. OK.ajtribick wrote:I've just done the comparison of ? Andromedae: the skyplane orbits definitely match, including orbital direction. Of course matching the skyplane orbits can be done for two configurations, you need the RVs to resolve the degeneracy between the two which are related by ???+180°, ???+180°. This is certainly outside the 1? parameter range for the orbits.
I really should see what calculations you actually did.
Ah! Crossposting...thanks for the details!
The transformation from the skyplane to Celestia's frame involve LOTS of atan's etc. Hence one MUST do such ???+180°, ???+180° operations MOST carefully! You sure know that atan's and other inverse trig functions in computing are defined for a fixed argument domain ...
unless you perhaps forgot the fixed argument domain of the atan's both in Grant's and my transformations! This is all VERY tricky stuff and thus may easily lead to mistakes.
Unfortunately it doesn't help that there seem to be several conventions for the coordinate systems used between various papers: for example the paper I used to compare the orbital plot of ? Andromedae (Pan et al., 1992) quotes ?=77°, ?=104°, i=105°, as opposed to Pourbaix et al. (2000) who give ?=257°, ?=284°, i=105°. Both sets of elements give the same skyplane plot, including orbital direction.
While it's >5 years ago that I explicitly checked, I seem to remember definitely that Celestia's original system was lefthanded! It always annoyed me, that's why I remember it . I am not sure whether some recent (poorly documented) changes took place in that respect?Indeed as far as I can make out, Pourbaix et al. (2000) are using a lefthanded coordinate system, with +x in the direction of increasing declination, +y in the direction of increasing right ascension, and +z away from Earth, and quoting ? for the secondary. Celestia elements on the other hand are righthanded,
Fridger
PS: too bad, LaTeX is also not yet activated on the new server....
 t00fri
 Developer
 Posts: 8772
 Joined: 29.03.2002
 Age: 17
 With us: 17 years 4 months
 Location: Hamburg, Germany
Re: Binary orbits incompatible with radial velocities
ajtribick wrote:...
Radial velocity on the other hand is given by
dZ/dt = K(cos (? + ?) + e cos ?)
Where ? is the true anomaly and K is the semiamplitude. Therefore when making the change ???+180° you invert the radial velocities, allowing identification of the ascending node.
All this is derivable from the rotation: first rotate about the Zaxis by ?, then about the Xaxis by i, then about the Zaxis by ?.
Now in matching the radial velocities, the measurements take positive V as movement away from Earth, so in the transformations you and Grant produced, we have to equate V=dZ/dt. However the Pourbaix et al. (2000) orbital elements give the required velocities by taking V=dZ/dt, hence the issue.
Thanks, Andrew,
that makes things much more transparent. It is of course close to no work to implement the ???+180°, ???+180° replacements in my Perl script and then to punch out corrected binary data files.
Looking at the ? and ? values in Pourbaix' original data table, there are many binaries with ?, ? close to 360 degrees. Adding 180 degrees does not make sense here. One first has to subtract 360 degrees here and then add 180 degs.
The next task would be to explicitly test whether the results from Celestia have indeed improved, as to the radial velocity data, while leaving the orbits unchanged. Note I am now talking about (gory) NUMERICAL math issues and NOT about analytical considerations
One perhaps interesting exercise would be to simply 'diff' the binary data files 'before and after' these changes. That might be instructive. Expected and unexpected symmetries or changes are then easily visible...
Any other suggestions?
One might even argue that it might be useful to always calculate the radial velocity for binaries in Celestia and display it e.g. in verbose mode on the canvas?
Celestia.Sci will eventually allow for general scientific plotting options. So plotting the skyplane orbits and radial velocities would certainly be a sensible application. Actually, Chris wrote a plotting module for the STA project. Plots could be easily generated via a celx interface as well.
Fridger
Re: Binary orbits incompatible with radial velocities
Further investigation...
While it looks like all the systems in Pourbaix et al. (2000) need updating, the situation is less clear for the visual binaries. Of the systems listed in table 1 of S?derhjelm (1999) that also have entries in SB9, 10 needed to be flipped in the radial direction, but 4 did not (HIP 44248, 45170, 60129, 104858). HIP 98416 appears to have orbital periods that differ by a factor of 2 between S?derhjelm and SB9.
While it looks like all the systems in Pourbaix et al. (2000) need updating, the situation is less clear for the visual binaries. Of the systems listed in table 1 of S?derhjelm (1999) that also have entries in SB9, 10 needed to be flipped in the radial direction, but 4 did not (HIP 44248, 45170, 60129, 104858). HIP 98416 appears to have orbital periods that differ by a factor of 2 between S?derhjelm and SB9.
 t00fri
 Developer
 Posts: 8772
 Joined: 29.03.2002
 Age: 17
 With us: 17 years 4 months
 Location: Hamburg, Germany
Re: Binary orbits incompatible with radial velocities
ajtribick wrote:Further investigation...
While it looks like all the systems in Pourbaix et al. (2000) need updating, the situation is less clear for the visual binaries. Of the systems listed in table 1 of S?derhjelm (1999) that also have entries in SB9, 10 needed to be flipped in the radial direction, but 4 did not (HIP 44248, 45170, 60129, 104858). HIP 98416 appears to have orbital periods that differ by a factor of 2 between S?derhjelm and SB9.
That looks rather untransparent, unfortunately!
I didn't check SB9 yet with regard to the used definition of the radial velocity. In general, one has to distinguish whether the observed RV or the one corrected for gravitational redshift, convective blueshift and for the zero points is quoted! The corrections can be large. It is only the corrected (relative) A, B radial velocities that are directly related to the component masses (kappa_A, kappa_B), not the observed RVs.
Did you check SB9 for the given definition?
From where exactly did you infer this??Indeed as far as I can make out, Pourbaix et al. (2000) are using a lefthanded coordinate system, with +x in the direction of increasing declination, +y in the direction of increasing right ascension, and +z away from Earth, and quoting ? for the secondary.
Fridger
Re: Binary orbits incompatible with radial velocities
Haven't checked for whether these factors are taken into account, however I am doing the comparison based on the shape of the curve and relative amplitudes of the variations.t00fri wrote:ajtribick wrote:Further investigation...
While it looks like all the systems in Pourbaix et al. (2000) need updating, the situation is less clear for the visual binaries. Of the systems listed in table 1 of S?derhjelm (1999) that also have entries in SB9, 10 needed to be flipped in the radial direction, but 4 did not (HIP 44248, 45170, 60129, 104858). HIP 98416 appears to have orbital periods that differ by a factor of 2 between S?derhjelm and SB9.
That looks rather untransparent, unfortunately!
I didn't check SB9 yet with regard to the used definition of the radial velocity. In general, one has to distinguish whether the observed RV or the one corrected for gravitational redshift, convective blueshift and for the zero points is quoted! The corrections can be large. It is only the corrected (relative) A, B radial velocities that are directly related to the component masses (kappa_A, kappa_B), not the observed RVs.
Did you check SB9 for the given definition?
This seems to be the coordinate system you need to use to simultaneously match the skyplane orbit plot and the radial velocities, using the equations I posted earlier. Alternatively you can redefine what rotations ?, i and ? represent, or perhaps the initial orientation of the unrotated orbit, and end up in a righthanded coordinate system.t00fri wrote:From where exactly did you infer this??Indeed as far as I can make out, Pourbaix et al. (2000) are using a lefthanded coordinate system, with +x in the direction of increasing declination, +y in the direction of increasing right ascension, and +z away from Earth, and quoting ? for the secondary.
(Note the system used by Grant's spreadsheet gives +x and +y in the same directions as I mentioned, it is only +z that is changed)
 t00fri
 Developer
 Posts: 8772
 Joined: 29.03.2002
 Age: 17
 With us: 17 years 4 months
 Location: Hamburg, Germany
Re: Binary orbits incompatible with radial velocities
Andrew,
as I have suggested yesterday,
I link here to a zipped 'experimental' directory bins_exp.zip
http://www.celestialmatters.org/users/t ... ns_exp.zip
with the following content:
vis_org.stc
vis_rot.stc
spect_org.stc
spect_rot.stc
log_vis.txt
log_spect.txt
the _org.stc files correspond to the original binary data from my Perl scripts (checked!), while the
_rot.stc files have been generated from the same Perl scripts with just the replacements:
$OMEGA += 180.0001;
$omega += 180.0001;
The log_*.txt files contain the diffs between the original and rotated data. They are always of the type
< Inclination 122.874
< AscendingNode 56.072
< ArgOfPericenter 213.139

> Inclination 39.116
> AscendingNode 201.107
> ArgOfPericenter 145.697
I thought it might be useful to play with the two variants in the context of our "radial velocity" issue. As I pointed out earlier, my results for the _rot.stc data might be incorrect due to the atan's and many if (....) expressions, depending on the signs of sums of products of trig functions, partially having $OMEGA and $omega as arguments.
Sorry I had no time for more thorough studies...
Fridger
as I have suggested yesterday,
that makes things much more transparent. It is of course close to no work to implement the ???+180°, ???+180° replacements in my Perl script and then to punch out corrected binary data files.
I link here to a zipped 'experimental' directory bins_exp.zip
http://www.celestialmatters.org/users/t ... ns_exp.zip
with the following content:
vis_org.stc
vis_rot.stc
spect_org.stc
spect_rot.stc
log_vis.txt
log_spect.txt
the _org.stc files correspond to the original binary data from my Perl scripts (checked!), while the
_rot.stc files have been generated from the same Perl scripts with just the replacements:
$OMEGA += 180.0001;
$omega += 180.0001;
The log_*.txt files contain the diffs between the original and rotated data. They are always of the type
< Inclination 122.874
< AscendingNode 56.072
< ArgOfPericenter 213.139

> Inclination 39.116
> AscendingNode 201.107
> ArgOfPericenter 145.697
I thought it might be useful to play with the two variants in the context of our "radial velocity" issue. As I pointed out earlier, my results for the _rot.stc data might be incorrect due to the atan's and many if (....) expressions, depending on the signs of sums of products of trig functions, partially having $OMEGA and $omega as arguments.
Sorry I had no time for more thorough studies...
Fridger

 Site Admin
 Posts: 4211
 Joined: 28.01.2002
 With us: 17 years 6 months
 Location: Seattle, Washington, USA
Re: Binary orbits incompatible with radial velocities
Fridger,
Once again, your tone is insulting... If you want to have a reasonable discussion with me, you'll need to restrain yourself from filling your posts with poorly targeted shots at my work.
Until Andrew introduced the sky plane frame, star orbits were always defined in Celestia's default ecliptical coordinate system. Thus, there's no way that Celestia's frames implementation could be the cause of the disagreement with radial velocity measurements. Anyhow, since they were added to Celestia, frames have been use successfully by quite a few space mission teams; their utility and correctness is wellestablished. As for 'untransparent coordinate documentation', I suppose you haven't bothered looking at the code:
or the WikiBook:
http://en.wikibooks.org/wiki/Celestia/Reference_Frames
To the best of my recollection, Celestia has never used a lefthanded coordinate system. It is however rotated 90 degrees from the conventional ecliptic coordinate system which has +z up instead of +y as in Celestia. That rotation certainly has caused a lot of headaches over the years.
Chris
Once again, your tone is insulting... If you want to have a reasonable discussion with me, you'll need to restrain yourself from filling your posts with poorly targeted shots at my work.
On the other hand, given Celestia's untransparent coordinate documentation in 2005, such a sign error can perhaps not be excluded. One should also take into consideration that my checks took place before lots of coordinaterelated changes have been introduced in the code by Chris, including frames and "all that". I have never seen a clearcut crosscheck that guarantees the identity of "before and after".
Until Andrew introduced the sky plane frame, star orbits were always defined in Celestia's default ecliptical coordinate system. Thus, there's no way that Celestia's frames implementation could be the cause of the disagreement with radial velocity measurements. Anyhow, since they were added to Celestia, frames have been use successfully by quite a few space mission teams; their utility and correctness is wellestablished. As for 'untransparent coordinate documentation', I suppose you haven't bothered looking at the code:
Code: Select all
/*! A BodyFixed frame is a coordinate system with the xaxis pointing
* from the body center through the intersection of the prime meridian
* and the equator, and the zaxis aligned with the north pole. The
* yaxis is the cross product of x and z, and points toward the 90
* meridian.
*/
or the WikiBook:
http://en.wikibooks.org/wiki/Celestia/Reference_Frames
t00fri wrote:While it's >5 years ago that I explicitly checked, I seem to remember definitely that Celestia's original system was lefthanded! It always annoyed me, that's why I remember it . I am not sure whether some recent (poorly documented) changes took place in that respect?
To the best of my recollection, Celestia has never used a lefthanded coordinate system. It is however rotated 90 degrees from the conventional ecliptic coordinate system which has +z up instead of +y as in Celestia. That rotation certainly has caused a lot of headaches over the years.
Chris
 t00fri
 Developer
 Posts: 8772
 Joined: 29.03.2002
 Age: 17
 With us: 17 years 4 months
 Location: Hamburg, Germany
Re: Binary orbits incompatible with radial velocities
Chris,
Sorry, if this sounded insulting to you. It was not intended to be so  as usual!
Note that I carefully referred above to the pre 2006 time, when the documentation of the Celestia coordinates was NOT laid down in a central place, as far as I could make out. The year 2005 was crucial in the context of our radial velocity discussion, since it was in 2005 that I tested and committed my binary star data base...
With the advent and considerable progress of the Celestia Wiki book documentation things have enormously improved. This I have never contested, however.
While I don't fancy your frames implementation very much (as we discussed earlier), I acknowledge its usefulness for specific practical applications in astrodynamics/celestial mechanics.
There may have been implicit tests of your framesrelated modifications after 2006 among people at NASA, ESA ... Yet, I cannot remember any systematic "before and after" tests of these massive code changes that were made accessible to the Celestia dev team. Since Andrew and I are hunting a VERY subtle issue related to Celestia's framedefinition, I made a respective remark above (merely as a note of caution, while time was lacking for going through the post2005code most carefully).
Fridger
chris wrote:Fridger,
Once again, your tone is insulting... If you want to have a reasonable discussion with me, you'll need to restrain yourself from filling your posts with poorly targeted shots at my work.On the other hand, given Celestia's untransparent coordinate documentation in 2005, such a sign error can perhaps not be excluded. One should also take into consideration that my checks took place before lots of coordinaterelated changes have been introduced in the code by Chris, including frames and "all that". I have never seen a clearcut crosscheck that guarantees the identity of "before and after".
Sorry, if this sounded insulting to you. It was not intended to be so  as usual!
Note that I carefully referred above to the pre 2006 time, when the documentation of the Celestia coordinates was NOT laid down in a central place, as far as I could make out. The year 2005 was crucial in the context of our radial velocity discussion, since it was in 2005 that I tested and committed my binary star data base...
With the advent and considerable progress of the Celestia Wiki book documentation things have enormously improved. This I have never contested, however.
While I don't fancy your frames implementation very much (as we discussed earlier), I acknowledge its usefulness for specific practical applications in astrodynamics/celestial mechanics.
There may have been implicit tests of your framesrelated modifications after 2006 among people at NASA, ESA ... Yet, I cannot remember any systematic "before and after" tests of these massive code changes that were made accessible to the Celestia dev team. Since Andrew and I are hunting a VERY subtle issue related to Celestia's framedefinition, I made a respective remark above (merely as a note of caution, while time was lacking for going through the post2005code most carefully).
Here it seems to me you effectively agree that the status of clarity about Celestia's coordinate frame was far from perfect in these earlier days of Celestia...chris wrote:...
It is however rotated 90 degrees from the conventional ecliptic coordinate system which has +z up instead of +y as in Celestia. That rotation certainly has caused a lot of headaches over the years.
Fridger
Last edited by t00fri on 06.07.2010, 10:27, edited 19 times in total.
Re: Binary orbits incompatible with radial velocities
Lets not get confused here: I have not implemented any reference frame stuff for .stc files. The SkyPlane reference frame (which matches Grant's spreadsheet and Fridger's binary orbits) is available for .ssc objects only. And I am seriously considering backing it out of the code if it turns out that the variant coordinate system discussed in this thread is the most common version. Trust an astronomyrelated discipline to use abominations like lefthanded coordinates, I suppose it is to be expected in a field where cgs units run rampant.
Also I think we should perhaps return to the subject at hand rather than trying to find insults in each others' posts, which won't get us anywhere.
Also I think we should perhaps return to the subject at hand rather than trying to find insults in each others' posts, which won't get us anywhere.

 Site Admin
 Posts: 4211
 Joined: 28.01.2002
 With us: 17 years 6 months
 Location: Seattle, Washington, USA
Re: Binary orbits incompatible with radial velocities
Pardon the confusion: I'd forgotten this was ssc only. Without actually double checking the source, I thought that you'd also added code to translate from the sky plane coordinate system to the internal coordinate system at load time.ajtribick wrote:Lets not get confused here: I have not implemented any reference frame stuff for .stc files. The SkyPlane reference frame (which matches Grant's spreadsheet and Fridger's binary orbits) is available for .ssc objects only.
Chris
 t00fri
 Developer
 Posts: 8772
 Joined: 29.03.2002
 Age: 17
 With us: 17 years 4 months
 Location: Hamburg, Germany
Re: Binary orbits incompatible with radial velocities
As Andrew showed, flipping the zaxis in the skyplane frame amounts to the transformation
???+180°, ???+180° . After generating the corresponding visualbins.stc and spectbins.stc via Perl, it is indeed impressive to confirm within Celestia that the skyplane projection is not at all affected, while the radial velocity is! That is a nice crosscheck at the end of the 'pipeline'.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
In this post, I want to add a different twist to this discussion, by considering another transformation that leads to precisely the same orbits as ???+180°, ???+180°.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
One of the initial orbital elements is the orbital inclination i . For binaries, the inclination is originally specified relative to the plane of the sky. For Celestia we need to transform i into the output Inclination wrto the ecliptical frame.
+++++++++++++++++++++++++++++++++
It is also directly related to the definition of the zaxis. Flipping the zaxix (in the skyplane frame) from positive to negative, amounts to the transformation i > i
+++++++++++++++++++++++++++++++++
For completeness, let me now consider my Perl routine RotOrbits linebyline that does the transformation from the skyplane frame to Celestia's ecliptical frame. It will be instructive to see why the effect of ???+180°, ???+180° is identical to the replacement of i > i with ?, ? untouched!
Here is the routine as a reference
Since we are now talking about lots of math and since LaTeX still doesn't work with the new server, I will continue with a well commented Maple worksheet. Here it is
Note, the only orbital output parameters (in the Celestia ecliptical frame) that are affected by
???+180°, ???+180° or equivalently i > i are only the following three
$Inclination
$AscendingNode
$ArgOfPeri
This I have also checked numerically, of course. There are now various possible interpretations about using i > i. Before getting to that, I let you first digest this result, perhaps...
Fridger
???+180°, ???+180° . After generating the corresponding visualbins.stc and spectbins.stc via Perl, it is indeed impressive to confirm within Celestia that the skyplane projection is not at all affected, while the radial velocity is! That is a nice crosscheck at the end of the 'pipeline'.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
In this post, I want to add a different twist to this discussion, by considering another transformation that leads to precisely the same orbits as ???+180°, ???+180°.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
One of the initial orbital elements is the orbital inclination i . For binaries, the inclination is originally specified relative to the plane of the sky. For Celestia we need to transform i into the output Inclination wrto the ecliptical frame.
+++++++++++++++++++++++++++++++++
It is also directly related to the definition of the zaxis. Flipping the zaxix (in the skyplane frame) from positive to negative, amounts to the transformation i > i
+++++++++++++++++++++++++++++++++
For completeness, let me now consider my Perl routine RotOrbits linebyline that does the transformation from the skyplane frame to Celestia's ecliptical frame. It will be instructive to see why the effect of ???+180°, ???+180° is identical to the replacement of i > i with ?, ? untouched!
Here is the routine as a reference
Code: Select all
sub RotOrbits {
my($ra_deg,$del_deg,$P,$a_arcsec,$i,$PA_of_Node,$Epoch_of_peri,$e,$Arg_of_peri
,$dist_ly) = @_;
my $del_rad = $del_deg*$pi/180.0;
my $ra_rad = $ra_deg*$pi/180.0  $pi;
my $eps = $pi/180.0*23.4392911;
my $ii = $pi/180.0*(90.0  $i);
my $om = $pi/180.0*($PA_of_Node  270.0);
my $alpha = atan(cos($ii)*cos($pi/180.0*($PA_of_Node))/(sin($ii)*cos($del_rad) 
cos($ii)*sin($del_rad)*sin($pi/180.0*($PA_of_Node)))) + $ra_rad;
if( sin($ii)*cos($del_rad)cos($ii)*sin($del_rad)*sin($pi/180.0*$PA_of_Node) < 0 ) { $alpha = $alpha + $pi };
my $delta=asin(cos($ii)*cos($del_rad)*sin($pi/180.0*$PA_of_Node)+sin($ii)*sin(
$del_rad));
my $lambda=atan((sin($alpha)*cos($eps)+tan($delta)*sin($eps))/cos($alpha));
if( cos($alpha) < 0 ) { $lambda = $lambda + $pi };
my $beta = asin(sin($delta)*cos($eps)  cos($delta)*sin($eps)*sin($alpha));
my $alphaOm = atan(cos($om)/(sin($del_rad))/sin($om)) + $ra_rad;
if( sin($del_rad)*sin($om) < 0 ) { $alphaOm = $alphaOm + $pi };
my $deltaOm = asin(cos($del_rad)*sin($om));
my $lambdaOm = atan((sin($alphaOm)*cos($eps) +
tan($deltaOm)*sin($eps))/cos($alphaOm));
if( cos($alphaOm) < 0 ) { $lambdaOm = $lambdaOm + $pi };
my $betaOm = asin(sin($deltaOm)*cos($eps) 
cos($deltaOm)*sin($eps)*sin($alphaOm));
my $sign = $betaOm > 0? 1.0:1.0;
my $dd = acos(cos($betaOm)*cos($lambdaOm  $lambda  $pi/2.0))*$sign;
$Period = $P;
$SemiMajorAxis = $dist_ly*63239.7*tan($pi/180.0*$a_arcsec/3600.0);
$Eccentricity = $e;
$Inclination = 90  $beta/$pi*180;
$AscendingNode = $lambda/$pi*180 + 90  floor(($lambda/$pi*180+90)/360.0)*360;
$ArgOfPeri = $Arg_of_peri + $dd/$pi*180  floor(($Arg_of_peri + $dd/$pi*180)/360.0)*360;
$MeanAnomaly = 360*((2000.0  $Epoch_of_peri)/$P  floor((2000.0  $Epoch_of_peri)/$P));
}
Since we are now talking about lots of math and since LaTeX still doesn't work with the new server, I will continue with a well commented Maple worksheet. Here it is
Note, the only orbital output parameters (in the Celestia ecliptical frame) that are affected by
???+180°, ???+180° or equivalently i > i are only the following three
$Inclination
$AscendingNode
$ArgOfPeri
This I have also checked numerically, of course. There are now various possible interpretations about using i > i. Before getting to that, I let you first digest this result, perhaps...
Fridger
Last edited by t00fri on 09.07.2010, 09:50, edited 4 times in total.
Re: Binary orbits incompatible with radial velocities
The preservation of the skyplane orbits can also be seen from the form of the ThieleInnes constants, which only contain terms in cos(i), which is unchanged under i?i.
For the radial velocity equation you need to know that the factor K which represents the semiamplitude contains sin(i), which picks up a factor of 1 under i?i. (This sin(i) term leads to the wellknown massinclination degeneracy for the majority of the exoplanets catalogue).
For the radial velocity equation you need to know that the factor K which represents the semiamplitude contains sin(i), which picks up a factor of 1 under i?i. (This sin(i) term leads to the wellknown massinclination degeneracy for the majority of the exoplanets catalogue).
Who is online
Users browsing this forum: 2 guests