Jupiter GRS & event comparison with CCD image

[Guest]

I think Grant's modification ( notably EquatorAscendingNode 337.77) of
the Jupiter orientation in his revised solarsys.ssc is quite a bit
worse than the original values.

I have done careful comparisons with precisely timed Jupi-events
from /real CCD images/ at Arkansas Sky Observatory
(http://www.arksky.org/). They specialize on planetary observations
and a wealth of precisely logged observational data may be found
there.

In the image below, you see comparisons of the observed Jupi event

Name: Date: JDate: Time (UT): Object: CM1 CM2 CM3
P. Clay
Sherrod 12152002 2452623.85972 08:38 Jupiter 57.2 81.9 250.5

with two corresponding Celestia simulations based on my new 2k Jupi
texture and light time delay of 38 min (Horizons). CM1..3 are the
measured longitudes of the Center Meridian in Systems I..III.


-------------------------------------------------------------------------
TOP (Grant's latest modifications):
----
RotationPeriod 9.924920 #revised value: System III - magnetic field
Obliquity 2.22 #revised value
EquatorAscendingNode 337.77 #revised value <=============

Middle:
--------
Real CCD, South is up. Shadows of Ganymede and Calisto as
well as the disk of Io appearing on the right edge of the planet.

BOTTOM (default, apart from a revision of RotationPeriod according to Horizon):
-------

RotationPeriod 9.9249125 # slightly revised according to Horizon's
Obliquity 1.82246
EquatorAscendingNode -1.87785 <=================
-------------------------------------------------------------------------

It is seen that the top image does not at all reproduce the event.
The bottom image -- just with RotationPeriod = 9.9249125 slightly
revised according to Horizons -- works almost perfectly for the shadow
of Ganymede, the lit position of Io at the planet's right edge and the
position of the GRS that was obtained from the original 2k texture by
a horizontal flip. Callisto's shadow is substantially off, also in
XEphem, btw;-). Both Celestia images have the light time delay of ~38 min
subtracted from the event time 8:38 UT on earth and are computed at
the location of the Observatory in Arkansas. There is still a slight
discrepancy since the shown events need Celestia UT 8:08 instead of 8:00.

It is well known that the time constancy of the GRS is best in System
II. I have actual measurements of the GRS position as function of time.

Bye Fridger

[t00fri]

Sorry, forgot to login. Above was me.

Bye Fridger

[granthutchison]

I think Grant's modification ( notably EquatorAscendingNode 337.77) of
the Jupiter orientation in his revised solarsys.ssc is quite a bit
worse than the original values.

I think there are several problems with what you've done, but none of them are to do with my solarsys.ssc modification!

1) The CustomOrbits for the Galileans are rotated by about 20 degrees in Celestia 1.2.5pre7 - Chris will fix this next time. By hauling the EquatorAscendingNode around by 20 degrees you've approximately fixed the Galileans' positions, at the expense of having Jupiter's pole and prime meridian (and the orbital plane of the Galileans) misaligned. Using my current Jupiter rotation parameters and a proper set of elliptical elements for date, I can in fact reproduce the satellite and shadow positions better than your "correction" does.

2) System III is inappropriate for the Great Red Spot, as you say, but that's what came with the original solarsys.ssc. I've just posted revisions specifically to correct GRS transit times, over on another thread:
http://www.shatters.net/forum/viewtopic.php?t=1497. (The RotationPeriod modification you've made is just a tiny adjustment to System III - most of the apparent effect you've gained derives from your yank on the EquatorAscendingNode. What you really need is the System II rotation period.)

3) Have you aligned your Jupiter texture to place the GRS in the correct longitude?
My GRS posting, above, corrected the orientation of the Jupiter texture that comes with Celestia, but a look at your 2k texture gives the following rotation definition for a System II, GRS-centred Jupiter:

Code: Select all

   #RotationPeriod    9.924920 #System III - magnetic field
   RotationPeriod     9.927953 #System II - Great Red Spot
   Obliquity   2.22
   EquatorAscendingNode   337.77

   #RotationOffset 305.40 #for System III map with central prime meridian
   #RotationOffset  21 #default jupiter.jpg
   RotationOffset  -36  #jupiter2k.jpg


Use this definition, and you'll find you get a GRS transit at 08:00, exactly as it should be for a light-travel time of 38 minutes to reproduce the GRS image you show.

If you stick with the above, and await Chris's revision of the Galilean orbits, everything should fall into place

Grant

[t00fri]

I think there are several problems with what you've done, but none of
them are to do with my solarsys.ssc modification!

1) The CustomOrbits for the Galileans are rotated by about 20 degrees
in Celestia 1.2.5pre7 - Chris will fix this next time. By hauling
the EquatorAscendingNode around by 20 degrees you've approximately
fixed the Galileans' positions, at the expense of having Jupiter's
pole and prime meridian (and the orbital plane of the Galileans)
misaligned. Using my current Jupiter rotation parameters and a
proper set of elliptical elements for date, I can in fact reproduce
the satellite and shadow positions better than your "correction"
does.

Grant:

Of course, I basically agree with you, and meanwhile I also have incorporated
Chris' modification of customorbit.cpp & solarsys.ssc as of
yesterday in the CVS tree, using your parameters in solarsys.ssc.

Since at any stage approximations are used in Celestia, the parameters
involved may more or less deviate from the "true" ones, in order to achieve the
optimum results within a given approximation.

My point was simply that given the /present/ (incorrect) approximation
to the Galileans, an empirical modification of the two crucial Jupiter
parameters 'EquatorAscendingNode' and 'Obliquity' (whose values had changed
substantially over the last weeks in solarsys.ssc;-)) can achieve much improved
results (for the time being). Chris' had not informed the other
developers like myself, that the Galilean orbits were incorrect and
that he was about to correct them...

The preferable approach --as it is now--consists clearly in improving
the underlying framework and involve the more "correct" parameters this way;-).

Let me still point out an interesting|useful feature of the CCD from
Arkansas Sky Observatory that I displayed previously: I chose it (among many),
since the particular triple moon configuration (Callisto's
shadow on the left, Ganymede's in the middle and the lit Io at
the right /edge/) (along with the GRS) provide a most sensitive
configuration to control and tune

1) Jupiter's 'EquatorAscendingNode' and 'Obliquity' /independently/
from each other (given the Galilean orbits and everything else, of
course)!

The /horizontal/ position of Io and Callisto's shadow are very sensitive
to the value of 'EquatorAscendingNode', while Callisto's /vertical/
shadow position is most sensitive to 'Obliquity'. Knowing about the
geometrical meaning of those two parameters, it should be obvious
why I selected that particular configuration;-).

( 2) The image was taken exactly at the GRS transit time...)

It is still amusing that some further tuning of those two parameters
(before Chris' last corrections) led to a /virtually perfect agreement/
not only with the CCD, but most amazingly with virtually all the
delicate mutual Galilean events recorded by Jean Meeus in the
Dec. 2002 issue of S&T on page 100ff. This includes e.g. events like

a) Dec 15 2002: 4o2T
b) Dec 27 2002: 2e1A !!,

everything /in time/ to better than 1' (!), after accounting for the exact
light travel times from Horizons.

Reproducing the correct /annular eclipse shadow/ of Europa (2) on Io (1) is
amazing (event b))! Both are quite far apart and thus this is a most
spectacular test;-).

Unfortunately, although the latest accuracy with your parameters and
Chris' modification in the code is very encouraging, most of the
delicate mutual moon events like a) b) are /NOT/ reproduced anymore...
a) now appears as a /partial/ (not total) occultation of Europa by
Callisto, and b) does not take place at all. Moreover, some event
timings are somewhat off. It seems a slight
empirical tuning of the present parameters could get us back, however,
to a truely spectacular accuracy.

Therefore: all the parameters that we are presently using have
uncertainties. What are they and where do I find them? Then it would
be an entirely legal procedure to slightly adjust them within their
errors to match those mutual moon events. What are the least well
measured relevant parameters??


Bye Fridger

[t00fri]

This is how Celestia's agreement with the CCD image above has improved after Chris' corrections in the CVS tree of yesterday, using Grant's orbital parameters...The exact light travel time from Horizons has been taken into account, hence also the timing accuracy is remarkable. Moreover, with the Celestia default jupiter.jpg (bottom image), I need 'RotationOffset 16.0' to reproduce the correct GRS transit (System II).

Not bad;-)



Bye Fridger

[granthutchison]

I need 'RotationOffset 16.0' to reproduce the correct GRS transit (System II).

Odd - my offset of 21 is the calculated value, and works perfectly for me.
What rotation period are you using for Jupiter? My definitions are:

Code: Select all

   RotationPeriod     9.927953 #System II - Great Red Spot
   Obliquity   2.22
   EquatorAscendingNode   337.77

   RotationOffset  21.019 #default jupiter.jpg


Grant

[granthutchison]

Therefore: all the parameters that we are presently using have
uncertainties. What are they and where do I find them? Then it would
be an entirely legal procedure to slightly adjust them within their
errors to match those mutual moon events. What are the least well
measured relevant parameters??

The pole position of Jupiter is specified in the Explanatory Supplement to the Astronomical Alamanac to the nearest hundredth of a degree, with precession adjustments on the order of thousandths of a degree per Julian century - which is why I calculated the Obliquity and the EquatorAscendingNode to the same accuracy. So you can reasonably do some fiddling in the third decimal place; but the primary problem is always going to be with the precision/time constraint on calculating CustomOrbits for the satellites and for Jupiter. I supect that although you can always fiddle the orientation of Jupiter to correct one set of events, it will then throw off some other set of events in the past or future.

Grant

[t00fri]

The pole position of Jupiter is specified in the Explanatory
Supplement to the Astronomical Alamanac to the nearest hundredth of a
degree, with precession adjustments on the order of thousandths of a
degree per Julian century - which is why I calculated the Obliquity
and the EquatorAscendingNode to the same accuracy.

OK, I own that book, so I can look things up precisely...
Also, what about the uncertainties in the orbital parameters of the
Galilean moons?

So you can reasonably do some fiddling in the third decimal place; but
the primary problem is always going to be with the precision/time
constraint on calculating CustomOrbits for the satellites and for
Jupiter. I supect that although you can always fiddle the orientation
of Jupiter to correct one set of events, it will then throw off some
other set of events in the past or future.

Your latter statement is not obvious to me, although an optimal choice
of parameters may not be easy in practice. As I emphasized before, if
one uses|compares different approximations, the values of the respective
/optimal/ parameters may not be identical and notably may not be equal to the
"true" ones. The question is rather, how to device an algorithm that
converges to a controlled determination of these optimal parameters.
At least that's what physicists are tought in their first semester;-).

Concerning the value of the 'RotationOffset', 21 deg's is also
tolerable in comparison with the above CCD, but 16 degs gives definitely
better agreement. The parameters I used are what Chris put in
yesterday:

RotationPeriod 9.927953 # System II (for GRS)
# RotationPeriod 9.92425 # System III (radio emissions)
Obliquity 2.222461 # 1.82246 # 2.22246
EquatorAscendingNode -22.203 # -1.87785 # -22.203

The EquatorAscendingNode is slightly different from your value
360-22.203=337.797, but does not affect my conclusions about 'RotationOffset'.
Do we agree about the timing? The CCD was taken in Arkansas at 8:38 UT
on Dec 15 2002, when the light travelling time was 38.8100' according
to Horizons. This gives 7:59:12 as the Celestia universal time for the
event, as you can also see in the image display above.

Are you claiming that for these parameters you get an equally good
agreement of the GRS position with the one in the CCD with 21 deg
RotationOffset? That would indeed be strange...

Bye Fridger

[granthutchison]

OK, I own that book, so I can look things up precisely...
Also, what about the uncertainties in the orbital parameters of the
Galilean moons?

Haven't a clue. There's real-world error and Celestia error - and I've formed the impression that the error within Celestia exceeds the real-world error in estimating the parameters.

Your latter statement is not obvious to me, although an optimal choice
of parameters may not be easy in practice. As I emphasized before, if
one uses|compares different approximations, the values of the respective
/optimal/ parameters may not be identical and notably may not be equal to the "true" ones. The question is rather, how to device an algorithm that
converges to a controlled determination of these optimal parameters.
At least that's what physicists are tought in their first semester.

But the position errors of Jupiter and its moons within Celestia are varying in a complex way relative to the real world. And you're trying to fix that with a few, once-only adjustments to coarse settings like Obliquity and EquatorAscendingNode. What will be "optimum" in one time-frame is not likely to be optimum in another.

Are you claiming that for these parameters you get an equally good
agreement of the GRS position with the one in the CCD with 21 deg
RotationOffset? That would indeed be strange...

I'm saying exactly that. Since our other parameters agree up to the second decimal place, it looks like this is just a matter for the eyeball.
I was happy with my numbers because they reproduce the predicted transit of the GRS at 08:00 (geometric, no light-lag) - whereas your setting brings it on >5 minutes later.
Looking at your posted image again, though, it looks like there has been a bit of drift since the last determination of the GRS longitude - it's sitting slightly west of the central meridian at 08:00. But to my eye you've overshot, and my calculated values now undershoot by about the same amount.

Grant

[t00fri]

But the position errors of Jupiter and its moons within Celestia are varying in a complex way relative to the real world. And you're trying to fix that with a few, once-only adjustments to coarse settings like Obliquity and EquatorAscendingNode. What will be "optimum" in one time-frame is not likely to be optimum in another.

Here you definitely are misunderstanding me. I am not quite as naive and I know my trade;-).
Obliquity and EquatorAscendingNode where a simple start two days ago before I knew that the Galilean orbits were incorrect and before I learned that the errors on these two are presumably very small. But there a other orbital parameters that may be less well known in game. Once I locate these, the strategy is to take a set of say 10 characteristic and well chosen mutual Galilean events from Meeus' article and tune such that /all/ those events are reproduced. Since these often involve shadows of one moon cast onto another that is pretty far apart, the handle is enormous here.

I'm saying exactly that. Since our other parameters agree up to the second decimal place, it looks like this is just a matter for the eyeball.
I was happy with my numbers because they reproduce the predicted transit of the GRS at 08:00 (geometric, no light-lag) - whereas your setting brings it on >5 minutes later.
Looking at your posted image again, though, it looks like there has been a bit of drift since the last determination of the GRS longitude - it's sitting slightly west of the central meridian at 08:00. But to my eye you've overshot, and my calculated values now undershoot by about the same amount.

Grant

Tomorrow I post a plot both with 21 deg and 15-16 deg in comparison with the CCD...

Bye Fridger

[granthutchison]

Tomorrow I post a plot both with 21 deg and 15-16 deg in comparison with the CCD...

OK, no, you're right on this one - I concede you 2.5 degrees!
I've just done what I should have done in the first place, which is to copy your images into Paint Shop Pro. I've rotated the CCD image a degree or so to get it to align with Celestia's view, and resized it to match the apparent diameter in Celestia. Then trimmed off the upper part of the CCD image, containing the upper half of the GRS, and married it on to the Celestia picture - good match. (Even after doing that, it still looks wrong to me in the original version, though - must be the tilt and the size difference.)
So the GRS seems to be 5 degrees of longitude adrift from the current transit times on the S&T website.

Grant

[t00fri]

Tomorrow I post a plot both with 21 deg and 15-16 deg in comparison with the CCD...

OK, no, you're right on this one - I concede you 2.5 degrees!
I've just done what I should have done in the first place, which is to copy your images into Paint Shop Pro. I've rotated the CCD image a degree or so to get it to align with Celestia's view, and resized it to match the apparent diameter in Celestia. Then trimmed off the upper part of the CCD image, containing the upper half of the GRS, and married it on to the Celestia picture - good match. (Even after doing that, it still looks wrong to me in the original version, though - must be the tilt and the size difference.)
So the GRS seems to be 5 degrees of longitude adrift from the current transit times on the S&T website.

Grant

For your info, I attach GRS drift data from Arkansas Sky observatory during 2002 as well as drift data from 1964-1986, all in system 2. Apparently, there was a recent drift from ~80 deg to ~85 deg during the last few months! This is nicely consistent with your analysis above...

Bye Fridger