Why have RotationOffsets changed in 1.5.0pre3

[Chuft-Captain]

I have found that rotational positions have advanced by approx 30 seconds between 1.5.0pre1 and 1.5.0pre3.

For example in these pictures of Space Station V (the first from PRE1 and the second from PRE3) taken at exactly the same time, the anti-clockwise rotation is approx 140degrees advanced in the second pic (PRE3).

Does anyone know if this is a bug or a deliberate change?

This is not a big deal for a single object such as Space Station V, but is a serious issue for situations involving multiple objects whose rotational positions are synchronised with objects in XYZ's (eg. planetary landers).

For example, a 30 second discrepancy could cause a craft in an XYZ trajectory landing on Earth, to miss it's target by approx 15km's. (assuming that planetary rotations are also affected by this discrepancy)
For objects with smaller periods (such as O'Neill cylinders ) this is a far more serious problem.

PRE1:


PRE3:

[selden]

CC,

The time displayed on the screen is UTC.

Unlike previous versions of Celestia, the time used internally by Celestia v1.5 for all of its scripts and catalogs is TDB, not UTC. Currently the difference between them is about 1 minute of time.

I thought Chris made a posting to the Forum about this, but the different time scales are described in the Celestia WikiBook at http://en.wikibooks.org/wiki/Celestia/Time_Scales

This change was required in order to make Spice kernels work. I thought it had happened before pre1, but apparently not all of it.

However, this should not affect the synchronization between SSC catalogs and XYZ trajectories. They both should be using TDB. If not, there's a bug in Celestia.

[Chuft-Captain]

However, this should not affect the synchronization between SSC catalogs and XYZ trajectories. They both should be using TDB. If not, there's a bug in Celestia.

Thanks for the explanation Selden. I didn't know about this change, but suspected something like this.
The fact that my XYZ's are now about 32 seconds behind the rotating elements suggests that this change to TDB has not been applied to XYZ times in the same way as to rotations. This does look like a bug then.

[selden]

CC,

Unfortunately, you'll have to provide a simple example with an XYZ file and a Rotation which demonstrates the problem, along with a description of what should happen and what actually happens.

[hank]

However, this should not affect the synchronization between SSC catalogs and XYZ trajectories. They both should be using TDB. If not, there's a bug in Celestia.

Thanks for the explanation Selden. I didn't know about this change, but suspected something like this.
The fact that my XYZ's are now about 32 seconds behind the rotating elements suggests that this change to TDB has not been applied to XYZ times in the same way as to rotations. This does look like a bug then.

I haven't looked at the code, so I'm just guessing about this, but I wonder if the problem might be with the epoch of the rotation elements? I believe that previously you couldn't specify one, but now you can. If you haven't specified one, it may be that the default value (0?) is not adjusted for the time base change.

- Hank

[Chuft-Captain]

However, this should not affect the synchronization between SSC catalogs and XYZ trajectories. They both should be using TDB. If not, there's a bug in Celestia.

Thanks for the explanation Selden. I didn't know about this change, but suspected something like this.
The fact that my XYZ's are now about 32 seconds behind the rotating elements suggests that this change to TDB has not been applied to XYZ times in the same way as to rotations. This does look like a bug then.

I haven't looked at the code, so I'm just guessing about this, but I wonder if the problem might be with the epoch of the rotation elements? I believe that previously you couldn't specify one, but now you can. If you haven't specified one, it may be that the default value (0?) is not adjusted for the time base change.

- Hank

I think you may very well be onto something here Hank!
The XYZ journeys are still starting and ending at exactly the same position, however rotations are out by approx the amount of the timebase change. (rotational positions are occuring ~ 32 seconds earlier in PRE3)
I'll do some experimenting by adding an Epoch adjustment (just the usual Epoch statement I assume?), however I think this correction should be made once in code rather than having to adjust the Epoch of every rotating element of every addon by 32.184 seconds.

Thanks both of you for the info. I wasn't aware of these changes as I don't do anything involving Spice Kernels. I think we may be getting to the bottom of it.

[Chuft-Captain]

FYI:
Added the statement:

Code: Select all

Epoch   0.0003725   # = 32.184 / 60 /60 / 24

to one of my Habitat definitions, and this had no affect on the rotation offset. I suspect maybe Epoch only affects orbits, not rotations???

[selden]

CC,

You've left out some critical information: which Rotation construct are you using?
[edit] the use of Epoch requires one of the new Rotation constructs. It can't be put inline with the old rotational elements.[/edit]

You might want to consider using

Code: Select all

PrecessingRotation
{
   Period <hours>
   PrecessionPeriod <years>
   Inclination <degrees>
   AscendingNode <degrees>
   MeridianAngle <degrees>
   Epoch <date>
}


[edit]
Note that Period is the object's Siderial Period. e.g. if applied to the Earth, it would be 23.93 rather than 24 hours.[/edit]

[Chuft-Captain]

Correction, I realized it's RotationEpoch statement (NOT Epoch), which should be used.

A bit of trial and error with the RotationEpoch statement gives me a value of 0.000364 (31.4496 seconds) difference between the PRE1 and PRE3 rotations. (Strangely, this is not quite equal to the expected 32.184 value).

eg. Rotate the habitat backwards...

Code: Select all

"Malta (4)B" "Sol/LC/L5/Malta (4)"
{     
Class        "Spacecraft"
RotationEpoch   0.000364
Beginning    "2009 04 03 04:42:51"
#Mesh       "_20km.3ds"
#Radius       17.55
Mesh       "_cylinderonly.3ds"
Radius       13.6
EllipticalOrbit
   {
   Period       1e12
   SemiMajorAxis    22.32862
   MeanLongitude    270
   }
Obliquity       0.0
EquatorAscendingNode    0
RotationPeriod       -0.0333333333333333
RotationOffset       364 #296
Albedo          0.1
}    

Unfortunately that's just one object, and this correction (and corresponding RotationOffset corrections) would have to be applied to every single rotating element, so I still think the reason for this difference should be investigated and corrected in code to maintain backwards compatibility with 1.4.1 and 1.5.0pre1 addons.