- #1

Freixas

- 307

- 42

- 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'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.

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.

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.