Some Special Relativity exercises with rigid objects

I was trying to argue that a few decimals of precison in acceleration would make a big difference in time elapsed. - i.e. you might get 5 seconds or somesuch, rather than 5 days. )
Challenge accepted. I wrote something to compute the time taken to move the object, capping the max acceleration at 1 m/sec², then 10, 100, etc. It output this:
Code:
Mag speed    hours
 0 0.003377 592.328611
 1 0.008869 225.504545
 2 0.013849 144.398106
 3 0.014967 133.605351
 4 0.015094 132.477694
 5 0.015107 132.364400
 6 0.015109 132.353065
 7 0.015109 132.351932
 8 0.015109 132.351818
 9 0.015109 132.351807
10 0.015109 132.351806
First column 'Mag' is magnitude of accleration, so basically 10**n m/sec²
The 2nd line is acceleration of 10 m/sec², or 1g. I stopped at a billion g since the answer converges to 132 hours (5.51 days) at a mere 100g, which took only 1¼ hour longer than far higher accelerations
 
Last edited:
Let's compute it then. RoS computation: t' = Lv where L is 1 and v = 0.866. Here, t' is the time change at what you call the 'launchpad' of the 2nd drone. Pretty impressive for a point-size drone to get one of these.
Anyway, RoS time change at the pad is 0.866, and the drone did its acceleration at time 0.577, so indeed, the 2nd drone is already moving in that frame. All of them are as a matter of fact.
It still isn't Rindler (hyperbolic) motion, but what you say here works.

Yes, it does seem to work. I can't find anything wrong with it, especially in the limit as the density of drones per unit length can approach infinity.

2K1bClj.png


I have added simultaneity lines in orange. The spacing between the drones is indeed 1.000 in the S' frame, the same as it was in the S frame before the acceleration.

Left point:
(x, t) = (2.00000, 1.73205)
x' = γ(x - vt) = 1.000

Right point:
(x, t) = (3.00000, 2.30940)
x' = γ(x - vt) = 2.000

Did you compute how long it takes to move the light-year object this way?

No, I was too busy trying to prove to myself that this solution would not break a string tied between the drones. You are correct that if the string is likewise accelerated, it would be the same as a smaller and more continuous set of drones. There does not seem to be any reason for the string to break, in that case. I can't find anything wrong with it, even though it is not Rindler motion.
 
Exercise P:

Essentially I am working in the frame of the object. I instantly (as measured at the rear-most point) accelerate it to a speed that contracts the tracks enough to include one more station. Then the front of the object is immediately at the destination we want it. Then I bring the object to a halt instantly (as measured at the leading point) which brings the rear (and all the other points between) forward by the same distance, which is a light hour. The time it takes to do this is the same as the relativity of simultaneity difference between the initial inertial frame and the frame with the ship at max speed, which was 0.0151 c.
So consider the event of the rear of the object at the beginning (time 0). In the track frame, the front of the object simultaneious with that event is also at (both train and track) time zero. Relative to the frame moving at 0.0151c, the rear event (time 0) is simultaneous with front event t=5.52 days, which is the event where the front accelerates instantly to the same speed as the track.

I think I understand now why it is important to only use a speed that length-contracts just enough to include one more station, rather than using a higher speed. Looking at it from the track frame, any higher speed would be wasteful, because it would cause too much length contraction of the train, which takes time, and then it has to be un-contracted again at the end, which also takes time.
 
2K1bClj.png


I have added simultaneity lines in orange. The spacing between the drones is indeed 1.000 in the S' frame, the same as it was in the S frame before the acceleration.
Not sure how easy it is to program whatever tool you use to generate that, but it is instructive to do a Lorentz transformation of that picture (all the events) in a frame moving to the right at 0.57735c
That speed is 'half' the speed of 0.866c and makes the speed (but not the velocity) of the object indentical both before and after the acceleration. Thus, in that frame, the coordinate length of the object cannot change due to the delta-V applied to it.
 
Not sure how easy it is to program whatever tool you use to generate that, but it is instructive to do a Lorentz transformation of that picture (all the events) in a frame moving to the right at 0.57735c
That speed is 'half' the speed of 0.866c and makes the speed (but not the velocity) of the object indentical both before and after the acceleration. Thus, in that frame, the coordinate length of the object cannot change due to the delta-V applied to it.

Would that be analogous to me plotting frame S with all the equally-spaced drones first moving v=+0.866c and then all of them simultaneously changing velocity to v=-0.866c keeping the same spacing between them? For some reason that does not seem as instructive as what you describe, probably because the "simultaneously" there is clearly a given, but in what you describe it would be a derived result?
 
Would that be analogous to me plotting frame S with all the equally-spaced drones first moving v=+0.866c and then all of them simultaneously changing velocity to v=-0.866c keeping the same spacing between them?
Analogous, yes. Point is, since the impulse events (the events where the worldlines abruptly change velocity) are space-like separated, so a frame must exist where all those events are simultaneous.

The instructive part seems to be that it doesn't violate rigidity to abruptly change velocity from -v to +v in an instant. But it's pretty easily shown that it cannot be done over a duration, however short. If you did, then during the duration in question, in the frame in which all the velocity changes happen at once, the proper length will be too small. There will be compressive strain on the object, violating the no-strain rule.
 
Analogous, yes. Point is, since the impulse events (the events where the worldlines abruptly change velocity) are space-like separated, so a frame must exist where all those events are simultaneous.

The instructive part seems to be that it doesn't violate rigidity to abruptly change velocity from -v to +v in an instant. But it's pretty easily shown that it cannot be done over a duration, however short. If you did, then during the duration in question, in the frame in which all the velocity changes happen at once, the proper length will be too small. There will be compressive strain on the object, violating the no-strain rule.

Yes, I can see that, using that frame instead of the original S frame. What is strange to me is that, using the original S frame, I would have thought it would have worked over a small but non-zero duration. Hmmm.

I think it is because, unlike Bell's scenario where the string is too short and thus stretches and breaks, we have a string that is too long, and thus becomes slack as it awaits the time when the slack will be taken up. That is still a violation of the no-strain rule for a rigid body. It just has the opposite polarity, and is thus different intuitively.
 
Last edited:
Exercise R: Quarter rotation of a cylinder of radius 1 lt hour

This seems very simple at first, but needs code to simulate.
The idea is that every part of the cylinder moves at light speed (or just short of it if that offends you) at all times. There's no reason to slow down.
The object never folds or gets distorted in any way. We spin it, so the radius decreases temporarily. The smaller the radius, the faster we can spin it.

We start at full radius and immediately accelerate inward, and as the radius drops, the trajectory curves to the side so that the tangential velocity exactly causes the right amount of contraction to keep the object rigid. So if we happen to drop the radius to half, the tangential speed must be 0.866c and the radial component 0.5c. See how it works?

So we rotate the object half way to its objective (1/8th turn in this case) and then immediately reverse the procedure to bring the thing back to a halt at its destination. Deceleration time is, by symmetry, identical to the time to get to the halfway point. The code only simulates to the halfway point. I can show the code if you like. The code can easily be modified to say perform a full turn instead of a quarter turn.

I ran the code, and intervals of 1000th of a time unit seems to work fine. I got the same answer with 100th of a time interval, but it differed in the 5th significant digit.

So it turns out that it takes time 0.749 to get halfway, or 1.498 total. Our tube was a light-hour in radius, so just under 1.5 hours to do it.
Radius drops from 1 to about 0.605 at the tightest. Tangential speed maxes out just shy of 0.8c.

Am I making any invalid assumptions? The only one that bothers me is to zoom in on any particle (say the rightmost) and look at it locally in the inertial frame of the axis. It is moving both tangentially (up) and radially (left), so the particle is moving diagonally to the upper left. The tube in that frame is a vertical line (at the rightmost point of a circle), but how can a vertical line be moving at c to the upper left? The object should be length contracted to zero in that view, which would put the local line of material perpendicular to the line of motion, but it is vertical instead. That disturbs me. Have I made a mistake?
That concern has nothing to do with the code. It is a conceptual thing, why I can or cannot do what I'm describing.
Keep in mind also that nothing is inertial here. Every particle has unbounded proper acceleration at all times, both due to centripetal acceleration and also do to increase in angular acceleration. The line needing to be perpendicular to the motion is true for inertial motion, and the motion of all the particles here is anything but inertial. That's my explanation for the concern expressed. Critique is encouraged.


Exercise Q is turning to a sort of PITA, but I found a way to mathematically describe how to formally make it into a paper wad, quickly rotated. My best score so far is 250 minutes, which sucks. I'm trying to beat 200.
 
Case R, rotation of the cylinder

Nobody has commented. I kind of need a tool that plots out a series of points and connects them, to give a sort of visual of what's going on.
It should take numeric input of some kind (what, a flat file of text numbers? XLS? How would I generate that?) and outputs a picture.
All I have is the raw data, and more points than I care to plot.

The program seems optimal if you forbid any distortion of the object. It is 2D, and folding is distortion. For small rotations, the program seems to generate an optimal solution, but for larger ones (a full rotation say), it starts to curve the wrong way. For small rotations, the curvature of the path is always concave as we accelerate inward and eventually back to the edge. But for larger ones, eventually we get in tight enough that the centripetal acceleration overcomes that curve, meaning we're not taking the shortest path. It means my program (my solution) is wrong, but I cannot find the fault.

Here is the code, but plotting the actual curves would probably aid discussion more than looking at it. It implements my algorithm, but why isn't my algorithm optimal for larger rotations?

Code:
// SR universe.  Natural units
// How long to rotate (through a finite angle) a 2D cylinder of radius 1
// The whole thing is done in polar coordinates
// Usage: caseP nnn   where nnn is a percentage of a full rotation
#include <stdio.h>
#include <math.h>
#define INTERVAL 0.001         // time increment
#define PI 3.14159265          // Full turn
int main(int ac, char **av)
{
   double gammI,               // lorentz factor (inverted)
          speedT, speedR,      // speed tangential, radial
          posT = 0, posR = 1,  // position tangential (radians), radial
          time = 0,
          vt, vr, dt, goal;    // vel, delta tangent pos
   int ix = 0, percent = 25;   // default
   if (ac > 1) {               // If percent arg supplied
      char *p = *++av;
      percent = 0;
      while (*p >= '0' && *p <= '9')
         percent = percent * 10 + *p++ - '0';
   }
   goal = (PI * (double)percent) / 100.;
   while (1) {
      gammI = posR;                          // 1st estimate
      vt = sqrt(1 - gammI * gammI);          // v from contraction
      vr = sqrt(1 - vt * vt);                // vel inward
      gammI = posR - vr * INTERVAL / 2;      // mid-interval radius / gammI
      vt = sqrt(1 - gammI * gammI);          // 2nd estimate, average v
      vr = sqrt(1 - vt * vt);                // avg vel inward
      dt = (INTERVAL * vt) / gammI;          // delta radians
      if (posT + dt > goal) break;
      posT += dt;
      posR -= INTERVAL * vr;
//    printf("G%f t%f r%f T%f R%f\n", gammI, vt, vr, posT, posR);  // debug
      time += INTERVAL;
   }
   double frac = (goal - posT) / dt;
   time += INTERVAL * frac;
   posR += INTERVAL * vr * frac;
   printf("time %f, min radius %f\n", time * 2, posR); // *2 for return trip
   return 0;
}
 
I found a tool to plot the quarter turn case. This is the path of one particle from start to finish, moving at c the whole time.

caseR90.PNG
The outside curve is the stationary quarter of the tube. The lower left is the path taken to move a quarter turn.
The crease in the curve is half way, where we peak our rotation rate and need to start slowing that down.
The solution is almost optimal, but a more optimal one would be a path that a rubber band would follow if wrapped around that shape.
It would mean the tube would not stay taut, but would be slack, wrinkled, anywhere where the rubber band doesn't touch that shape.
The curve starts out at the lower right and curves right at first, but near where it hits that first grid line (I had no control where the tool put those, so no idea why it chose the 4-5 ratio), but the majority of it curves barely to the left, which is suboptimal.
I can plot other curves as well, but this one illustrates all my concerns.
 
Nobody seems to spot problems, but I feel like the curve is wrong. The line departs from the circular border at a perpendicular angle and only slowly gathers lateral motion. In reality, significant speed is needed to result in the first small increments of length contraction. The line still must depart perpendicular at first, but I feel it should must curve to the right much quicker. My program is suspect, and I need to re-check the mathematics of it.
Maybe my intuitions are wrong and the program is doing fine.

Update: I think my fears are unfounded. The mathematics checks out.
 
Last edited:
Note: as per Grøn's Fig. 9. Part C referred to earlier there are only x, y and t dimensions while z = 0 making the wheel effectively rigid.
yW4RstU.png


Grøn's Fig. 9. Part C shows the stationary observer/camera being in the same plane as the wheel i.e. the observer and the entire wheel occupy the same plane so the Observer is stationary and at 0 degrees to the plane of rotation of the wheel.
gKXcTeI.png


Extending the model to all angles of rotation/orbit.

Basic calculations (non relative)


On non relativistic scales the distance between the observer and the models stationary C.O.M, = 2 * Pi * r c/v where r is the radius of rotation/orbit of the 2 sources and v is the angular velocity of the source(s). The time taken for the source to rotate/orbit through one quarter = (2 * Pi * r)/4. This mapping only shows emitted photons that are still in transit at the time the observation is made and, during a period of one complete rotation/orbit, all these currently in transit photons would eventually be observed at the observation point, that stayed stationary relative to the C.O.M.

Basic calculations (relative)

At relativistic scales, and where the observer is at 0 degrees to the plane of rotation of the sources (per Grøn's Fig. 9. Part C solution), there would be maximum length contraction of the 'spoke', that is the point on the wheel's circumference where the source rested on, while it emitted photons. This 'spoke' length contraction would be consistent for wheels/rings rotating/orbiting at the same relativistic velocity when the observer is at different angles to the plane of rotation. The distance doesn't change between the observer and the C.O.M. at the same start point, only the shift changes. The images below show the observer at different angles to the plane of rotation/orbit for sources with the same angular velocity.
fetch
While this diagram
 
Note: as per Grøn's Fig. 9. Part C referred to earlier there are only x, y and t dimensions while z = 0 making the wheel effectively rigid.
The posts and the paper from which all that was taken is interesting, but not particularly relevant. It seems to concern itself with what a series of orbiting lights would look like to some observer moving relative to the center of rotation. There is no mention of angular acceleration in the paper, and this topic (the latter two cases at least) is primarily about acceleration of objects and bringing them back to a halt relative to the original rest frame, all without local strain on the object.
 
The posts and the paper from which all that was taken is interesting, but not particularly relevant. It seems to concern itself with what a series of orbiting lights would look like to some observer moving relative to the center of rotation. There is no mention of angular acceleration in the paper, and this topic (the latter two cases at least) is primarily about acceleration of objects and bringing them back to a halt relative to the original rest frame, all without local strain on the object.

Øyvind Grøn's paper is a compendium of all the different historic approaches to Born rigidity and the Ehrenfest paradox in rotating reference frames. While he didn't publish his workings for Fig 9 Part C “optical appearance” plot (workings shown from a solution from a now defunct website) you can see that the method he used to effectively negate the impacts of Born rigidity is reflected in his conclusions (part 4) and all conclusions are well worth rereading. The observer in Fig 9 Part C was stationary on the 'Road' frame (Part A = Wheel frame and Part B = Axle frame) while the observer was stationary with respect to the center of rotation on the second example shown (Non Grøn basic galaxy model).
4. If the disk is regarded as a 2-dimensional surface it can be put into rotation in a Born rigid way, that is without any displacements in the tangential plane of the disk, by bending for example upwards so that it obtains the shape of a cup.
 
Øyvind Grøn's paper...

LaurieAG, I am so glad to see that you are still hanging about and doing well. I remember when you and I, and some others, were discussing Grøn's paper a long time ago. How time flies!

There is no mention of angular acceleration in the paper, and this topic (the latter two cases at least) is primarily about acceleration of objects and bringing them back to a halt relative to the original rest frame, all without local strain on the object.

Halc, indeed you are correct that the Grøn paper deals with totally different aspects of this. But I believe you have already solved for the optimal acceleration profile for the linear case. If so, then I would think you should be able to simply "wrap" that method around a rolling wheel to get the rotating case. If you have only one contact point, it would require one full rotation to complete. But, depending on your own rules, you might be able to have multiple contact points.
 
Last edited:
I believe you have already solved for the optimal acceleration profile for the linear case. If so, then I would think you should be able to simply "wrap" that method around a rolling wheel to get the rotating case.
For case R (rotation of a 2D disk), I suppose the answer lies in performing linear motion similar to the linear case, reducing the object to one which can be rotated on a different axis. A rigid 3D wheel cannot undergo any angular acceleration at all, so in that sense, the problem is impossible. But my object isn't 3D.

I have found myself somewhat too busy to work on writing the code for this, which probably will remain the case until January.

If you have only one contact point
You seem to misunderstand. There is no rolling going on, no contact with any surface or anything, so no meaningful 'contact points'. Yes, there are lots of examples of rolling on the web, which is just rotation as expressed in a different inertial frame. These examples rarely involve angular acceleration, and if they do, they cannot involve rigid motion.
 
Back
Top