Special Relativity App

I have written an application to show the basic need for Special Relativity. The model contains an Observer and an Emitter which can have a velocity. The Emitter will emit a Photon every 1s of model time. Each Photon is encoded with the time and position that it was created at. They travel back towards the Observer until they reach it and are measured. The Observer will record the emission information already encoded in the Photon and the observation information containing the time the measurement was made and the period since the last measurement.

There are 3 models running at the same time, in fact they all have the same 'in model' time, meaning that the period 1s is the same in all models and they all consider the 12th second to be the 12th second. Time is truly equal across models.

The top model has an Emitter that does not have a velocity. This allows you to see how a signal unaffected by Relativity will look.

The middle model has a velocity of 0.5c.

The bottom model has a velocity of c. This is the maximum influence that velocity can cause.

The results of each model are recorded in some tabs along the bottom half of the page. The tabs are labelled 'Result Set 1', 'Result Set 2' and 'Result Set 3' matching the top, middle and bottom models respectively.

Here's a screenshot:


There are some controls to zoom in or out a bit, scale distances and set the precision of the models.

You can use it on my site at http://www.nevyns-lab.com/mathis/app/Relativity/Special.

This app will help with understanding Miles in his Relativity papers. The first paper, Relativity as a Concept, starts out describing exactly what this app shows.

This app is a much simpler version of the desktop app I wrote about 5 years ago. I may look into allowing custom velocity settings and acceleration, which shows the next level of Relativity.

Here is a section from the Relativity as a Concept paper:

Miles Mathis wrote:
To do a transform you have to assign a set of variables to your incoming data. You can make them primed variables, for example. This is what Einstein did. But conceptually you aren’t finished. You now have to assign your coordinate system. It isn’t enough to make a variable assignment. You have to also define your new coordinate system. This is where the central error is made. In the Pioneer example, the data is coming from the spacecraft, so Einstein and everyone else defines the primed coordinate system as belonging to the spacecraft. But this is false. What we receive on earth is just data. We are measuring or observing not the spacecraft itself, but information arriving from the spacecraft. In other words, we are seeing how the spacecraft looks to us, not how the spacecraft looks to itself.
      The whole reason we have to do a transform in the first place is that the finite speed of light is skewing the data. The information from the spacecraft is arriving late to us, compared to when it was experienced by the spacecraft, and it is arriving with time periods stretched out and meters compressed and so forth, as we know. We do the transform in order to correct this. The transform gives us numbers that we can compare to local numbers and make sense of. But if the finite speed of light is skewing the numbers, then logically the numbers must have been unskewed back at the spacecraft. The spacecraft is not emitting funky data, we are receiving funky data. It is the distance between us, and the finite speed of light, that is causing the difference. Therefore, the spacecraft, which is no distance from itself and is not seeing itself with light that has had to travel long distances, must be experiencing normal local data.
      This means that the transform is not expressing a difference between the numbers of the spacecraft and the numbers on the earth. The transform is expressing a difference between numbers arriving at the earth on E/M waves and numbers on earth arriving from a negligible distance. To put it another way, x’ is not how the length of the spacecraft looks to the spacecraft, it is how the length of the spacecraft looks to us, from a long distance away. Therefore you cannot give x’ to the spacecraft. You must give x’ to the data only.

Nevyn,

Looks good. If you are showing that the observer sees time slowing (apparent only, not real as your sim clearly shows) from photons released by high/light speed emitters, then fine.

Beyond that though, I see some confusion. Why is the apparent time dilation in line two, v=c/2, 3/2 that of normal time (line 1)? The observer in line 3 views an emitter traveling at c with a time dilation of only 2? You might want to add a line, The emitter experiences normal time, it only appears distorted, or lengthened, to the stationary observer. I think you also need to include the transform.

I take special pleasure in reviewing your simulations, no personal slights intended. Please let me know when I can review Special Relativity.
.

You can review it at any time, Airman. If I put it up on the web then it is ready for criticism. Not necessarily complete, but I am open to any comments, good or bad.

The amount of influence that Special Relativity can apply is based on the time between light pulses, let's call that t. At most, it can only apply a 2*t affect. That is because the Emitter only has t to move in until the next pulse.

Think of it this way: with no velocity, there is t between each pulse, 1s in my models. During that time interval, with a velocity of c, the Emitter can only travel t * 300,000km.

The Emitter emits 1 photon at t=10, say. During the next t, that photon, let's call it P1, travels away from the Emitter at c. In that same t, the Emitter is also traveling at c in the opposite direction. So when it emits P2, at t=11, there is 2t * 300,000km between P1 and P2. Therefore, the Observer will see P1 at some time, let's call it t1', and P2 2t later, t2'. Since photons always travel at c and the Emitter is also traveling at c, the maximum possible speed, therefore the maximum possible affect is 2t.

If we made t larger, let's say t=2, then the maximum affect would be 4s. You can only double the time between observed photons because photons already move at the fastest possible speed and to reach the maximum affect, the Emitter also has to travel at c in the opposite direction to the photons.

I always struggle with the words associated with my apps. How much do I need to say? What do I need to tell the user? In this case, I didn't want to say too much about the conclusions that can be drawn from the model. I started to, but decided against it. The results give you enough information to discover the transforms and I thought that is a good exercise for anyone trying to understand Relativity.

What I might do is create another page with my analysis and the transforms that I have found from the data and provide a link to it in the app. This way, the user can choose not to look at it and work it out for themselves or, if they can't be bothered to do so, they look it up.

I'll give you a head start. I have found that there are multiple degrees of Relativity. The first degree is shown by the top model in this app. The Emitter has no velocity at all, but is some distance from the Observer. This introduces a time delay between the Emitter emitting the photon and the Observer measuring it. There is no time dilation or anything like that, just a basic time delay. Find this transform first. Find the way that the Observer can determine the actual time that the Emitter emitted the photon given the distance that the Emitter is from the Observer.

The first degree of Relativity, let's call it R(1), is caused by distance. The second degree of Relativity, R(2), is caused by a changing distance so the Emitter has to have a velocity, relative to the Observer. Once you have the transform for R(1) it is easier to see what the transform for R(2) will look like.

You can probably guess the next degree already as it is based on a changing changing distance, or an acceleration. In his papers, Miles seems to suggest that R(3) is caused by a second entity that has a velocity with respect to the Emitter. This seems to give it 2 velocities with respect to the Observer, but I have found that it does not.

The reason for this is that the new entity, let's call it Sub-Emitter (because it is an Emitter inside of the existing Emitter), can be considered to have a single velocity relative to the Observer just by adding the velocity of the Emitter, relative to the Observer, with the velocity of the Sub-Emitter, relative to the Emitter, together to get a single velocity.

Let's do some basic math to see how this works.

Let:
vEO = velocity of Emitter relative to Observer
vSE = velocity of Sub-Emitter relative to Emitter
vSO = velocity of Sub-Emitter relative to Observer
t = time between distance measurements

vEO = 10m/s
vSE = 1m/s
t = 1s

Then:
In t seconds, the Emitter will move 10m away from the Observer.
In t seconds, the Sub-Emitter will move 1m away from the Emitter.
Since the Sub-Emitter is connected to the Emitter it will also move 10m from the Observer during the same time interval. At the end of that interval, the Sub-Emitter has moved 11m away from the Observer. Therefore, the Sub-Emitter has a velocity of 11m/s relative to the Observer.

vSO = vSE + vEO

Which is just a regular velocity, no acceleration involved. Everyone has thought that there must be an acceleration involved because the Sub-Emitter is moving relative to the Emitter while the Emitter itself is moving. The problem is that they are all thinking between the measurements. By that, I mean that during the time interval between measurements, it looks like the Sub-Emitter is accelerating. But that time between measurements in not in anyone's data. Only measurements are part of your data so you can't tell what is happening during the interval. At the end of the interval, when we have something measured, we can see that the Sub-Emitter has moved a set distance from the Observer and that distance is constant because both the Emitter and Sub-Emitter have a constant velocity.

In my desktop version of this app, I did implement the Sub-Emitter concept expecting to see R(3), but only saw R(2). I had to implement acceleration of the Emitter to reach R(3) which, once I figured out the degrees of Relativity, made perfect sense.

I have wanted to discuss this with Miles for years but wasn't confident enough in my analysis. I'll let you guys pick it apart for a while and then I think I will write a paper about it and see what Miles thinks.

Another way to look at the maximum affect of Relativity is to reverse the direction of the Emitter. I can do this in my desktop app but haven't included it in this version as I think I will create a series of similar apps to show the different scenarios.

When the Emitter starts at a large distance from the Observer, with a velocity of c towards the Observer, the photons and the Emitter are moving in the same direction. This makes the observed time between photons less than t, in this case it makes it 0.

The Emitter emits a Photon at t=0. During the time from t=0 to t=1, the Photon moves towards the Observer at c. But so does the Emitter. So at t=1, the Photon and the Emitter are in the same location. So the next Photon emitted will also be in the same location.

This gives us a series of Photons emitted at different times but all with the same location at every stage (ignoring the fact that they can't all occupy the same space at the same time). So the Observer will not see any of them until they all reach the Observer at the same time (including the Emitter).

This makes perfect sense because you can only see light that hits you. You can never see light at a distance. In fact, you never see anything at a distance because you never see anything other than photons. You infer the distance by analyzing the complete picture, not the individual photons.

So Special Relativity has a range of [0, 2] times by t, the time between emitted photons, which is set by the speed of light. To be more precise, it is set by the speed of transmission of the signal, which in this case happens to be c.

I have made a few updates. Cleanup up the code a bit. Restructured a few things and generally made it operate better. Under the hood, it is now capable of using any number of accelerations but I haven't used them in the release version yet.

I added some more words to describe how time and coordinate systems are handled and a little bit about finding the transforms. I hope it isn't too confusing.

The 3 Emitters now start at the same location, rather than models 2 and 3 starting at the Observers. This does cause a 10s wait for results to come in and offsets all results by a 10s equivalent which is why I have used 10s. It makes nice round numbers that are easily subtracted to remove the latency.

.
Nevyn, Your logic showing an observed time dilation of a close to lightspeed emitter of less than two seems correct.  

The idea of a relatively stationary forward photon wavefront at lightspeed is new to me. I always believed that the time experienced by a passenger on emitter three dilated until the observed speed of photons traveling forward would reach light speed. Therefore someone traveling at close to light speed could make a quick round trip back to their source and observe that hundreds or thousands of years had gone by, depending on how close to light speed the passenger traveled at. My understanding was obviously the product of science fiction. It certainly makes more sense to accept that the passengers on the emitters experience no time dilation at all.
.

Yes, once you look at the cause of Relativity, you can see how stupid the twins paradox really is. To his credit, when Einstein was asked about it, he said he didn't know if it is a real thing or not. I think he did know but didn't want to rock-the-boat of his own promotion by contradicting most other Physicists. He was already on shaky ground, so I can't blame him for sitting on the fence. Of course, here we are 100 years later and physics still hasn't straightened it out, so I wish that he had spoken up (and someone would have listened to him).

There was a thread on Reddit a few weeks ago asking about the age difference between the twins and I so badly wanted to say zero, but it really isn't worth the trouble. I've tried to explain this to a colleague at work who is into mainstream physics but he just won't listen, won't look and won't think for himself. It's too frustrating so I don't bother anymore. I am willing to put my apps out there for others to find and hopefully get something out of, but I won't try to convince anybody that isn't asking to be convinced anymore.

I have made some slight changes.

I am using some 3D models to represent the Observer and Emitter. They look pretty good but the textures have not been applied. I have to figure out how to get them into the model.

Some code has been refactored to allow easy interchanging of result set formats and better support for varying number of columns which is needed for the acceleration version of this app, coming shortly.

The app checks to see if you have WebGL available in your browser and if not, it uses a software renderer. This has degraded performance so it doesn't use the 3D models and removes all lighting and the materials to support them. Even at that reduced quality, it is still slow and gets slower the more photons there are in the model.

It has been brought to my attention that this page does not work well in Safari. I've tried to work around the issues but some are being very stubborn. It now shows a warning message to Safari users but I recommend using a better browser. Safari is quickly becoming the pain that IE used to be.

Just wanted to say this is very interesting Nevyn and dare I say "Ingenious".

I've published the acceleration model at www.nevyns-lab.com/mathis/app/Relativity/Special/sr-acc.html.

Note that I have changed the name of the other page which was called SpecialRelativity.html but is no called sr-vel.html. I wasn't thinking ahead when I originally named the file. That old file name will still actually work because I put in a page that will redirect to the new one in case anyone had the old link.

This version contains a top model with no velocity, a bottom model with a velocity of c and a middle model with an initial velocity of 0 and an acceleration of 0.1c by default. You can vary the acceleration between 3 settings: 0.001c, 0.01c and 0.1c.

This allows you to see the middle model start out like the top model and accelerate towards the bottom model. Once it reaches a velocity of c its acceleration is removed.