Twin Paradox Visualization: Understanding with Java & Diagrams

In summary, the program shows two diagrams, one from the perspective of the stay at home/earth twin on the left side and the traveling twin on the right side. The accelerations are considered to be near instantaneous, hence why you won't see the clock counters of the traveling twin's clock rising during the acceleration phases as almost no time/negligible "time passes" from his perspective. The blue clock being an instance of the stay at home twin/clock which is always measured to be "at the same time" from the traveling twin's perspective. At stage 3 and
  • #1
Jeronimus
287
9
I decided to work a bit on my Java program created to visualize the Twin Paradox. It shows two diagrams. One from the perspective of the stay at home/earth twin on the left side and the traveling twin on the right side/diagram.
The accelerations are considered to be near instantaneous, hence why you won't see the clock counters of the traveling twin's clock rising during the acceleration phases as almost no time/negligible "time passes" from his perspective.

here is a video running this:



Stage 3 and 4 are the most interesting ones. You can see how the traveling twin measures the blue clock counter to be below his counter, hence having "ticked slower" during his travel up to stage 2.

The blue clock being an instance of the stay at home twin/clock which is always measured to be "at the same time" from the traveling twin's perspective.

At stage 3 and 4 however, you can see how he will measure the blue clock to be ticking much faster during the acceleration phase in stage 3 and 4.
It's important to understand that this is caused by the traveling twin measuring different instances of that clock to be crossing his x-axis (simultaneity).I am not done yet with this program, but i think it is pretty interesting still and might help some understand the twin paradox better. Any ideas on how this could be displayed in a better way are more than welcome.

The shameful code for this can be found here http://pastebin.com/Bj75SiMH

...in case someone wants to mess around with it. But be warned, it's very "experimental"/terrible. A mess that i did not get time to clean up yet. The easiest way to run it, would be to download the free DrJava IDE (google it).
Then just copy and paste the code into it, hit the "compile" button and then the "run" button.
 
Last edited:
Physics news on Phys.org
  • #2
I also uploaded it to my google drive, since youtube seems to be a bit random about displaying it in HD or not

https://drive.google.com/file/d/0BxMwFJfbOvWveFVSNkVwaFpGY1E/view

It's smaller in size (just 17mb) and better quality since no re-encoding is taking place. It does display directly as video in the browsers i tried but i guess it depends on if they support the x264 codec i used.

Some confirmation on if this worked would be nice.
 
  • #3
Looks like i got into the alpha stage.

I added a few additional features. A few more moving "clocks" added to the whole. "clocks" in quotes because it depends on what we interpret as a moving clock it seems, after pondering my own creation. Here is a video showing some of the extra features.



So when you see those colored dishes moving around, they are first and foremost events measured to be happening at x,t according to the defined methodology of measuring the positions in space and time, and the dish of equal color in the other diagram is the same event measured at different positions x', t' depending on v_rel and how far the "travelling observer" moved.
Travelling observer in quotes, because if you check the animation until stage 2, especially if you click on "show symmetry" you might discover that it did not matter who of the twins accelerated at the beginning in stage 1. By the end of stage 2, the picture looks fully symmetric to me.

You might ask, "then why does the traveling observer's (white dish) clock show less seconds by the end of stage 2?". Well, that is because of bloody favoritism of drawing the two diagrams like this it seems. I had to choose one side... or so it seemed/seems to me.

The white dish represents the instances of the clock local to the traveling twin (the clock he wears and is traveling with) which are crossing the x-axis("now" axis) of the stay at home twin. Hence, what he sees as a clock/twin moving away of him.

The second diagram, showing the traveling twin's perspective at a given "time", was designed with the idea in mind to somehow keep the two diagrams in sync, but by doing so, you create the illusion of there having been an asymmetry, showing "clearly" in the different clock counters between the two twins.

The procedure in drawing the two diagrams was basically:

Let the traveling clock/twin move a little from the stay at home twin's perspective. Check the position and then use the Lorentz transformations(setting t=0 x=0 where the traveling twin is currently) to transform the coordinates into the other diagram. That way, the traveling twin is always at x'=0 t'=0 as it should be one would think. And the stay at home twin is also always at x=0, t=0.
But doing it that way, the stay at home twin "moves faster" towards the time axis than the traveling one.

Instead, i could have designed the diagrams, such that i keep the blue clock/stay at home twin always at x=0, t=0 on the left diagram and nothing would be wrong with that. In that case, we would see the traveling twin move faster towards the t axis and his counter being ahead instead. We would have to stop at 8.66s however, because that is where the acceleration takes place.
If we were to not accelerate at all, the time difference would keep increasing, favoring the traveling twin to be ahead in time seemingly.

So i thought, let's see how all this looks if we let both traveling "at the same speed" towards the t axis. Some kind of "God" perspective outside, not favoring any of the two. Basically i drew the events on the right diagram, and then moved everything down by the time difference required to make both even.

There is nothing wrong with that except that your head might start wobbling, trying to figure out what "now" is for who, where and when.

Looking at my own creation, questions came into mind, like "Can a resting, non accelerating observer be fooled into thinking that he is accelerating?". "Can an accelerating observer be fooled to think that he is at rest?" One would think that this is not possible, because just by placing two clocks at the same distance to himself, he would see those clocks going out of sync. The clock towards the acceleration direction would run faster than the clock behind.
It would SEEM that there would be no way of getting two such clocks to be synced. But to make such a statement, one would have to fully wrap his head around this complex matter. Especially in understanding what the "now" is.

the code can be found here: http://pastebin.com/xCsqT8zK (edit: link changed... some "bug" i forgot to fix before posting, making fullscreen work only on 2560,1440 monitors)

You can just copy and paste the code into drJava (or some other java IDE) and just hit compile and run to run it. This time i also created a jar file(single click executable if you have Java on your system) using netbeans. Worked fine both in linux and windows. The file can be found here.

https://drive.google.com/open?id=0BxMwFJfbOvWvbmZrNjNtTWU4VHc (edit: also changed, see above)

Nevertheless you would need to have some form of Java JVM/JRE installed on your system to run it.

You can also download the video in a better quality while being smaller in size than the youtube video here:

https://drive.google.com/file/d/0BxMwFJfbOvWvTERJcVdjY3p0aVk/view?usp=sharing
Unfortunately the code is quite messy still. I cannot make sense of it myself when looking back at the formulas at times. If it wasn't for watching my own program, basically showing me when i got the formulas wrong, i could not have done it. A lot of times i just smashed the keyboard like a monkey until i got it right out of chance i suppose.
A lot to be done still, especially the light beams part. I had to think of an algorithm to draw the light grid efficiently. When i couldn't figure it out in a timely manner, i just had EVERY clock emit a light beam into all directions which is why you might see the light rays to not be THAT straight at times.
It all seems so easy until you actually have to put it down to code.
 
Last edited:
  • #4
When checking "show symmetry", one should also un-check "show black clocks counters" for now. I forgot to also move the black clocks "down in time"(while show symmetry is checked) on the right diagram, so it wouldn't show the right output.

This will be fixed in the final version, where i also plan to add two more smaller canvases below the diagrams, showing actual clocks at different locations as their counters advance while they move towards the observers or the observers move towards them, depending on the observers/perspectives. I have not figured out yet which would be the best method to represent this.
It would be just the x axis. Now time axis. Showing the clocks which cross the "now"-axis of the twins.

Also, the final will allow to adjust the v_rel and time to travel before the turnaround, which is questionable of how useful it would be in terms of watching all the stages, but it certainly seems to be useful as in being able to slowly accelerate to near c and watch how the geometry of the right diagram changes.

Someone might be able to pick up on a project of creating a "mechanical Lorentz transformator" should such an animal not exist yet. Again, i am not sure of what would be the "best" way to do it, but by watching the right diagram while acceleration is taking place, especially with the light grid turned on, you can see how the light beams would translate into rods certain events always stay on.

The events themselves, or clocks with counters if you want, would be connected through springs possibly, rubber bands would also be an option possibly. In the case of "infinitely" many and arbitrary small springs/rubberbands, we are maybe looking at some elastic material possibly.

One can see that pulling at one of those clocks representing events, which lie one of the two lightbeams of the lightcone, if the apparatus was properly built, it would mechanically "compute" the Lorentz transformations.
By being able to move the two "main rods", hence the lightcones and having them intersect with other rods representing the light grid, one could do the boost/acceleration at different points of this mechanical spacetime-"fabric".
Basically the static universe. You can stretch and bend it however you want, at whichever point you like, but it remains the same (in a sense).
 
  • #5
To not keep spamming this thread, i will keep the newest version of the program and code included as links in the description of the video on youtube unless some major change happens.
The named bugs have been fixed and the ability to change the velocity added as well.

Unless i come up with the final version, this will be where to look for the latest.

This will be the last links for now

https://drive.google.com/open?id=0BxMwFJfbOvWvZjZTdUsyRDA4OGs the jar file

and here is the code https://drive.google.com/open?id=0BxMwFJfbOvWvM3dsWWpmU3JGQnM a .java file
 
  • #6
I worked a bit more on the code. Now you can zoom in and out using the mousewheel. I also added the 2 extra canvases showing the "twins" (in this case, clocks) i mentioned above. Within the added canvases below the two diagrams, you can now see exactly how the clock counters of clocks at a distance to the twins behave, especially during the acceleration phase.

A lot more could be done, but this might be the final as my motivation to improve this more is dwindling.

Here is a video showing the new capabilities.



the links to the updated code and executable jar file are same as above. (google drive allows you to update versions i figured out later)
 

1. What is the Twin Paradox?

The Twin Paradox is a thought experiment in special relativity that involves two twins, one who stays on Earth and one who travels through space at high speeds. When the traveling twin returns to Earth, they find that they have aged less than their twin who stayed on Earth due to the effects of time dilation.

2. How does Java help visualize the Twin Paradox?

Java is a programming language that allows us to create interactive simulations and visualizations. In the context of the Twin Paradox, Java can be used to create animations and diagrams that help us understand the concept better.

3. Why is it important to understand the Twin Paradox?

The Twin Paradox is an important concept in special relativity and helps us understand the effects of time dilation and the relativity of simultaneity. It also has practical applications in fields such as space travel and GPS technology.

4. Can the Twin Paradox be proven through experiments?

While the Twin Paradox is a thought experiment, it has been verified through experiments using atomic clocks and high-speed particles. These experiments have confirmed the predictions of special relativity and the effects of time dilation.

5. Are there any limitations to the Twin Paradox visualization using Java and diagrams?

The use of Java and diagrams can help us understand the concept of the Twin Paradox, but it is important to note that they are simplifications and do not fully capture the complexities of the phenomenon. It is also important to have a solid understanding of special relativity to fully grasp the visualization.

Similar threads

  • Special and General Relativity
Replies
31
Views
1K
  • Special and General Relativity
Replies
13
Views
2K
  • Special and General Relativity
Replies
20
Views
2K
  • Special and General Relativity
Replies
14
Views
710
  • Special and General Relativity
Replies
5
Views
638
  • Special and General Relativity
4
Replies
122
Views
5K
  • Special and General Relativity
Replies
11
Views
1K
  • Special and General Relativity
4
Replies
115
Views
5K
  • Special and General Relativity
3
Replies
70
Views
4K
  • Special and General Relativity
Replies
24
Views
2K
Back
Top