Some Special Relativity exercises with rigid objects

Discussion in 'Physics & Math' started by Halc, Oct 25, 2023.

  1. Halc Registered Senior Member

    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:
    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: Oct 30, 2023
    DaveC426913 likes this.
  2. Google AdSense Guest Advertisement

    to hide all adverts.
  3. Neddy Bate Valued Senior Member

    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.

    Please Register or Log in to view the hidden image!

    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

    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.
  4. Google AdSense Guest Advertisement

    to hide all adverts.
  5. Neddy Bate Valued Senior Member

    Exercise P:

    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.
  6. Google AdSense Guest Advertisement

    to hide all adverts.
  7. Halc Registered Senior Member

    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.
  8. Neddy Bate Valued Senior Member

    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?
  9. Halc Registered Senior Member

    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.
  10. Neddy Bate Valued Senior Member

    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: Oct 31, 2023
  11. Halc Registered Senior Member

    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.
  12. Halc Registered Senior Member

    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?

    // 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;
  13. Halc Registered Senior Member

    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.

    Please Register or Log in to view the hidden image!

    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.
  14. Halc Registered Senior Member

    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: Nov 7, 2023
  15. LaurieAG Registered Senior Member

    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.

    Please Register or Log in to view the hidden image!

    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.

    Please Register or Log in to view the hidden image!

    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.

    Please Register or Log in to view the hidden image!

    While this diagram
  16. LaurieAG Registered Senior Member

  17. Halc Registered Senior Member

    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.
  18. LaurieAG Registered Senior Member

    Ø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).
  19. Neddy Bate Valued Senior Member

    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!

    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: Nov 19, 2023
  20. Halc Registered Senior Member

    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.

    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.

Share This Page