ScriptedOrbit units convention

[ajtribick]

I'm not sure if this is a bug or an intentional feature, but ScriptedOrbits do not follow Celestia's usual units conventions where objects orbiting stars or barycentres use AU as orbit units and everything else uses km. In the ScriptedOrbit, the position is always specified in km. This means that any scaling parameters passed to the script do not obey the usual rules, which I find quite odd.

[chris]

This is intentional, because there's no mechanism for specifying which ScriptedOrbit numeric parameters are distances and need to be scaled. In the example on the in the WikiBook ( http://en.wikibooks.org/wiki/Celestia/Trajectories ), some of the numeric parameters are times, some are angles, and some are distances.

--Chris

[ajtribick]

Surely the scaling should be applied to the output of the function (which is definitely a position), not to the inputs.

[chris]

Surely the scaling should be applied to the output of the function (which is definitely a position), not to the inputs.

I didn't realize you meant the outputs. The use of kilometers for the outputs of all ScriptedOrbits is also intentional. Otherwise, it might be necessary to have two different versions of a scripted orbit function: one that uses AU, and another than uses kilometers. An actual example is a ScriptedOrbit that receives packets from a simulator running in a separate process. If positions were scaled, a separate ScriptedOrbit function (or an extra parameter) would be required for heliocentric and geocentric orbits.

--Chris

[t00fri]

This is intentional, because there's no mechanism for specifying which ScriptedOrbit numeric parameters are distances and need to be scaled. In the example on the in the WikiBook ( http://en.wikibooks.org/wiki/Celestia/Trajectories ), some of the numeric parameters are times, some are angles, and some are distances.

--Chris

Chris,

sorry, this explanation of yours I don't understand. I find it not at all transparent physicswise...

Fridger

[ajtribick]

The need for extra functions to handle different units exists either way. With the current situation, separate functions are needed for heliocentric orbits if the distances are to be interpreted consistently with their use everywhere else in .ssc files.

For example, if I make a Lissajous orbit function, this is a generic orbit which could be applied to a wide variety of situations. I would think anyone else who decides to use this function would expect the input parameters to work according to .ssc conventions. Your example of a simulation on the other hand is a special case which is going to be tailored to a single system.

[chris]

The need for extra functions to handle different units exists either way. With the current situation, separate functions are needed for heliocentric orbits if the distances are to be interpreted consistently with their use everywhere else in .ssc files.

Extra functions are only needed if we assume that ScriptedOrbits need to be absolutely consistent with how other orbits work. While I agree that this would be desirable, there are other considerations that I believe make this the wrong choice, for example:

For example, if I make a Lissajous orbit function, this is a generic orbit which could be applied to a wide variety of situations. I would think anyone else who decides to use this function would expect the input parameters to work according to .ssc conventions. Your example of a simulation on the other hand is a special case which is going to be tailored to a single system.

Yes this is an isolated system that could be configured with two different ScriptedOrbit types. But, it's not desirable to force the implementers of such systems to have to deal with two different units. Another example which might convince you is a ScriptedOrbit that loads a standard ephemeris file format (say .nio). These files use the same units for storing position vectors of planets and satellites. Two versions of this ScriptedOrbit are required if we do automatic conversion of distances.

Another point: with standard orbit types, time units are also different for planetocentric and heliocentric orbits. An EllipticalOrbit's period is specified in years for a star orbiting objects and in days for everything else. There's no way we can do a similar conversion for time fields of ScriptedOrbits--they're not going to behave exactly like the standard orbits even with conversion of distances. So while I agree the Lissajous example would benefit from unit conversion, it's a problem in other cases.

Finally, there's the issue of compatibility. There are existing add-ons that rely on the current behavior of ScriptedOrbit. I'd rather not break them by changing how ScriptedOrbit works. I'd be willing to sacrifice compatibility if there was an outright bug in ScriptedOrbit, but hopefully my examples have at least convinced you that there's enough merit to the current 'kilometers only' behavior.

(If I could rewrite the ssc format, I'd get rid of the implicit unit differences and instead use a syntax that let ssc creators specify units explicitly, e.g. "100*km", "2.1*au", etc.)

--Chris

[chris]

This is intentional, because there's no mechanism for specifying which ScriptedOrbit numeric parameters are distances and need to be scaled. In the example on the in the WikiBook ( http://en.wikibooks.org/wiki/Celestia/Trajectories ), some of the numeric parameters are times, some are angles, and some are distances.

--Chris

Chris,

sorry, this explanation of yours I don't understand. I find it not at all transparent physicswise...

Fridger

It's not relevant, because I misunderstood what Andrew was proposing. He is suggesting that for consistency with other orbit types, Celestia automatically convert the output of a ScriptedOrbit to AU when it is used for a heliocentric object. See the previous two posts in this thread for a further explanation.

--Chris

[t00fri]

(If I could rewrite the ssc format, I'd get rid of the implicit unit differences and instead use a syntax that let ssc creators specify units explicitly, e.g. "100*km", "2.1*au", etc.)

Yeah!!! That would be it....pleasing a physicist's heart What's hard about coding something like this, with the old behaviour being the default for compatibility?

Fridger

[chris]

(If I could rewrite the ssc format, I'd get rid of the implicit unit differences and instead use a syntax that let ssc creators specify units explicitly, e.g. "100*km", "2.1*au", etc.)

Yeah!!! That would be it....pleasing a physicist's heart What's hard about coding something like this, with the old behaviour being the default for compatibility?

It would require a lot of modifications to the ssc parser code, but nothing too hard. It's definitely too large a task for 1.6.0, but a possibility for the next version.

--Chris

[ajtribick]

That would definitely be a very useful feature - at present, trying to set up a solar system using Jacobi elements is horrendous.

E.g. the following configuration for HD 202206, using a configuration found using systemic (which uses the Jacobi setup, with each orbit being referred to the barycenter of the inner planets). In this setup, only HD 202206 b and the ab Barycenter use years and AU, the planet HD 202206 c is in days and km...

Code: Select all

Modify "b" "HD 202206"
{
   EllipticalOrbit {
      Epoch 2451402.8027
      Period 0.6995
      SemiMajorAxis 0.830
      Eccentricity 0.437
      ArgOfPericenter 205.4
      MeanAnomaly 352.8
   }
}

ReferencePoint "ab Barycenter" "HD 202206"
{
   EllipticalOrbit {
      Epoch 2451402.8027
      Period 0.6995
      SemiMajorAxis 0.0119
      Eccentricity 0.437
      ArgOfPericenter 205.4
      MeanAnomaly 352.8
   }
}

Modify "c" "HD 202206"
{
   OrbitFrame {
      EclipticJ2000 { Center "HD 202206/ab Barycenter" }
   }
   EllipticalOrbit {
      Epoch 2451402.8027
      Period 1376
      SemiMajorAxis 379700000
      Eccentricity 0.123
      ArgOfPericenter 153.9
      MeanAnomaly 51.601
   }
}

ReferencePoint "ab-c Barycenter" "HD 202206"
{
   OrbitFrame {
      EclipticJ2000 { Center "HD 202206/ab Barycenter" }
   }
   EllipticalOrbit {
      Epoch 2451402.8027
      Period 1376
      SemiMajorAxis 738700
      Eccentricity 0.123
      ArgOfPericenter 153.9
      MeanAnomaly 51.601
   }
}

(I guess an alternative would be to define several Barycenters in a .stc file but this is still not ideal... might be interesting to experiment with the Mass property in order to autogenerate these kind of configurations, but that will have to wait for post-1.6.0)