I am unable to get this calculation to work. Either i am misunderstanding something, or there are inaccuracies i am unaware of... Please comment:
(I have simplified the numbers):
- Planet RotationPeriod is 18 hours
- Satellite Period is 0.75 days, with no RotationPeriod (tidally locked)
- Satellite Obliquity of 45 degrees
... To make the satellite stand still (not change orientation relative to the planet), as i understand it, the Precessionrate should be:
360 divided by 0.75 = 480.
... This works short term. But in a thousand years, there is a considerable drift.
What am i doing wrong?
- rthorvald
Precessionrate calculations
The problem with PrecessionRate is we can't change its axis. I asked several times to have the ability to change the PrecesionRate axis with an SSC command like "PrecessionAxis [x x x]". I don't know why Chris is hesitant to add this.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"
Cham wrote:I don't know. Your number should be ok, if the values are exact. If you rounded some numbers, then it may explain the drift.
I have simplified the numbers to get the concept right, since the real values gave me too many decimals for my calculator to handle... And i thought the problem was that the result was not accurate enough. So, i re-stated the problem with simpler values to test it, but it comes out wrong still.
- rthorvald
The drift is most probably caused by your rounded values. Try some EXACT values (don't do approximations). Try some simple integers and select some so the division could give another integer.
EDIT : I've experienced similar problems before, and I had to fine-tune my precession rate value by trial and error, since the exact calculations wasn't giving the right value for a long period of time. I suspect the cause may be an approximation in Celestia's code. There is probably a Pi somewhere in the code, rounded to something like Pi = 3.1415927, or something like that, since a true rotation rate is given by
EDIT : I've experienced similar problems before, and I had to fine-tune my precession rate value by trial and error, since the exact calculations wasn't giving the right value for a long period of time. I suspect the cause may be an approximation in Celestia's code. There is probably a Pi somewhere in the code, rounded to something like Pi = 3.1415927, or something like that, since a true rotation rate is given by
Code: Select all
Omega = 2 Pi / Period
Last edited by Cham on 14.12.2006, 19:15, edited 1 time in total.
"Well! I've often seen a cat without a grin", thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!"
This is exactly what i have done.Cham wrote:The drift is most probably caused by your rounded values. Try some EXACT values (don't do approximations). Try some simple integers and select some so the division could give another integer.
Cham wrote:EDIT : I've experienced similar problems before, and I had to fine-tunned my precession rate value by trial and error, since the exact calculations wasn't giving the right value for a long period of time.
Yes... I am playing with it right now. I need the thing to stay in place for at least three thousand years, but after 7-800, it is noticeably off track.
- rthorvald