Celestia Forums

When time is synchronized among all multiple views, there is really only the need for one clock. But could we also have multiple clocks for multiple views when time is not synchronized? This should probably be limited in number, or we could have clocks all over the place, but a couple of extra clocks would be useful and highly instructive. Perhaps it could be related to the size of a view.

One example: watching a Galilean eclipse from Earth (clock set to Earth time) and watching the same from near Jupiter (Jupiter time with Light Travel Delay). The two could be seen to differ by the amount of the LTD.

Regards,
Gary

Gary,

firstly, in my view, the simultaneous display of several clocks with different times would be confusing to many, since a majority does not really know about the subtleties of special relativity. In addition, people might easily forget which of the >= 2 visible clocks displays which time. You might argue of course that buying a subscription to your site could provide the lacking explanations. You may actually retrieve many relevant forum discussions about 6 - 7 years ago, when we implemented both LT display and the Multiview feature into Celestia...

Secondly, we do already have implemented various concrete possibilities that you mentioned (except that we only show ONE clock, but with different times):

For example: In Multiview ==>

activate a Horizontal Split,
activate "View active Frame" , <======= this is instructive!

Set time display to UTC.

In the left-hand frame GO to Earth, select it and activate LT display ('-' key).
Activate next the right-hand frame (TAB - key) and GO to Jupiter. Hence, in the left-hand frame Earth is displayed and in the right-hand frame we see Jupiter.

Now attention, please:

Return to the left-hand frame (TAB - key) and make sure Earth is selected: note down the UTC time.
Then, hit TAB - key, which activates the right-hand frame, BUT retains the selection of Earth. Note again the UTC time! Indeed, the displayed time has advanced by about 1 hour (<=> LT). Finally, select Jupiter (by clicking on it) and note the time again... Aha!

This was a simplified illustration of your above example concerning Gallilean moon eclipses in two frames with LT activation.

Last not least, adding more clocks or other displays to the canvas, always has a price tag: a tendency of cluttering and distracting from the main content: The beautiful Universe display in 3D

Fridger

I'd add that Fridger's nice example could be trivialy celx-scripted
so as to be easily reproducible in an educational context. If really
needed, the different clocks could be also displayed in the frames.

Greetings, Vincent,

I've been greatly impressed by your work for some time. I've been trying to find an e-mail address for you but have been unable to find one. Do you prefer not to receive e-mails from Forum Members?

Anyway, back on topic, yes, displaying the clocks in their respective frames (only necessary if time is unsynchronized) is exactly how it should be done. Supporting frames and unsynchronized times, the lack of individual clocks in unsynchronized frames seems a glaring oversight. In the first place, just seeing clocks in multiple frames when time IS UN-sychronized, yet only one clock when it IS synchronized, is an emphatic visual cue that would benefit new users in particular. More importantly, it eliminates having to go through the a lot of distracting "back and forthing".

As you have done so much to make Celestia easier for new users to enjoy, I'm a little surprised by your response and am interested to hear your further thoughts.

Regards,
Gary

Fridger,

Now attention please:
#1: there is no need for you to spend your valuable time stating the obvious. Plus, your example perfectly makes the point of the "back-and-forthing" that is currently necessary to stay apprised of the time in unsynchronized frames.

#2: once you are again injecting Special Relativity into an issue where Newtonian and Einsteinian reference-frames are essentially equivalent. Having calculated the maximum time dilation of the planets, I look forward to debating (or discussing, your choice) this more in future posts.

#3: if this Forum is the proper place to discuss my site, I will be happy to go head to head with you on that issue also. I'll contact Selden and Chris to confirm what is appropriate.

Looking foward to more robust exchanges.

Gary

VikingTechJPL wrote:Fridger,

Now attention please:
#1: there is no need for you to spend your valuable time stating the obvious. Plus, your example perfectly makes the point of the "back-and-forthing" that is currently necessary to stay apprised of the time in unsynchronized frames.

My example was nothing but a reply to your above example! Is it really true that you consider hitting the TAB key repeatedly a "back-and-forthing"? In any case, I am only concerned with potential hard coded (C++) code changes in Celestia. Anything that is done at the scripting level is another issue.

#2: once you are again injecting Special Relativity into an issue where Newtonian and Einsteinian reference-frames are essentially equivalent. Having calculated the maximum time dilation of the planets, I look forward to debating (or discussing, your choice) this more in future posts.

Please believe me, I know what I am talking about. I explained it once already. Of course, the planetary movements are non-relativistic to very good approximation, but space travel is NOT, once you want to visit distant bodies! Cosmology is highly relativistic (GR).

From a consistent physics point of view, there is no escape from a special relativity framework, once the speed of light is taken to be finite (non-infinite) and frame-invariant. Some movements like e.g. the planetary ones are still non-relativistic, yet the underlying framework is definitely relativistic. That was all I meant to express above.

In my LT approach, I have therefore just added the LT feature as an optional, purely calculational tool e.g. for timing eclipses, but NOT as part of Celestia's astromechanical framework.
But as soon as >= 2 permanent clocks were displayed on screen (one for each frame), then the situation changes conceptionally. Then we should define exactly what times are displayed by each of the clocks.

#3: if this Forum is the proper place to discuss my site, I will be happy to go head to head with you on that issue also. I'll contact Selden and Chris to confirm what is appropriate.

Looking foward to more robust exchanges.

Gary

As long as the forum discussions are led politely, and are neither about politics, religion or sex, it is not Chris' or Selden's decision what forum members address or don't address...
Your site is accessible by the public in the net, hence anyone who likes to write about it here is entitled to do so.

Fridger

Fridger,

Item by item in reverse order:

Item 3: Agreed 100%.

Item 2: The non-relativistic approximation is exactly what we'd be talking about when viewing eclipses, occultations and most other events from planet or moon surfaces, or even from in typical orbits. Though, come to think of it, some comets get pretty fast near the Sun, and their time dilation would be interesting to calculate. As for space travel, we both know the first two issues that arise: first, what happens to the Lorentz Transforms' denominators as v approaches c; denominators abhor zeros as much as "nature abors a vaccuum"; second, as soon as we travel faster than c, we're no longer in the realm of relativity anyway. We broke it! Even Celestia's single clock "should" relativistically be disabled when we exceed c. But, hey, Celestia's little bit of license here is eminently acceptable.

In my LT approach, I have therefore just added the LT feature as an optional, purely calculational tool e.g. for timing eclipses, but NOT as part of Celestia's astromechanical framework.

I hope you don't "de-emphasize" LT for users. It works great for non-terrestrial eclipses viewed from Earth. It's interesting that you chose to index it to planet time, and then work backward to Earth time, rather than the other way around. Using the opposite approach, all non-terrestrial eclipses viewed from Earth would not have needed to be adjusted time-wise by LT. Either perspective has its advantages, though I think I might have chosen your approach too since not having to change the time frame out at each planet is a plus for new users. It's easier for them to understand an "absolute time" (dare we say) at each planet. I downloaded Celestia's code and looked at the implementation; simpler is better; one division, one addition/subtraction. The key-bindings probably took you longer to code than the math.

But as soon as >= 2 permanent clocks were displayed on screen (one for each frame), then the situation changes conceptionally. Then we should define exactly what times are displayed by each of the clocks.

Admittedly, this presents the issue of defining the other clocks' time-frames. When we're seven light-seconds from Jupiter, do we use Jupiter time or do we use Jupiter time minus 7 seconds? Sounds like we might be doing the same type of head-scratching that Michelson and Morley must have done.

Item 1: With 2 un-synchronized views it's not much of an issue, just slightly distracting. With 3 or more un-synchronized views, the "back-and-forthing" becomes "round-robin-ing" (always 1, 2, 3, 4,...) unless you use the mouse. That's when it becomes more of a pain. Still, the main drawback is that you only have one clock on the screen at a time. I can implement multiple clocks easily in CELX, but the option of two (or more) clocks in un-synchronized frames would still be nice for non-CELX users as a basic feature of Celestia.

Gary

Gary,

let me try being short.

While in special relativity each Lorentz frame has it's own time, in the non-relativistic Galilei limit (c-> infinity or v/c -> 0), there is only ONE universal time and hence ONE clock! Obviously we are not talking here about "daylight saving times" or different local time zones. It's the time differences (i.e. the clock tick intervals) that become frame dependent! 2 events happening at the same time in one Lorentz frame (2 exploding fire crackers, for example) won't be concurrent in another. You can see that easily by inspecting the general formulae for the transformation of time in special relativity: in the limit that v/c -> 0 you find t' -> t for ALL frames!

Since Celestia rests mainly on a non-relativistic framework, it is fair to employ an observer who is able to travel with infinite speed, c -> infinity, ( rather than with the physical finite speed of light c). And the displayed time in Celestia is meant to be the unique Galilei time, actually. That's why I am against installing more than one frame-dependent permanent clock on the screen. This might even be more confusing for knowledgable than for ignorant users But it seems from your reply that you got this somewhat subtle point.

On the other hand, once we introduce permanent frame-dependent clocks we have to bother about all the rest of special relativity as well for consistency. Like how to deal with an observer whose maximal speed is limited by c, who experiences a strong relativistic distortion of his/her visual field of view while travelling with v ~ c , color shifts and many other relativistic phenomena. Worst of all is the problem how to reach e.g. Alpha Cen and further distant objects . In addition, astrophysics knows a number of phenomena where special relativity is essential: like what happens around quasars (jets...) or cosmic rays or the description of gamma ray bursts or the understanding how stars generate their energy for long periods of time via E = m * c^2 etc. This features are not (yet) relevant for Celestia, though.

Fridger

Vincent,

Using a CELX script as you suggested does work well. The advantages here made a big difference. I tried this script with just the clocks, and it really didn't tell enough. With the added annotation afforded by CELX, it became much more understandable—especially at first glance. This script should help make the point that we don't see what happens on the other planets right away. Hopefully, new users will also begin to associate planet distances with certain ranges of Light Travel Time.

By looking at a number of eclipses, they can also see that the LT to a planet can vary due to Earth's orbital diameter and the eccentricity of all planet orbits.

Thanks for the input,
Gary

Hi Gary,

VikingTechJPL wrote:I've been trying to find an e-mail address for you but have been unable to find one. Do you prefer not to receive e-mails from Forum Members?

I've been in touch with many forum members through Private Messages and then, via e-mails when needed.

VikingTechJPL wrote:As you have done so much to make Celestia easier for new users to enjoy, I'm a little surprised by your response and am interested to hear your further thoughts.

The point is precisely to make a clear discinction between what can be done using Celx or Lua scripting and what should be hardcoded.
A lot of great ideas and features have been submitted for implementation. In that aspect, the Celx API and the Lua Hook process provide a great sandbox to test them.
Back to your request for displaying multiple clocks, I recently added a celestia:synchronizetime method to Celx precisely for that kind of purpose. By my response, I meant that celx scripting represents to me a far better way to exploit what you suggested because it offers the possibility to display some extra information text. Also, an implicit rule tells us that any feature that will overcrowd the Celestia viewport should be kept away from the Celestia core code.

VikingTechJPL wrote:Using a CELX script as you suggested does work well. The advantages here made a big difference. I tried this script with just the clocks, and it really didn't tell enough. With the added annotation afforded by CELX, it became much more understandable—especially at first glance. This script should help make the point that we don't see what happens on the other planets right away. Hopefully, new users will also begin to associate planet distances with certain ranges of Light Travel Time.

I'm happy that you eventually made up your mind to use a celx script. I'm really looking forward to testing it!

Best regards,
Vincent