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.
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.
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.
The program window is divided in three parts:
When you create a model, you create some bodies ans stick some rules to them. In order to create a body:
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:
In order to manage your models you have five buttons at your disposal, in the first button row:
Save: as you might expect, this button saves your work to a local file on your computer. Well, since this software is a web page and for security reasons web pages are not allowed to access the user's filesystem directly, the Save button actually triggers a download. It is actually a dummy download, since the file contents come from the local memory of your computer, not from a web server, but it does not matter: web browsers handle these operations as real downloads. Depending on how you configured your web browser, it might either open a window asking you to choose a name and a destination directory for the file, or silently save the file into a directory named "Downloads" with its default name (LTS_File.html) without asking you anything. The suggested file name extension is .html; you should not change it if you expect the software to be automatically launched when you double-click on the saved file.
Open: this button loads a file saved with Save.
AutoSave: since Javascript makes normal file saving such a nuisance, you can also enable autosaving your work to a file handled by the web browser. Since this browser-managed file space is separated from the rest of the filesystem, security is not a problem and the software can save to this file at will. After you enable autosaving, your work will be saved automatically after every change you make. You can close the browser window, launch the software again and it will automatically reload your work. If you then deselect autosaving, the saved file will be deleted. Remember: Save and AutoSave are completely independent from each other. They don't (and cannot) save to the same file.
URL: this URL encodes your work. You can manually copy it and send it to somebody else.
Clear all: this button deletes everything (every body and rule you defined). Many programs call this functionality "New", but I thought that such a destructive command needed a more descriptive name.
This is the end of the Overview. Now that you know what you should do, time has come to explain how to do it.
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.
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.
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.
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".
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.
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.
EMISSION. An emission rule makes a body to emit a new body. The emitted body is always point-like and is typically intended to represent a signal; you will probably want to make it massless so that it moves at the speed of light, but the program leaves this choice to you. After creating the rule, you will probably want to select the emitted body and change its name, color and initial speed. Since this is usually the case, the software automatically selects the just created body. Limits: as already written in a previous chapter, the maximum number of bodies that a single rule can spawn is limited to 20.
VANISH. A vanish rule simply states that the body must vanish. This is useful for signals. Only bodies that have been emitted by an emission rule can vanish; bodies created with the New body button cannot.
CLOCK. Every body has a "clock", which actually works like a stopwatch. A rule can start or stop the clock. The same rule starts the clock if it is not running or stops it if it is already running. Every clock is initially not running by default. Once a clock starts, its value becomes visible as text between the control buttons and the Plane. When a clock stops, the time it shows gets frozen. If and when it is started again, the time restarts from zero, but the last frozen value is shown as well.
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.
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.
TIME. When you click on the time bar or the Stop play button, you implicitly select a time. If you then create a rule, that time becomes a time event. The spatial position of the event is the current position of the currently selected body. This position is not memorized; the program memorizes the time, which is always rounded to a 1/64th of a second, and the body identifier. The time event that you just created becomes visible as a red line in the time bar and can be selected using the next/previous event buttons. MATCHING: The time trigger is instance-specific: for multi-instance bodies, the rule fires only when that specific instance of the body reaches the given time. Other instances of the same body are undisturbed.
COLLISION. The software automatically detects collisions among bodies and generates collision events. MATCHING: It depends. If bodies A and B collide, and you use this collision as a trigger in a rule affecting body C, then the software does not care about instance numbers: a collision between any instance of A and any instance of B triggers the rule for all instances of C. But if you use the A-B collision as a trigger in a rule affecting - say - B, things are slightly different: whenever any instance of A collides with any instance of B, the rule affects only the single instance of B that just collided with A. Other instances of B will be affected if and when they will collide with some A.
CHANGE. When a new segment is added to the universe line of a body, this is a change event. This happens not only when a speed change rule fires, but also when a body is emitted or vanishes. When the user selects a change event, the software shows it in more descriptive words than just "change", but internally all these kinds of events are considered minor variations of the same thing. MATCHING: although it may sound strange, change triggers match body IDs and segment numbers, but not instance numbers. For example, if you create a rule when body A2 changes speed for the second time (so when segment A23 is created), the rule fires when any Ai3 is created (such as A13 or A43). This is useful. A prior version matched instance numbers too, but during testing it came out that it was more desirable not to do it.
CLOCK. When a clock starts or stops, this is an event that - like any event - can be used as a trigger. MATCHING: like change events, clock start/stop triggers match body IDs but not instance numbers.
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.
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:
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".
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.
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.
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.