Lorentz Transform Simulator

INTRODUCTION

This is the manual of the Lorentz Transform Simulator. This software lets a user easily create a simulation of physical bodies moving according to the laws of Special Relativity. The user can create bodies, set their names, colors and initial velocities and define rules that the bodies will obey, such as "at time 5:00, the body P1 changes velocity" or "when P1 meets P2, P1 emits a signal S1 towards P3". After building the model, the user can start the simulation, change its speed, stop it, freely move along the time axis like with a YouTube video, select any reference frame and see what happens in that frame.

The real reason why I wrote this program is that I am sick tired of people who invent trivial examples that, in their opinion, should easily prove Relativity wrong. I am sick of telling these guys that the mathematical consistency of the theory can be - and has been - demonstrated, sick of telling them that all their counterexamples are based on trivial mistakes and that they should just learn how to use the Lorentz transforms correctly. The next time one of those guys will come up with a new example, I'll just tell him to build his simulation using this program and see what happens according to the real laws of Special Relativity, not according to the distorted picture of Relativity in his mind.

However, if you are going to use this program, please go on reading this manual. This Relativity software is relatively easy to use, meaning that, if you read the manual, you will probably find the program rather easy to use. If you do not, you'll probably find it incomprehensible and unusable.

A basic knowledge of Special Relativity is assumed. You are not required to be able to use Lorentz transforms (aka "boosts" in SR jargon), because the program will handle them for you (it's its main purpose), but you should know what an inertial reference frame is. The whole point about this software is letting the user see what changes in the representation of reality when moving from a reference frame to another one.

Basic Features

The program is written in Javascript, which is the programming language of web pages, so you don't need to install anything to run it. You just need any modern web browser and you probably already have one installed. However, I developed and mostly tested the program with Firefox, whose Javascript support is excellent, so if you experience problems (such as performance problems) running this software with other browsers you might give Firefox a try. I developed this program for personal computers, with a reasonable screen and a real mouse; I have no idea if this program can be used on a smartphone. I use PCs as computers and phones as phones. If you want to use a phone as a computer, good luck; you are on your own.
For the sake of ease of use, the program is a graphical WYSIWYG editor (What You See Is What You Get), or at least it tries hard to pretend it is (more on the limitations later). The model created by the user can be encoded as an URL, so the user can show his/her model to anybody just sending him/her an URL: just clicking on the link will run the program and have it load the simulation, ready for use.
The simulation is bidimensional, which should be enough for the most complex models.

OVERVIEW

Before getting into details, it is wise to provide an overview of what the program does, how it does it and how to make it to do what you want. Details can wait.

This program lets you do two things: create a model and simulate its behaviour. Creating a model consists in defining bodies (shapes, names, colors, initial velocity vectors) and rules that specify what the bodies should do and when. Simulating its behaviour means that you can play the simulation like a video file, go forward and backward, select a body and use it as a reference frame and see what happens in that frame.

Overview: Program Window

The program window is divided in three parts:

Overview: Bodies and Rules

When you create a model, you create some bodies ans stick some rules to them. In order to create a body:

  1. click or drag into the Plane to define position and dimensions;
  2. click the button "New body"; this creates the body with default properties;
  3. click other buttons in the second button line to change the properties (name, color, initial speed) to suit the model you are thinking of.

It is not necessary to create all bodies at once. You can create some bodies, then define some rules, then create more bodies, then think again and delete some bodies and rules and so on.

Rules are the tough part. Creating rules is the heart of model editing. A rule establishes a cause-effect relationship. If a rule were written as text, it would be in the form:

"In reference frame A, when event B happens, then event C must happen too."

So B is the cause, C is the effect, and A is the context. In order to create a rule, you must define A, B and C:

Overview: Load and Save

In order to manage your models you have five buttons at your disposal, in the first button row:

This is the end of the Overview. Now that you know what you should do, time has come to explain how to do it.

DETAILS

Bodies

The program allows the user to create only two kinds of physical bodies: rectangular and point-like. As of this writing, the program support for rectangular bodies is very limited: such bodies can just move at constant speeds. The user chooses the velocity vector and the body always has that speed for the whole duration of the simulation. The reason for this limitation is that having an extended body change its speed without causing problems (such as breaking apart) in Special Relativity is a complex thing: every point of the body should follow a different complex acceleration scheme. The body is distorted while accelerating and this would be a little nightmare for both drawing it on the screen and computing interactions with other bodies. However, it is just possible that a future release might support rectangular bodies that accelerate.

Point-like bodies are more flexible. They can change their velocity vector (abruptly; smooth acceleration is not supported) any number of times. They can be created (emitted) by other bodies and they can vanish. They can be massless (and hence always move at the speed of light) or not. They can also be multiple, meaning that more than one physical body may be created by a single body definition; as an example, if you create a rule establishing that when body P1 meets body P2, P1 emits body P3, if P1 meets P2 more than once (because one of them changes velocity) more than one body P3 is emitted. The instances of P3 can be distinguished by a low index (P31, P32...). Limits: in order to avoid unreasonable computational burdens, the software imposes a limit to the number of physical bodies that a single definition can spawn: as of this writing, the limit is 20.

In order to create a point-like body, click somewhere in the Plane, then click the "New body" button. You will be asked if the body is massless or not. Click well because you cannot change these settings (position and mass) later. The body coordinates will be rounded to the nearest integer numbers; in other words, do you see that sort of grid in the Plane? Bodies can be created only where the grid wants. Please consider it good news, because it would be difficult to specify exact coordinates if they were not rounded. Anyway, rounding coordinates is also a must for saving characters when encoding the model as an URL. A grid square is 1 light-second large: in the simulation, it takes one second for a body moving at the speed of light to cross a square.

In order to create a rectangular body, do not just "click" on the Plane; perform a drag: press the left mouse button, move the mouse, then release the button. The wider your move, the bigger the body rectangle. More exactly: the body rectangle will be formed by all grid squares that are completely enclosed in the rectangle whose diagonal is marked by the two edges of your drag movement. You will not be asked to specify if the body is massless, because it cannot be.

Technically, when you create a rectangular body, you are internally also creating five point-like bodies, one corresponding to the center of the rectangle and other four at the edges. If you decide to name that body Pippo, its edges by default are named Pippo_A, Pippo_B, Pippo_C, Pippo_D. After creating the rectangle you can click on an edge to select it and then change its name.

When you create a body, the program chooses default values for its name, color and initial speed (velocity vector). You will probably want to change these settings, clicking on the buttons "name", "color" and "speed" in the second button line.

When you create a body this way, you create a body with an infinite past and an infinite future. If you change its speed, you redefine not only its future path but also its past path. The only space-time point in its path that is not affected is its creation point. The creation position is the place in the Plane where you clicked before creating the body; the creation time is the current time shown in the time bar when you created the body. No matter the initial speed that you set, the program makes sure that at the creation time the body passes by its creation position. This is valid only for the initial speed; you might create a speed change rule that changes the body speed so that at the nominal creation time it does not pass by the creation position any more.

There is also another way to create bodies: using an emission rule. Bodies created this way do not have an infinite past and might not have an infinite future. More about it later on.

You can delete the currently selected body clicking on the Delete button. However, if other bodies or rules contain references to the body being deleted, they will have to be deleted as well. If other bodies need to be deleted, you will be warned and asked to confirm the whole operation.

In any case, always remember that you work on body definitions, not on actual bodies. If you select an instance of a multi-instance body and delete it, you actually delete the definition and hence all instances of that body.

When you change the speed of a rectangular body, you'll notice that its shape changes. This is due to the relativistic contraction of lengths. The dimensions of the rectangle that you define with the mouse are always intended as the real dimensions that the body has in its own rest frame.

When you set the initial speed of a body, this setting is always relative to the creation reference frame of the body, which is the reference frame that was currently selected when you created the body (see next section), so pay attention to this setting too before clicking on the "New body" button because you cannot change it after creating the body.

Working in the Plane

In order to select a body (which you need to do to change something about it), you just click on it. However, it often happens that several bodies are very close to one another. If this is the case, don't worry: just go on clicking on the same spot to cycle among all bodies that are there. The empty space is part of the cycle, so if you click on a spot which is already occupied by some body but you actually intend to click on the space itself to create a new body there, just go on clicking until the selection circle is green instead of red: it means that you have selected the underlying empty space.

Scrolling: you can grab and drag the Plane around using the right mouse button. You may find it useful when some body in your model moves out of the visible part of the Plane.

Working with Time and Events

The time bar always shows the time dimension of the current reference frame. You can move to a specific time clicking on the time bar; if you click with the right mouse button, you move to a time which is rounded to the closest second. You can also scroll the bar by dragging it with any mouse button. Now let's focus on the control buttons:

This button goes to time 0:00 and also resets the time bar to its initial position like it had never been dragged.

This button goes to the previous event.

Play backward. If clicked again, increase the speed of backward play (fast backward).

Stop playing. This software does not distinguish between pausing and stopping.

Play forward. If clicked again, increase the play speed (fast forward).

Go to the next event.

Events are shown in the time bar as thin vertical red lines. However, several events may happen at the same time and thus look like one red line. It would be impossible to select a specific event by clicking on it, so the program does not even try supporting selection of events by clicking on them. In order to go to a specific event, always use the dedicated buttons (possibly after having moved to a close time by clicking on the time bar). Selecting an event is important for creating rules. If you create a rule while an event is currently selected, the rule will be triggered by that kind of event. Otherwise, if you create a rule when no event is currently selected, the rule fires at the currently selected time.

Reference Frames

The main purpose of this program is to allow a user to see what changes in the representation of reality when passing from a reference frame to another one. This program only supports inertial reference frames (simply called "reference frames" in the rest of this manual). While the program runs, there is always a currently selected reference frame. All user actions are implicitly relative to that frame. The initial, default reference frame is called "Lab". Although you can create and run your model without leaving the Lab, you will most probably want to switch to other reference frames from time to time.

Any reference frame different from the Lab is defined by a segment. As already explained, a single body definition can correspond to more than one real body. Every real body can change speed more than once. Every section of the universe line of a real body is called "segment"; as an example, if a body changes speed twice, its universe line is composed of three segments. Internally, the program identifies segments using three numbers: the ID of the body definition, the index of the instance and the index of the segment. Any segment can be used as a reference frame. Just select the body (actually, the body instance) and click the button "Use as reference frame": the current segment will become the current reference frame. You will probably see that other bodies in the Plane instantly change their positions and shapes. This is normal. The fact that some things change from a reference frame to another one is the whole point about Einstein's relativity theory. If you then click the Play button, you will also see that the body you selected does not move. That's exactly what you should expect: every body is still relatively to itself. However, if that body changes its speed later on, you will see it beginning to move. This happens because the reference frame is defined by the segment, not by the body, so although the body switches to another segment you still watch it in the reference frame of the previous segment that you selected. The reference frame is inertial and thus can never change its speed.

The current reference frame is shown in the second line after "R. frame:". As already explained, the initial frame is the Lab. If you click on a body and use it as a reference frame, the name of the body will be shown instead of the Lab. If the body has more than one instance, the instance number will be shown as a low index after the name. If the body changes speed at any time during its existence, a segment number will be shown as a high index. For example, Pippo23 means that you selected the third segment of the second instance of Pippo as a reference frame (I seriously doubt that your model will be so complex, but the program must support the most general cases anyway).

Massless bodies move at the speed of light and thus cannot be used as reference frames.

In order to get back to the Lab reference frame, click on some empty spot in the Plane and then click on "Use as reference frame".

Setting Speeds

There are two situations when you set the speed of a body: when you change the current speed (usually the initial one) and when you create a speed change rule (see RULES section). In both cases you'll have to cope with the dreadful Velocity dialog box. It's one of the most complex and error-prone things in the user interface of this software.

In this dialog box there are four fields:

The software uses the speed of light as the speed unit, so a speed is a number from 0 to 1 (from -1 to 1 for rectangular components). The first two fields represent the velocity vector in rectangular coordinates, while the last two fields represent the velocity vector in polar coordinates. You don't need to set all four fields. Actually, you really must not do it. You should set only enough fields to define the velocity vector in an unambiguous way; all other fields should be set to "undefined". Normally, two numbers are enough to define a velocity; in some situations you will just use rectangular coordinates, in other situations you will find the polar representation more comfortable (especially with massless bodies), but more complex situations might occur. The program lets you specify the velocity with the maximum freedom. Just specify any two fields and the program will compute the vector. As an example, you might specify vx and direction. However, if you choose to specify vx and v, the sign of vy cannot be deduced, so you have to specify it (there is a specific option in the drop-down option list). The same happens if you choose to specify vy and v.

If all this still does not sound complex enough, there are also many ways to specify the value of any single field. When you set a field, you don't type a number: you select an option from a list (this is also for saving bits in the URL string). Several different speeds are supported. For each speed value, the list shows the corresponding γ factor that determines the magnitude of relativistic effects (γ=1/sqrt(1-v2/c2)). However, besides options corresponding to speed values, there are also options that allow to specify that the speed, or a specific speed component, should be equal to that of another body. Moreover, when specifying the direction, it is possible to specify that the body should move towards another body, of course taking this other body's speed into consideration so that the two bodies can successfully meet (assuming that the other body does not change its speed).

The speed that you set is always relative to a reference frame. For the initial speed, it is the body creation reference frame; for speed change rules, it is the rule reference frame.

If you make some mistake in setting the velocity, usually defining too many or too few fields, the program usually warns you immediately so you can fix the bad fields, but if you make a more subtle mistake the program realizes it only during the computation stage, well after you confirm the setting closing the dialog box. In this case the program warns you that it could not successfully recompute the model and that it had to undo your last change; you'll have to set the speed all over again. As an example, it may happen when you define rectangular components in such a way that the resulting speed exceeds the speed of light, or when you specify that a body should move towards another body but the former is not fast enough to reach the latter. Please be patient, it takes some time to get used to that awkward speed setting dialog box; only then you'll start appreciating its flexibility.

Rules

It is assumed that you read the overview section about rules and already know what they are and how to create them. Here are more details.

Summarizing what you are expected to have already read, a rule is always in the form: "In reference frame A, when event B happens, then event C must happen too". You create the rule clicking a button in the third row. The button you click specifies event C, while the reference frame A is assumed to be the currently selected reference frame and the trigger event B is the current event selected with the next/previous event buttons of the time control panel. You should already know all this, so now let's focus on the C part of rules. As of this writing, the software supports four types of rules: speed change, emission, vanish, clock.

In order to delete a rule, you should select its event C with the next/previous event buttons and then click the "Delete rule" button. Pay attention: this is different from rule creation. When creating a rule, you must select the trigger event B first, while when deleting a rule you must select the effect event C first. This difference is unfortunate but necessary, because more than one rule can share the same trigger event; only the effect event can unambiguously identify the rule that caused it.

Rule Triggers

When you create a rule, the currently selected event becomes the rule trigger. This means that the rule fires not only when that single event happens, but also when any very similar event happens (this concept of similarity is detailed in the following sections about MATCHING). There are several kinds of triggers. Basically, any event and any time can be used as a trigger for a rule. If this explanation is enough for you, fine! You can skip the rest of this chapter.

Still here? It seems you want more details. Okay, here they are.

The Problems with Simultaneity

Unfortunately, this software has a BIG issue with simultaneity. The concept of simultaneity is fundamental in Relativity. Two events are simultaneous in a given reference frame if they happen at the same time in the time coordinate of that reference frame. It is assumed that the time coordinate is defined using clocks synchronized with Einstein's synchronization scheme. In other words, simultaneity is relative. The same two events can be simultaneous in a reference frame and not simultaneous in another frame. Of course, all this makes sense only if instantaneous communication is not possible. Actually, any communication at speeds exceeding the speed of light must not be possible. This is crucial for the logical and mathematical consistency of Special Relativity.

And here is the problem: this software does support instantaneous communication among distant bodies. I know that it should not because it is physically unfeasible and incompatible with SR, but I had to implement it because it is very handy for building models and also useful for compact encoding of models as URLs. The software supports instantaneous information transfer in several situations:

Somebody will be thinking: "So what? What's the problem?". The problem is that any body or piece of information which is moving at a speed which is greater than c (which is the case of an infinite speed) in a reference frame can be time travelling towards the past in another reference frame. In other words, in order to simulate instantaneous communication in all reference frames correctly, this software actually needs to simulate time travelling communication correctly. In yet other words, the software must support foreseeing the future. This is technically difficult and not even possible in general. The user might easily build a model containing cross references among bodies that create a grandfather paradox and make the model impossible to simulate.

I have been strongly tempted to redesign the software to remove any single instance of instantaneous communication, but I realized that this redesign would have strongly limited the flexibility and ease of use of the software. So I chose the hard way and implemented instantaneous communication somehow. I wrote a complex event resolution engine that tries to solve the system in non-cronological order when necessary. If the user ever creates a paradox, or just a situation which is too difficult for the software to solve, the program automatically rejects the last change made by the user. Sorry.

Instantaneous communication is a problem also for another reason. The purpose of this software is educational, but the mere existence of an instantaneous communication that cannot exist in Relativity goes against this purpose. The risk is that a user might abuse this feature, create strange situations and think that this proves Relativity wrong, while it just proves me fool (yes, I KNOW that I should not have implemented that useful feature). So, let me be very, very clear about this. Instantaneous communication cannot exist in Relativity. All features of this software that imply an instantaneous communication should be considered just a way to simulate an a priori knowledge. As an example, if you build a model where, when remote event A happens, person B does something, it does not mean that B somehow instantly sees event A when it happens. It means only that B knew in advance that event A would have happened, he knew where, how and when it would have happened, and decided to keep an eye on his clock and do something at the same time. That's all. No communication, just information gathered in advance, no matter how.

Reporting Bugs

Bugs? What bugs? There aren't any bugs in this program. It is perfect.
OK, seriously... this program grew much more complex than I would have expected and I did not test it well enough. After all, I wrote it as a hobby. I seriously suspect that it will never be tested well enough, so you (the user) might step into some nasty bug. If it happens, please consider reporting it. Reporting a bug is not very difficult. It basically takes a few easy steps:

  1. When you step into the bug, before doing anything else with the program, save the program's debug log to a file, clicking the button "Save Debug Log".

  2. Write an email explaining what went wrong and why you think that it was wrong, even if you think it is obvious (ex. "The program crashed" or "body P3 is going to the left while it should go to the right"), because 1) I need to know if I have really reproduced the behaviour you saw, and 2) I need to understand if it is a bug or a counterintuitive intended behaviour. Please attach the debug log to the email.

  3. If you like, you may include in the mail an explanation of what you were doing, but it is not important. The log should tell me everything you did to arrive at that anomalous situation. The log includes any editing command you issued to the program. The ClearAll button clears it.

  4. Send the email to me (currently, paolrus (at) libero (dot) it).

If you enabled autosaving, it might happen that the program crashes right after loading the autosaved data. If this happens, the program will probably go on crashing every time you try to run it, leaving you in a seemingly unrecoverable situation. However, since Javascript code is mostly asynchronous, part of the user interface should still work (otherwise, clicking the "Save Debug Log" button would be impossible). You might recover from the freeze just disabling autosaving (thus deleting the autosaved data) and reloading the page. You should better try to save the data to a real file before doing it, because you might be able to reload the saved file after you report the bug to me and I fix it.