Binary orbits incompatible with radial velocities

[ajtribick]

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, vice-versa 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 z-axis of the coordinate system to be pointing in the wrong direction.

(Exoplanetary orbits on the other hand appear to be fine)

[t00fri]

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 orbit-images 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 coordinate-related 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]

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

Fridger

[Hungry4info]

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.

[ajtribick]

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 z-coordinates 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 z-axis needs to be flipped, from the Thiele-Innes constants it is clear that the transformation to make to the orbital elements (before converting to the ecliptic frame) is ???+180°, ???+180°.

[t00fri]

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 z-coordinates 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 +z-axis disagrees with the +z-conventions in Celestia or not? I suppose there is consistency. You then seem to suggest that --due to a differing z-axis 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 z-axis needs to be flipped, from the Thiele-Innes 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 orbit-checks.

Meanwhile, I found two examples of my test-images 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 mixed-up +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 multi-parameter 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?

[ajtribick]

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 sky-plane 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 left-handed 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 right-handed, 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 sky-plane 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 sky-plane orbits I am not sure it is particularly worthwhile for visual binaries...

[ajtribick]

Quick summary of the mathematical details I am using:

The Thiele-Innes 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 Thiele-Innes constants are unchanged, resulting in the exact same sky-plane 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 semi-amplitude. 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 Z-axis by ?, then about the X-axis by i, then about the Z-axis 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.

[t00fri]

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.

It means that my results for Celestia do NOT generate any observable discrepancy, except if radial velocity measurements are considered in addition. OK.

I really should see what calculations you actually did.
Ah! Cross-posting...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 ...

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 sky-plane plot, including orbital direction.

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.

Indeed as far as I can make out, Pourbaix et al. (2000) are using a left-handed 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 right-handed,

While it's >5 years ago that I explicitly checked, I seem to remember definitely that Celestia's original system was left-handed! 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?

Fridger

PS: too bad, LaTeX is also not yet activated on the new server....

[t00fri]

...
Radial velocity on the other hand is given by

dZ/dt = K(cos (? + ?) + e cos ?)

Where ? is the true anomaly and K is the semi-amplitude. 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 Z-axis by ?, then about the X-axis by i, then about the Z-axis 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

[ajtribick]

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.

[t00fri]

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?

Indeed as far as I can make out, Pourbaix et al. (2000) are using a left-handed 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.

From where exactly did you infer this??

Fridger

[ajtribick]

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?

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.

Indeed as far as I can make out, Pourbaix et al. (2000) are using a left-handed 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.

From where exactly did you infer this??

This seems to be the coordinate system you need to use to simultaneously match the sky-plane 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 right-handed coordinate system.

(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]

Andrew,

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

[chris]

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 coordinate-related 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 well-established. 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 x-axis pointing           
 *  from the body center through the intersection of the prime meridian         
 *  and the equator, and the z-axis aligned with the north pole. The           
 *  y-axis 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

While it's >5 years ago that I explicitly checked, I seem to remember definitely that Celestia's original system was left-handed! 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 left-handed 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]

Chris,

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 coordinate-related 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 frames-related 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 frame-definition, I made a respective remark above (merely as a note of caution, while time was lacking for going through the post-2005-code most carefully).

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

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

Fridger

[ajtribick]

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 astronomy-related discipline to use abominations like left-handed 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.

[chris]

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.

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.

--Chris

[t00fri]

As Andrew showed, flipping the z-axis 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 cross-check 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 z-axis. Flipping the z-axix (in the skyplane frame) from positive to negative, amounts to the transformation i -> -i
+++++++++++++++++++++++++++++++++

For completeness, let me now consider my Perl routine RotOrbits line-by-line 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

[ajtribick]

The preservation of the skyplane orbits can also be seen from the form of the Thiele-Innes 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 semi-amplitude contains sin(i), which picks up a factor of -1 under i?-i. (This sin(i) term leads to the well-known mass-inclination degeneracy for the majority of the exoplanets catalogue).