I Gamma - A Minkowski Spacetime Diagram Generator

[Freixas]

Gamma is a Minkowski spacetime diagram generator. I probably started this project in August and have been working on it almost full-time since. It will be a free, open-source application.

• The program can draw all the usual things: axes, grids events, and worldlines, etc.
• It's easy to create observers moving through complex paths that include segments with different accelerations.
• It's also easy to grab the instantaneous moving frame at any point along the path.
• You can animate anything.
• You can add a GUI tool to control values. For instance, you can use a slider to change the velocity of an observer or a toggle to turn things on an off (like the grid). You can do this while an animation is running.
• You specify a problem with respect to a rest frame, but draw it with respect to any other inertial frame. This inertial frame can change throughout the animation, making it possible to view things from the point of view of an accelerated observer.

I don't really know if it has any appeal to the members of this august group. I am looking for feedback from physicists, so if you are willing to check it out, let me know. It's not yet ready for distribution, but I can let you know when it becomes available.

I've posted a preview of the application on YouTube. For some of you,the language I use in the video will not meet your high standards; please ignore my errors and focus on the application. The diagrams it draws look correct to me; let me know if you see a problem.

---

Gamma can be used to create spacetime diagrams; whether the diagrams are correct is another matter—garbage in, garbage out. But this could be a problem with the diagram, not with Gamma, the diagram generator. I've tried to base Gamma on formulas developed by physicists, but have included some of my own algorithms.

What follows is an overview of the formulas and methods I use. I would be very interested in any problems you see at this level.

$c$ is always 1.

I use the Lorentz transformations, of course.

For acceleration, I use the formulas given by Phil Gibbs here: https://math.ucr.edu/home/baez/physics/Relativity/SR/Rocket/rocket.html. I have generalized the formulas:

• $-t$ values are allowed. This means that $x$ cannot be used to generate a unique point on the acceleration curve. Any $x$ value can identify 0, 1, or 2 points on the curve.
• I've introduced a new value, $d$ (distance), defined this way: $t < 0, d = -|x|, t \geq 0, d = |x|$. Every $d$ value identifies a unique point on the full acceleration curve. $d$ is further generalized so that $d = 0$ can bet set to be any point on the curve. If we measure $d$ from one point on the curve to another and the segment crosses the vertex, the total relative distance will be the distance from the first point to the vertex plus the distance from the vertex to the second point. Therefore, $|d|$ for any point is the distance traveled from whatever point is set to be the 0 point
• The vertex of the acceleration, which is normally at $(0, 0)$ can be offset to anywhere.

An observer's worldline consists of a series of segments with a constant acceleration (which can be 0). The segments are "glued" together, so that the next segment starts with the ending segment's final $x$, $t$, $v$, $d$, and $\tau$ (observer time) values.

The Gibbs' equations allow calculating one type of value from another. I have generalized this to work with a worldline consisting of multiple segments. I do this by searching segments, from earliest to latest, and returning the earliest matching value (if any). There are ways to get further matches.

A new segment can receive a velocity set by the user rather than using the final velocity of the prior segment. These worldlines are unphysical, but many common spacetime diagrams have these instantaneous velocity changes. My software treats each worldline as including the first, but not the last point, so that each point has a unique associated inertial frame.

The $x$ axis angle is: $\theta = atan(v)$. The $t$ axis angle is a reflection of this angle around 45° (if $\theta$ is positive) or -45° (if $\theta$ is negative).

Given a unit length $u$, tick marks are spaced $u (\sqrt{1 + v^2} / \sqrt{1 - v^2} )$

To calculate the instantaneous moving frame's axes at a point on the worldline, I use the velocity at the point to calculate the angle of the $t$ axis. The angle and the point define a line. Knowing $\tau$ and the axis scaling, I calculate the $\tau = 0$ location. The $x$ axis goes through that point.

For the hypergrid, I use the Gibb's acceleration formulas with the vertices placed on the $x$ axis, and the acceleration set to $1/x$ (with $x \ne 0$, obviously). For hypergrid lines in the upper/lower quadrants, I just mirror the $x$ versions appropriately.

The diagram is specified relative to a rest frame, but it can be drawn relative to any frame. This requires transforming points, angles, and velocities:

• Points are transformed using the Lorentz equations, of course.
• Velocities are transformed using this formula $(u - v)/ (1 - uv)$, where $u$ is a velocity relative to the rest frame and $v$ is the velocity of the inertial frame used for drawing (this velocity is also relative to the rest frame).
• Angles are converted by first converting them to velocities, converting the velocities as above, and then converting the velocity back to an angle.

There is more math, of course. For example, I can intersect lines with other lines and with worldlines. I don't currently have a good algorithm for intersecting two hyperbolas, so I can't intersect worldlines.

I've tested a lot of this math by simply animating or manipulating the diagram. For example, if I change the drawing frame and use the wrong formulas, the diagrams would probably fall apart. Intersections can be checked by placing an event on the intersection and visually confirming that the position is correct.

 

[PeterDonis]

The diagrams it draws look correct to me; let me know if you see a problem.

A much better way of testing would be to give other people a way to run the program for themselves. It's really hard to tell whether your code is correct from only a small number of examples.

 

[Freixas]

A much better way of testing would be to give other people a way to run the program for themselves. It's really hard to tell whether your code is correct from only a small number of examples.

Of course, Peter. The video is just so people can decide if this is something that interests them. If you're interested, in testing it let me know.

My comment was in case someone saw something in the video that was obviously wrong.

 

[PeterDonis]

If you're interested, in testing it let me know.

I would be interested in testing it, yes.

 

[Freixas]

I would be interested in testing it, yes.

Thanks, Peter. I'd prefer to handle the alpha reviewers by email, if possible. There's a contact email at the end of my video. Would you be willing to use that address to send me your email? I could use the PM system here, but it would be awkward to manage a group of reviewers that way.

 

[PeterDonis]

I could use the PM system here, but it would be awkward to manage a group of reviewers that way.

I'll PM you my email address so you can send me info that way.