[[I've changed the subject line since this discussion no longer has
anything to do with Hooke's law.]]

In article <vpd0kg$23r6$1@dont-email.me>, Luigi Fortunati writes:

In my animation https://www.geogebra.org/m/rs4cfxzg body A of 5 particles collides inelastically with body B of 3 particles.

Before the collision, the total momentum p=+2 is entirely owned by
body A

This is incorrect: before the collision, *both* bodies have nonzero
momentum (relative to Luigi's inertial reference frame). To be precise,
before the collision we have:
mass: m_A = 5 m_B = 3
velocity: v_A = +1 v_B = -1
momentum: p_A = +5 p_B = -3 p_total = p_A+p_B = +2

After the collision, it is true that the total momentum does not change
(it always remains equal to p=+2), [[...]]

In fact, at the end of the collision, the positive momentum p=+2 belongs "only" in part to body A (p=+1.25) and the rest has transferred to body B (p=+0.75).

This is correct: since momentum is conserved, the total momentum after
the collision is equal to the total momentum before the collision, i.e.,
+2. Since the total mass is m_A+m_B = 8, the common velocity after the collision must be v_A = v_B = 0.25, and thus the two bodies' individual
momenta after the collision must be p_A = +1.25 and p_B = +0.75.

How is it possible that, during the collision, there is a transfer of momentum from body A to body B if the action of body A on body B is
*equal* to the opposite reaction of body B on body A?

The answer is that the momentum transfer during the collision is actually *two-way*, i.e., *each* body transfers some momentum to the other body.
That is, during the collision A's momentum changes (because B transfers
some momentum to A), AND B's momentum changes (because A transfers some momentum to B).

Let's work this out in detail:
Before the collision:
p_A_before = +5
p_B_before = -3
p_total_before = p_A_before+p_B_before = +2
After the collision:
p_A_after = +1.25
p_B_after = +0.75,
p_total_after = p_A_after+p_B_after = +2
Thus, *during* the collision, the bodies momenta change by these amounts:
Delta_p_A = p_A_after-p_A_before = -3.75
Delta_p_B = p_B_after-p_B_before = +3.75
Delta_p_total = Delta_p_A+Delta_p_B = 0

In other words, during the collison B transfers momentum -3.75 to A,
so that A's momentum changes by Delta_p_A=-3.75. AND, during the
collision A transfers momentum +3.75 to B, so that B's momentum changes
by Delta_p_B=+3.75.

And why does this transfer of momentum from A to B not occur in the first three instants and only occurs in instants 4 and 5?

To answer that we need to delve into the detailed internal structure of
each body and the dynamics of the collision. I'll write about that in
a following posting.

--
-- "Jonathan Thornburg [remove -color to reply]" <dr.j.thornburg@gmail-red.com>
(he/him; currently on the west coast of Canada)
"[I'm] Sick of people calling everything in crypto a Ponzi scheme.
Some crypto projects are pump and dump schemes, while others are pyramid
schemes. Others are just standard issue fraud. Others are just middlemen
skimming off the top. Stop glossing over the diversity in the industry."
-- Pat Dennis, 2022-04-25

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <m28047FughsU1@mid.dfncis.de>, I wrote

the momentum transfer during the collision is actually
*two-way*, i.e., *each* body transfers some momentum to the other body.
That is, during the collision A's momentum changes (because B transfers
some momentum to A), AND B's momentum changes (because A transfers some momentum to B).

[[...]]

In other words, during the collison B transfers momentum -3.75 to A,
so that A's momentum changes by Delta_p_A=-3.75. AND, during the
collision A transfers momentum +3.75 to B, so that B's momentum changes
by Delta_p_B=+3.75.

In article <vps7vq$3laqc$1@dont-email.me>, Luigi Fortunati replied

Body B has a momentum -3 and, therefore, cannot transfer -3.75 to body
A because it does not have it.

This is mistaken. (Linear) momentum doesn't have an inherent zero point,
so there's never a case where one body doesn't have enough momentum to
transfer some to another body. Rather, momentum is analogous to position
on a number line, where being at position -3 doesn't prevent you from moving
a distance 3.75 either to the right or to the left.

One way to "see this in action" is to consider what the collision would
look like if analyzed in a different inertial reference frame (IRF). For example, let's consider an IRF which is moving to with a velocity v=-10
(i.e., moving the left at a speed of 10) with respect to Luigi's original
IRF. In this new IRF, each velocity is the velocity in Luigi's original
IRF + 10.

In this new IRF, the speeds and momenta before the collision are
v_A_before = +11 --> p_A_before = +55
v_B_before = +9 --> p_B_before = +27
p_total_before = p_A_before+p_B_before = +82
so that after the collision, the total momentum must also be p=+82. Hence
the common body of mass 8 must be moving at a speed of p/m = +10.25 after
the collision, and A and B's speeds and momenta after the collision must be
v_A_after = +10.25 --> p_A_after = +51.25
v_B_after = +10.25 --> p_B_after = +30.75
p_total_after = p_A_after+p_B_after = +82
The velocity changes during the collision are thyus
Delta_v_A = v_A_after - v_A_before = +10.25 - +11 = -0.75
Delta_v_B = v_B_after - v_B_before = +10.25 - +9 = +1.25
and the momentum changes during the collision are
Delta_p_A = p_A_after-p_A_before = +51.25 - +55 = -3.75
Delta_p_B = p_B_after-p_B_before = +30.75 - +27 = +3.75

Notice how the velocity changes during the collision, AND the momentum
changes and A <--> B transfers during the collision, are exactly the same
as when we analyzed the collision in Luigi's original IRF.

--
-- "Jonathan Thornburg [remove -color to reply]" <dr.j.thornburg@gmail-pink.com>
(he/him; currently on the west coast of Canada)
"[I'm] Sick of people calling everything in crypto a Ponzi scheme.
Some crypto projects are pump and dump schemes, while others are pyramid
schemes. Others are just standard issue fraud. Others are just middlemen
skimming off the top. Stop glossing over the diversity in the industry."
-- Pat Dennis, 2022-04-25

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vpd0kg$23r6$1@dont-email.me>, Luigi Fortunati writes:

In my animation https://www.geogebra.org/m/rs4cfxzg body A of 5 particles collides inelastically with body B of 3 particles.

This animation shows a specific set of motions of the 5 bodies (shown
as spheres), with a specific set of deformations (the spheres overlap)
at various times.

This animation might be what actually happens in an inelastic collision,
or it might not be. How can we find out? That is, how can we apply the
known laws of Newtonian mechanics to work out what happens?

To do this, we need a *quantitative* model of body A and of body B, and
of how they interact during the collison.

Earlier in this thread (article <m1dng8FkasU1@mid.dfncis.de>) I
suggested a model consisting of a set of point particles interconnected
with "springs with friction". That model is reasonable for elastic or partly-elastic collisions, but as we'll see, we need to modify it a bit
to handle fully-inelastic collisions.

An example of a fully-inelastic collision is crunching snowballs
(or lumps of modelling clay) together. Notice that if you compress a
snowball (or a lump of clay), then let go, the snowball (or clay) stays compressed: it doesn't rebound to its original size. In contrast, in
our earlier model the springs can (and would) re-expand after being
compressed.

So, to model a fully-inelastic collision, let's change our model a bit:

We still have a set of point particles (5 for body A, 3 for body B),
equally spaced along a line. But, now the particles are interconnected
with "struts", which behave like springs-with-friction *except* that
they don't re-expand after being compressed. More precisely, if L is
the (time-dependent) current length of a strut, and L_eq is the original equilibrium length of a strut, then

If dL/dt < 0, i.e., if the strut's length is currently decreasing,
then the strut acts like a spring-with-friction, exerting a restoring
force R = -k (L - L_eq) - mu dL/dt, where k is the elastic spring
constant, mu is the spring friction coefficient, and our sign convention
is that R > 0 pushes "outwards" (i.e., tends to increase L).

Otherwise, the strut exerts no restoring force (i.e., R = 0) AND
we reset L_eq to the current value of L.

For example, if we imagine compressing the strut a bit, then removing
the applied compression force, then after we remove the applied
compression force there's no restoring force, so the strut doesn't
re-expand.

The reason we reset L_eq to the current (compressed) L is so that the
system behaves reasonably if there's a further compression. If we didn't
reset L_eq, then even if there were only a very small further compression,
the restoring force R would immediately jump to a large value, which seems physically implausible. By resetting L_eq, we ensure that if there's
only a small further compression, there will only be a small restoring
force R, which seems more reasonable.

We also need to say what happens in our model when a pair of particles
collide (as do A1 and B1 at the very beginning of the collision). A
reasonable answer is to say that the particles then stick together,
moving as a single particle with mass 2. (This means that the system
of equations changes -- there is now one fewer particle, and not all
the particles have the same masses.)

Now we can use Newton's laws to construct a full-fledged dynamical
model of the collision. Each point particle moves according to Newton's
2nd law,
m_i d^2 x_i/dt^2 = F_net_i
where m_i and x_i are the mass and position of particle i, and F_net_i
is the net force acting on particle i, i.e., the algebraic sum of the
restoring force R_left_i from the strut to the left of the particle
(if there is a strut there) and the restoring force R_right_i from
the strut to the right of the particle (if there is a strut there),
F_net_i = R_left_i - R_right_i



So, what happens in the collision? To solve the model numerically and
find out, during the simulation we have to
(a) detect any time(s) at which any strut stops compressing (so that
we can reset L_eq to the current value of L), and
(b) detect any time(s) at which any pair of particles collide (so that
we can replace them by a single particle with their total mass, and
change the system of equations accordingly).

<<begin slight digression on numerical software design>>
The standard design for ODE integration routines (e.g., the Gnu Scientific Library routines I used in the program I posted earlier in this thread)
solves the equations
du(t)/dt = F(t,u(t)) where F is a user-provided subroutine
u(t=0) = u_0 where u_0 are user-provided initial data
where u_0, u(t), and the result of F are all N-dimensional real vectors.
You write code to specify a sequence of "goal" times t_goal (these are
usually just the times at which you want to print the solution), and
for each goal time the ODE integration routines take as many internal
time steps as are needed to advance the solution vector to or beyond
the goal time, then (if the integration actually went beyond the goal
time) time-interpolate to determine the solution vector at the goal time.

This design usually works well, and it's very efficient because it lets
the ODE integration routine figure out the right internal time steps
based on the behavior of the solution.

But for our inelastic-collision problem, the standard design is a bit
clumsy: because we don't know if or when condition (a) and/or (b) might
occur, we have to instead specify each goal time to be only a tiny step
ahead of the current time, so that we can check for (a) and/or (b) before calling the ODE-integration routine again to further advance the solution.
That is, we have to bypass all the fancy "automatically choose the most efficient time step" mechanisms in the ODE integration routine. The
result is extra work for us (the programmer) and a much less efficient
program.

An alternative approach is to use fancier ODE integration software
which can monitor "auxiliary conditions" automatically. That is, ODE integration routines like LSODAR (<https://www.netlib.org/odepack/>) or
its successor SUNDIALS (<https://computing.llnl.gov/projects/sundials/>)
can solve the equations
du(t)/dt = F(t,u(t)) where F is a user-provided subroutine
u(t=0) = u_0 where u_0 are user-provided initial data
where u_0, u(t), and the result of F are all N-dimensional real vectors,
AND they can (optionally) also concurrently monitor a set of M auxiliary functions G(t,u(t)) (where G is a user-provided subroutine returning
an M-dimensional vector), so that if any component of G(t,u(t)) = 0,
then the integration will stop and the ODE integration routine will
report the time and which component of G is zero.

This make it much easier to program our dynamical model, because we can
now easily check for (a) by having one of the components of G be dL/dt,
and we can check for (b) by having one of the components of G be the
distance between an adjacent pair of particles. And, with this type of programming, we can return to specifying only the goal times when we want
to print the solution, and let the ODE integration routine automatically
choose efficient internal step sizes.

So, at the cost of having to use a somewhat more complicated set of
ODE integration software, we get both easier programming *and* a much
more efficient program.
<<end slight digression on numerical software design>>

If I find the time, I'll write a program implementing the above and
post some of the output.

ciao,
--
-- "Jonathan Thornburg [remove -color to reply]" <dr.j.thornburg@gmail-pink.com>
(he/him; currently on the west coast of Canada)
"The ideal subject of totalitarian rule is not the convinced Nazi or
the convinced Communist, but people for whom the distinction between
fact and fiction (i.e., the reality of experience) and the distinction
between true and false (i.e., the standards of thought) no longer exist."
-- Hannah Arendt, The Origins of Totalitarianism

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)