Some reference frames questions

[ajtribick]

First question: in the Celestia WikiBook, the way to implement a Laplace plane frame is described as follows:

This is the worst case. The Laplace plane for each satellite is defined by its polar right ascension and declination (in the EquatorJ2000 frame); this defines the local Laplace plane's ascending node longitude (90?° plus the pole's RA) and inclination (the co-declination, i.e. 90?° minus the dec).

Code: Select all

EllipticalOrbit {
    OrbitFrame { TwoVector {
        Center "object"
        Primary { Axis "x"
            ConstantVector { Vector [<Laplace plane ascending node>] Frame { EquatorJ2000 { Center "object" } } }
        }
        Secondary { Axis "z"
            ConstantVector { Vector [<Laplace plane pole>] Frame { EquatorJ2000 { Center "object" } } }
        }
    } }
...
}

This neglects how to get the Laplace plane ascending node and pole vectors from the RA, Dec and Tilt values supplied in the JPL Planetary Satellite Mean Orbital Parameters page.

Secondly, when specifying an OrbitFrame, why not have the Center parameter default to the parent body specified in the definition (or does it already?).

Thirdly, how would you define an OrbitFrame that would allow specification of binary star orbit parameters? (Yes, I know this can be done already using the spreadsheet for elements conversion, but that means it is not obvious what the original data used for the orbit was)

[chris]

First question: in the Celestia WikiBook, the way to implement a Laplace plane frame is described as follows:

This is the worst case. The Laplace plane for each satellite is defined by its polar right ascension and declination (in the EquatorJ2000 frame); this defines the local Laplace plane's ascending node longitude (90?° plus the pole's RA) and inclination (the co-declination, i.e. 90?° minus the dec).

Code: Select all

EllipticalOrbit {
    OrbitFrame { TwoVector {
        Center "object"
        Primary { Axis "x"
            ConstantVector { Vector [<Laplace plane ascending node>] Frame { EquatorJ2000 { Center "object" } } }
        }
        Secondary { Axis "z"
            ConstantVector { Vector [<Laplace plane pole>] Frame { EquatorJ2000 { Center "object" } } }
        }
    } }
...
}

This neglects how to get the Laplace plane ascending node and pole vectors from the RA, Dec and Tilt values supplied in the JPL Planetary Satellite Mean Orbital Parameters page.

Yes, this would be helpful. To get the pole vector, you just need to do a rectangular to spherical conversion. The z-axis points toward declination 90, the x-axis to declination 0/RA 0h, and the y-axis to declination 0/RA 6h. The ascending node is 90 degrees plus the RA, as stated on the WikiBook page.

Secondly, when specifying an OrbitFrame, why not have the Center parameter default to the parent body specified in the definition (or does it already?).

Not yet, but this is a very good idea (especially for ConstantVector frames, where the frame center doesn't matter.)

Thirdly, how would you define an OrbitFrame that would allow specification of binary star orbit parameters? (Yes, I know this can be done already using the spreadsheet for elements conversion, but that means it is not obvious what the original data used for the orbit was)

You can't define frames for stars yet. It's actually quite a bit of work to implement.

--Chris

[selden]

You can't define frames for stars yet. It's actually quite a bit of work to implement.

Might it be easier to implement Class "star" in SSC files?

Just wondering...

[ajtribick]

Thanks for your answers, that sorts most of the issues.

You can't define frames for stars yet. It's actually quite a bit of work to implement.

However, you CAN define frames for extrasolar planets, which have orbital elements given in the same type of reference frame as for binary stars orbits. So having the frame available would still be useful even if it can't be used for stars.

[ajtribick]

Further point: might it not be useful to allow specification of an axis by specifying RA and Dec rather than a 3-component vector?

[chris]

Further point: might it not be useful to allow specification of an axis by specifying RA and Dec rather than a 3-component vector?

Yes, it would. There are a couple places where it would be useful to use spherical coordinates instead of Cartesian coordinates. The constant vector for frames is one, the vector for FixedPosition is another (i.e. longitude/latitude/altitude instead of x/y/z.)

One approach would be to allow RADec [ ra dec ] instead of Vector [ x y z]. However, that might be confusing because it allows the user to provide coordinates that won't give the expected result unless the frame is set to EquatorJ2000. So another approach is to provide an alternative to ConstantVector that assumes EquatorJ2000:

Code: Select all

TwoVector {
    Center "object"
    Primary { Axis "x" RADec { <ra1> <dec1> } }
    Secondary { Axis "z" RADec { <ra1> <dec1> } }
}


The ease of use comes at the expense of some of the flexibility of the first approach.

--Chris

[ajtribick]

Ok, just to test I am doing something vaguely sensible here...

To use astrometric orbital elements (e.g. for exoplanets), the reference frame is

Code: Select all

OrbitFrame {
   TwoVector {
      Center "star"
      Primary {
         Axis "z"
         RelativePosition { Target "SSB" }
      }
      Secondary {
         Axis "x"
         ConstantVector { Vector [ 0 0 1 ] Frame { EquatorJ2000 { Center "star" } } }
      }
   }
}

...at least, it seemed to work when I tried it out on the astrometric elements of EPS Eri b.