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
Newton e Hooke
Re: Newton e Hooke