Star orbits proposal

General discussion about Celestia that doesn't fit into other forums.
Topic author
chris
Site Admin
Posts: 4211
Joined: 28.01.2002
With us: 23 years
Location: Seattle, Washington, USA

Star orbits proposal

Post #1by chris » 04.10.2004, 03:45

On the developers list there's been some discussion of how stars orbits should be specified in .stc files. Here is what has emerged so far and is implemented in the CVS top of tree.

First of all, there is no means to specify an orbit in the stars.dat file. You must use an .stc file. To compensate for this somewhat, it's now possible to override a star from stars.dat with a replacement in an .stc file. This happens automatically when you create a star in an .stc file that has the same catalog number as one from stars.dat.

Another feature that was introduced to make it easier to create orbiting stars is automatic catalog number generation. You can simply omit the catalog number from the star definition and Celestia will generate one for you. A star without a catalog number must have a name. (It's actually not that hard to allow completely anonymous stars too, if someone voices a good reason for it.)

Here's a very basic orbiting star definition for Sirius B:

Code: Select all

# For compatibility with older .stc files, the Star keyword is optional
Star "Sirius B"
 {
   RA 101.28855
   Dec -16.713142
   Distance 8.6012238
   SpectralType "DA2"
   AppMag 8.44

   EllipticalOrbit
   {
   Period            50.090
   SemiMajorAxis      19.8 # 19.8AU = 7.500 arcsec
   Eccentricity       0.592
   Inclination       97.51
   AscendingNode    161.33
   ArgOfPericenter  184.56
   MeanAnomaly       40.89
   }
}


This example uses an EllipticalOrbit (as I expect most stars will), but any other orbit type valid for planets will also work for stars. Of course, since Celestia has no custom orbits for stars, SampledOrbits are the only type that make sense. Just as for planet orbits, the units are years for period, AU for the semimajor axis. The center of the orbit is given by the star's RA, declination, and distance. For this example, I've used the coordinates of Sirius. This isn't correct. Sirius and Sirius B are of comparable mass, so they actually orbit around a barycenter about one third of the way from Sirius B to Sirius A. The way to correct the problem is to redefine Sirius A with a position and orbit identical to Sirius B except for the semimajor axis and argument of pericenter. The ratio of the semimajor axes should match the observed value (smaA / smaB = 0.466) and the arguments of pericenter should differ by exactly 180 degrees.

Systems with more than three stars often have a pair of stars A and B in a tight orbit, with much more distanct companion C orbiting the pair. It's not possible to describe such a system using a fixed barycenter like the one in the Sirius B example, thus Celestia supports a new barycenter object in .stc files. A barycenter behaves just like an invisible star and may even have planets. Here's a sample trinary system featuring a barycenter:

Code: Select all

Barycenter "Trinary AB"
{
   RA 81.2886
   Dec 16.7
   Distance 1200

   EllipticalOrbit
   {
   Period             10.0
   SemiMajorAxis       0.3
   Eccentricity        0.02
   Inclination        30.0
   AscendingNode       0.0
   LongOfPericenter  120.0
   }
}


Star "Trinary A"
{
   RA 81.2886
   Dec 16.7
   Distance 1200
   SpectralType "K7V"
   AbsMag 6.5

   EllipticalOrbit
   {
   Period              0.01
   SemiMajorAxis       0.03
   Eccentricity        0.12
   Inclination        30.0
   AscendingNode      45.0
   LongOfPericenter    0.0
   }

   Barycenter "Trinary AB"
}

Star "Trinary B"
{
   RA 81.2886
   Dec 16.7
   Distance 1200
   SpectralType "K5V"
   AbsMag 6.0

   EllipticalOrbit
   {
   Period              0.01
   SemiMajorAxis       0.03
   Eccentricity        0.12
   Inclination        30.0
   AscendingNode      45.0
   LongOfPericenter  180.0
   }

   Barycenter "Trinary AB"
}

Star "Trinary C"
{
   RA 81.2886
   Dec 16.7
   Distance 1200
   SpectralType "M8V"
   AbsMag 10.5

   EllipticalOrbit
   {
   Period             10.0
   SemiMajorAxis       5
   Eccentricity        0.02
   Inclination        30.0
   AscendingNode       0.0
   LongOfPericenter  300.0
   }
}


In this system C is a red dwarf orbiting two close K stars. A and B orbit the barycenter AB, which in turn orbits the barycenter ABC. Since ABC is fixed, however, we didn't have to define a separate barycenter object for it. More complex systems such as the Castor sextuple can be created by adding additional stars and barycenters. It's also possible to create systems where close planets orbit an individual star in a pair, but very distant planets orbit the barycenter of the pair: just give the barycenter as the parent of the distant planets and a star as the parent of the close ones.

The reference plane for star orbits is the ecliptic. Grant has mentioned that it would be convienent to also allow orbits to be specified with respect to the sky plane, since this is how star orbits are given in catalogs.

I welcome feedback on this implementation of star orbits. Nothing should be considered final; there's plenty of opportunity to change things before the next Celestia release.

--Chris
Last edited by chris on 04.10.2004, 05:09, edited 1 time in total.

Evil Dr Ganymede
Posts: 1386
Joined: 06.06.2003
With us: 21 years 8 months

Post #2by Evil Dr Ganymede » 04.10.2004, 04:02

I like the look of it so far... but I have a couple of requests though:

1) Can you pleasepleaseplease introduce a "Mass" parameter for primaries in order to calculate orbital distance or periods? I'm thinking that if you explicitly define the orbital distance AND period, then the Mass parameter can be ignored and the semimajor axis and period are used as they are. But if EITHER the semimajor axis OR the period are defined, then the mass can be used to calculate the missing parameter (it's not like the equations are particularly difficult or complex).

Right now designing STCs is a bit of a pain in the arse because one has to calculate the orbital period separately for every orbiting body and write that into the STC - the aim of my proposal would make it a lot easier to make STCs since you'd just be able to type in the distance and Celestia could figure out the period on the fly from that data. (or you could type in the period and Celestia will calculate the semimajor axis using the primary's mass and use that to draw the orbit).


2) When you put planets around the Star objects, can their periods be defined in years and the distance defined in AU too? That's how planetary orbits are usually defined, after all.

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

Post #3by Guckytos » 04.10.2004, 10:49

Chris,

your proposal sounds very good so far.
I like especially the possiblity to just define a barycenter with some planets, this will make runaway planets or interstellar Stations possible.
Will the new STC files then work with absolute Magnitude for the stars or/and with the apparent mag as up to now?

But where in your second example is the barycenter "Trinary ABC" defined?
The necessity to put the RA, Dec and Distance into every star of the multiple systems show in your example is annoying me a bit.
Isn't there a chance to make it in a way, that you only have to give that once? Okay, it's only copy'n'paste anyway, but if it was possible it would be nice.
Seems like i will have to rewrite my guide, once that is all sorted out, but who cares.
Those changes are really worth a bit work from my lazy self *g*

Hmmm i think Evil Dr Ganymede has a point there, with his mass parameter idea. If you don't know beans about anything you could still create binary, trinary stars and they would look okay. And if you are a pro, you can tweak the systems by giving both parameters and thus deactivating the checking mechanism.

Regards,

Guckytos

Medusa

Post #4by Medusa » 04.10.2004, 13:00

A really good implimentation, Chris, that's how Mom Nature does the orbit of stars. I guess *any* kind of multiple systems could be built by using the new star and barycenter definitions recursively.

I don't know if Dr.Ganymede's please for a mass parameter really is a good idea. To my personal taste, as many parameters as possible should kept "free" - even if it means some copied and pasted lines in parameter files. One day there COULD be the need for some tricky new objects which only work without proper mass definitions - imagine something comparable to the "Emissive true" trick used to get some pseudo-stars in orbit now. It would not have worked if there would have been a definition about luminescence (planets never shine). Fortunately Chris didn't it this way. So I would feel more comfortable with less parameters than more. Hope you get my point.

~Medusa.

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

Post #5by chris » 04.10.2004, 15:59

Evil Dr Ganymede wrote:I like the look of it so far... but I have a couple of requests though:

1) Can you pleasepleaseplease introduce a "Mass" parameter for primaries in order to calculate orbital distance or periods? I'm thinking that if you explicitly define the orbital distance AND period, then the Mass parameter can be ignored and the semimajor axis and period are used as they are. But if EITHER the semimajor axis OR the period are defined, then the mass can be used to calculate the missing parameter (it's not like the equations are particularly difficult or complex).

I probably won't do this. For stars, it's a big headache to implement, requiring a lot of extra bookkeeping to make it work generally. It seems to me that generating sensible periods and semimajor axes is the domain of a separate world building tool, not the Celestia data file parser. Such a tool could do other useful things like fill in approximate star masses based on spectral type and warn if you try to place a satellite outside a planet's Hill radius.

Right now designing STCs is a bit of a pain in the arse because one has to calculate the orbital period separately for every orbiting body and write that into the STC - the aim of my proposal would make it a lot easier to make STCs since you'd just be able to type in the distance and Celestia could figure out the period on the fly from that data. (or you could type in the period and Celestia will calculate the semimajor axis using the primary's mass and use that to draw the orbit).
I know it's a pain. I just don't think that the Celestia parser is the right place to address the problem.

2) When you put planets around the Star objects, can their periods be defined in years and the distance defined in AU too? That's how planetary orbits are usually defined, after all.


Those are the units used for both planet and star orbits, though there was a typo in my original post that may have made that unclear.

--Chris

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

Post #6by chris » 04.10.2004, 16:13

Medusa wrote:A really good implimentation, Chris, that's how Mom Nature does the orbit of stars. I guess *any* kind of multiple systems could be built by using the new star and barycenter definitions recursively.
I think so . . . A similar system seems to work quite well for solar system objects. In fact, I'm considering adding a Barycenter object type to the .ssc parser. Right now, you have define an object with the class set to invisible. A Barycenter definition would have the same result internally, but it's much more sensible for the .ssc author.

I don't know if Dr.Ganymede's please for a mass parameter really is a good idea. To my personal taste, as many parameters as possible should kept "free" - even if it means some copied and pasted lines in parameter files. One day there COULD be the need for some tricky new objects which only work without proper mass definitions - imagine something comparable to the "Emissive true" trick used to get some pseudo-stars in orbit now. It would not have worked if there would have been a definition about luminescence (planets never shine). Fortunately Chris didn't it this way. So I would feel more comfortable with less parameters than more. Hope you get my point.

I think that his proposal allows the semimajor axis and period to be free. The idea is for Celestia to derive plausible values automatically if one of the parameters is missing. If you provide both the semimajor axis and period, Celestia will use the values you specified rather than calculating them from the mass. But, there are other reasons not to implement the proposal, most of them involving code complexity and keeping the .stc and .ssc formats 'clean'.

--Chris

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

Re: Star orbits proposal

Post #7by granthutchison » 04.10.2004, 19:04

chris wrote:Grant has mentioned that it would be convienent to also allow orbits to be specified with respect to the sky plane, since this is how star orbits are given in catalogs.
This also seems to be the format for extrasolar planets. Unfortunately, it's nonsensical for objects within the solar system, so it can't be the Celestia standard. However, if plane-of-sky coordinates are implemented for star orbits, it would be very useful to have the same option for planets.

Here's a concrete example, using Alpha Centauri, of how Chris's current formulation can be used to substitute for the original stars.dat.

Code: Select all

71683 # ALF Cen A
{
   RA 219.916998      # point between two stars
   Dec -60.83748372   # in mass ratio 1.09:0.92
   Distance 4.3950709
   SpectralType "G2V"
   AppMag 0.01

   EllipticalOrbit {
      Period          79.914
      SemiMajorAxis   10.8928 # 23.68 divided in mass ratio 1.09:0.92
      Eccentricity    0.5179
      Inclination   82.98
      AscendingNode   67.71
      ArgOfPericenter 3.77    # Original pericentre - 180
      MeanAnomaly     200.12
   }
}

71681 # ALF cen B
{
   RA 219.916998      # point between two stars
   Dec -60.83748372   # in mass ratio 1.09:0.92
   Distance 4.3950709
   SpectralType "K0V"
   AppMag 1.34

   EllipticalOrbit {
      Period          79.914
      SemiMajorAxis   12.7872 # 23.68 divided in mass ratio 1.09:0.92
      Eccentricity    0.5179
      Inclination   82.98
      AscendingNode   67.71
      ArgOfPericenter 183.77
      MeanAnomaly     200.12
   }
}

1) The Hipparcos catalogue number suffices. Star names aren't specified, unless you want to add some new designation to Celestia's current list. (Specifying a previously existing name just causes a duplication in the displayed list.)
2) I had to work out a barycentre location for the two stars, using their mass ratio. This is because they're fairly widely separated ih the sky, and most often you won't need to do that.
3) The elliptical orbital elements at present need to be transformed from plane-of-sky (6th Catalog of Orbital Elements of Visual Binaries) to ecliptic. Bit of a pain to do, although you'll find my spreadsheet to do the maths on Selden's website. This is why I think it would be nice to be able to enter plane-of-sky elements directly.
4) The 6th Catalog supplies only angular separations, so you need to do a bit of maths to work out the true SemiMajorAxis (23.68) at ALF Cen's distance, before splitting it between the components according to the mass ratio of the stars.

Now a sample planet around ALF Cen A, which some people might recognize:

Code: Select all

"Wunderland" "ALF Cen A"
{
   Texture "earth.*"
   Radius  4890

   EllipticalOrbit {   
      Period            1.45
      SemiMajorAxis     1.32
      Inclination      82.98 # to match orientation of star system
      AscendingNode    67.71 # to match orientation of star system
   }

   RotationPeriod   26.7

   Obliquity            82.98 # to match orientation of orbit
   EquatorAscendingNode 67.71 # to match orientation of orbit
}

1) Period and SemiMajorAxis are defined in the usual planetary terms, so no worries for the Evil Doctor.
2) To align the planet with the plane of the stellar system, I need to give its orbit the same Inclination and AscendingNode as used in the stc, and need to set Obliquity and EquatorAscendingNode equal to the Inclination and AscendingNode. (In practice, you'd be using values somewhat different from this, to recreate the usual orbital and axial tilts.)

My point is that if we can define star orbits by plane-of-sky, but not planet orbits, it will create a headache for planet-builders who want to have control of the orientation of their planet within such systems.

Grant

Evil Dr Ganymede
Posts: 1386
Joined: 06.06.2003
With us: 21 years 8 months

Post #8by Evil Dr Ganymede » 04.10.2004, 22:08

I think that his proposal allows the semimajor axis and period to be free. The idea is for Celestia to derive plausible values automatically if one of the parameters is missing. If you provide both the semimajor axis and period, Celestia will use the values you specified rather than calculating them from the mass. But, there are other reasons not to implement the proposal, most of them involving code complexity and keeping the .stc and .ssc formats 'clean'.


I'm not sure I follow how it makes things THAT much more complex. It's just a straight IF block isn't it? Kinda like this pseudocode:

Code: Select all

IF both semimajor axis and period are specified THEN use them as is and ignore mass.

IF mass is specified THEN
           IF only semimajor axis is specified THEN use mass to figure out orbital period using:
           SQRT(((semimajor axis in metres^3)*(4*(PI()^2)))/(0.00000000006672559*primary mass))

           IF only period is specified THEN use mass to figure out semimajor axis using:
           ((0.00000000006672559*primary mass in kg*(orbital period in seconds^2))/(4*(PI()^2)))^(1/3)
ENDIF

IF mass is not specified THEN do whatever Celestia does normally.


Other than that, do you need to do anything else to make this work?

Medusa

Post #9by Medusa » 06.10.2004, 11:22

If it's really that simple, why don't you do it in your .ssc files? Kepler' Law should not be too hard to type into a desktop calculator....

~Medusa

Evil Dr Ganymede
Posts: 1386
Joined: 06.06.2003
With us: 21 years 8 months

Post #10by Evil Dr Ganymede » 06.10.2004, 16:29

Medusa wrote:If it's really that simple, why don't you do it in your .ssc files? Kepler' Law should not be too hard to type into a desktop calculator....

~Medusa


Because AFAIK you can't use ssc files to run and because there's this whole massive 3D solar system/star renderer package that could potentially do it for me with no effort whatsoever :D.

I mean, if you were making a system with 3 stars, 18 planets, and 30 moons it could get incredibly tedious to manually figure out all their orbital periods or distances. Calculating those in Celestia could save a hell of a lot of time.

HankR

Alternate approach for star orbits

Post #11by HankR » 11.10.2004, 06:03

Just for discussion I thought I'd outline a possible alternate approach for handling multiple star system orbits. I probably haven't thought about this carefully enough, so there may be significant problems that I've overlooked, but I thought I'd bring it up just in case it might be useful.

The main purpose here is to simplify the required orbit specification. The basic idea is that for a companion star, you would just specify the name of its primary, the astrocentric orbit of the companion relative to its primary, and the mass of the companion relative to the mass of its primary. This data would allow the barycentric positions of the two stars to be derived internally by Celestia.

Internally, Celestia would first calculate the companion's position in astrocentric coordinates, then calculate the barycenter from the companion position and mass ratio, and then apply the corresponding translation to transform the two star positions into global coordinates (with the barycenter of the system assumed to be fixed in global coordinates).

For systems with more than two components the interpretation of the orbit specifications would be slightly modified for convenience. In the case of an additional (distant) companion, that companion's orbit would be specified relative to the barycenter of the close pair, rather than relative to the primary. If the distant companion itself has a close companion, the orbit specified for the distant companion would be interpreted as the orbit of the barycenter of the second close pair relative to the barycenter of the first close pair. The orbit for the distant companion's close companion would be specified as an astrocentric orbit relative to its primary (the distant companion). The positions of the various components would be translated internally into global coordinates based on the position of the barycenter of the system, as in the binary case.

This approach is less flexible, as it does not allow the stars to have their barycentric orbits specified independently. But of course, the barycentric orbits aren't actually independent, and I don't think the simplified approach would exclude many physically reasonable systems. In compensation for this loss of flexibility, this approach eliminates the redundancies of explicitly specified barycentric orbits, and also reduces the number of orbit calculations required.

I didn't indicate how the global coordinates of the system barycenter would be determined. If the epoch of the RA, Dec and Distance specifying the position of the primary is known (or assumed), a one-time calculation could be done to determine the barycenter based on that position and the orbital positions of the companions at that epoch.

Does this make any sense?

- Hank

HankR

Example

Post #12by HankR » 11.10.2004, 06:37

Here's how (I think) a triple star system might look with the approach I've outlined:

Code: Select all

Star "Trinary A"
 {
    RA 81.2886
    Dec 16.7
    Distance 1200
    SpectralType "K7V"
    AbsMag 6.5
 }
 
 Star "Trinary B"
 {
    RA 81.2886
    Dec 16.7
    Distance 1200
    SpectralType "K5V"
    AbsMag 6.0

    Primary "Trinary A"
    MassRatio 1.0
    EllipticalOrbit
    {
    Period              0.01
    SemiMajorAxis       0.06
    Eccentricity        0.12
    Inclination        30.0
    AscendingNode      45.0
    LongOfPericenter  180.0
    }
 
 }
 
 Star "Trinary C"
 {
    RA 81.2886
    Dec 16.7
    Distance 1200
    SpectralType "M8V"
    AbsMag 10.5

    Primary "Trinary A"
    MassRatio .012
    EllipticalOrbit
    {
    Period             10.0
    SemiMajorAxis       5.3
    Eccentricity        0.02
    Inclination        30.0
    AscendingNode       0.0
    LongOfPericenter  300.0
    }
 }


Incidentally, now that Celestia will be supporting relative stellar motions in multiple star systems, would this be a good time to consider also supporting (3D) proper motion?

- Hank


Return to “Celestia Users”