Simulation of Elastic Collisions

[MatinSAR]

Do you understand how to do that?

I'm having trouble understanding how to use those equations to determine the four unknowns (two angles and two speeds). IMO we need to measure at least one angle in the lab to be able to calculate the magnitudes of the velocities after the collision.

For example, the equation above don't provide any information about the velocities post-collision because we don't know the angles $\theta_{1,f}$ and $\theta_{2,f}$ and we do not know $v_{1,f}$.

Edit: By reviewing the equations in post #4, I am now 90% sure that I cannot use the equations from that link-15.6: Two Dimensional Elastic Collisions- in my code...

We need to measure one of the angles in the lab frame. Don't you agree, @haruspex?

 

[kuruman]

Isn't it difficult to predict when they will collide? Each particle has the chance to collide with every other particle.

In such problems, one disc is modeled as a point disc and the other a disc of radius $2R$. The momentum and energy transfer are the same. See figure below.

You don't need to know well in advance when two particles will collide. You need to know whether they will collide in the next interval $\Delta t$. To figure that out, first you calculate where they will be if their velocities were the same between $t=t_n$ and $t=t_n+\Delta t$. If it turns out that the point disc is inside the other, $(|\mathbf r_2-\mathbf r_1|<2R)$, then you conclude that the collision (assumed instantaneous) will be completed within the interval $\Delta t$ therefore you must discontinuously change the velocities before the collision to the velocities after the collision as described in post #16. You know where each particle is because you have to tell the machine to put it there after each$\Delta r$. Before you do that, you test if the new positions imply that one disc is inside the other. If it turns out that this will the case, you keep the positions the same and change the velocities before the collision happens. The figure below shows what I mean. The "Before" figure on the left and the "Accepted" figure on the right can be considered as two consecutive frames in the simulation.

In my code, I assumed all collisions to be head-on, meaning the only direction in which the velocity could change was along the line connecting the colliding particles. This simplification leads to equations similar to those found in this link:
15.4: One-Dimensional Collisions Between Two Objects

Is this approach to simulation incorrect?

You can use the equations in that reference (they are the same as the ones in the hyperphysics link I gave you) but you have to understand that subscript $x$ in them is the same as subscript $\parallel$ in post #16. The scattering angles are not needed if you choose to adopt my method for the simulation, which you don't have to do. I am just pointing out how approached such simulations in the past.

 

[MatinSAR]

You can use the equations in that reference (they are the same as the ones in the hyperphysics link I gave you) but you have to understand that subscript $x$ in them is the same as subscript $\parallel$ in post #16. The scattering angles are not needed if you choose to adopt my method for the simulation, which you don't have to do. I am just pointing out how approached such simulations in the past.

Thanks for the clarification with the algorithm. The current problem is related to the physics of the problem. I'm not sure if considering head-on collisions is a good simplification or not, as it makes the final velocity equations after collision too simple.


The most important lesson for me here is:
The cost of choosing a project topic later than other students is that you'll end up with the most difficult one. I'm really glad I didn't accept the professor's offer to enter the rotation in simulation.

 

[MatinSAR]

I appreciate your help, but I think considering head-on collisions is enough for my project. Thank you, @haruspex and @kuruman, for your time and assistance.

 

[haruspex]

In my code, I assumed all collisions to be head-on, meaning the only direction in which the velocity could change was along the line connecting the colliding particles.

The velocities only change along the direction of the line joining the mass centres, whether head-on or oblique. @kuruman explained that in post #16. The process is:

• calculate the direction of that line
• resolve the velocities into coordinates parallel to and normal to that line
• convert velocities along the line into being relative to one of the discs
• compute the new velocities along that line
• convert back to the lab frame
• take the velocities normal to the line of centres to be unchanged
• resolve the velocities back into your standard xy coordinates

You also need to watch out for overflow when doing divisions or using the tan function. E.g. when coding the use of a division you will need to think about the physical meaning of the denominator being extremely small. Is it possible? Is there a way to cope with it?
E.g. if the library arctan function is of the form
double arctan(double ratio)
then calling it as arctan(y/x) might blow up in the division.
A solution would be to front-end it with a dyadic version, solving the arctan ambiguity at the same time. The library function would always return a value in the range $(-\pi/2, +\pi/2)$. I think this is right:

double arctan(double x, double y) {
if (abs(x) < MinInvertible) {
if (y > 0) return Pi/2;
return -Pi/2;
}
if (y > 0) return arctan(y/x);
return arctan(y/x) + Pi;
}

But maybe the library already has a dyadic version.

An interesting sanity check you can do is to keep track of the total KE. Because of rounding errors it won't be constant, but it should only drift slowly. If it drifts persistently up or down then you could artificially tweak all the velocities to keep it in bounds.
(This is trickier in simulations involving other energy modes, such as PE, or other conservations, such as momentum. What should be tweaked?)

 

[MatinSAR]

• calculate the direction of that line
• resolve the velocities into coordinates parallel to and normal to that line
• convert velocities along the line into being relative to one of the discs
• compute the new velocities along that line
• convert back to the lab frame
• take the velocities normal to the line of centres to be unchanged
• resolve the velocities back into your standard xy coordinates

This is what I did except that I did not use relative velocity.

Spoiler: My code.

function update_velocities!(vx1, vy1, vx2, vy2, x1, y1, x2, y2, r1, r2, m1, m2)
    # Relative position
    Δx = x2 - x1
    Δy = y2 - y1
    distance = sqrt(Δx^2 + Δy^2)
    
    # Normal vector (unit vector from particle 1 to 2)
    nx = Δx / distance
    ny = Δy / distance

    # Tangent vector (perpendicular to the normal vector)
    tx = -ny
    ty = nx

    # Dot products with normal vector
    vn1 = vx1 * nx + vy1 * ny
    vn2 = vx2 * nx + vy2 * ny

    # Dot products with tangent vector (remain unchanged)
    vt1 = vx1 * tx + vy1 * ty
    vt2 = vx2 * tx + vy2 * ty

    # Update normal components based on elastic collision principles
    new_vn1 = (vn1 * (m1 - m2) + 2 * m2 * vn2) / (m1 + m2)
    new_vn2 = (vn2 * (m2 - m1) + 2 * m1 * vn1) / (m1 + m2)

    # Update velocities
    vx1_new = tx * vt1 + nx * new_vn1
    vy1_new = ty * vt1 + ny * new_vn1
    vx2_new = tx * vt2 + nx * new_vn2
    vy2_new = ty * vt2 + ny * new_vn2

    return vx1_new, vy1_new, vx2_new, vy2_new
end

I wanted to consider a situation where the velocity changes in both directions, even perpendicular to the line connecting the centers of mass of two objects.

But as I mentioned in post #34, I regret it, and it's a waste of time in my opinion.

You also need to watch out for overflow when doing divisions or using the tan function. E.g. when coding the use of a division you will need to think about the physical meaning of the denominator being extremely small.

I can't see how it might happen in my code.

 

[haruspex]

This is what I did except that I did not use relative velocity.

Your code looks good.

I wanted to consider a situation where the velocity changes in both directions, even perpendicular to the line connecting the centers of mass of two objects.
View attachment 355380

There is no such situation. On what basis would you decide those velocity changes?
I believe the diagram you posted is merely a simplified version, not showing the line of centres at impact (which must have been parallel to $v_{2,f}$).
See the diagrams at https://www.physicsforums.com/threads/how-does-elastic-collision-angle-relate-to-mass-ratios.983227/.

 

[MatinSAR]

Output of my work as a GIF: (this is the 1st version)

 

[MatinSAR]

On what basis would you decide those velocity changes?

I believed that, in general, the force exerted on particle 2 by particle 1 is not aligned with the line connecting their centers. But it is, yes?

There is no such situation. On what basis would you decide those velocity changes?
I believe the diagram you posted is merely a simplified version, not showing the line of centres at impact (which must have been parallel to $v_{2,f}$).
See the diagrams at https://www.physicsforums.com/threads/how-does-elastic-collision-angle-relate-to-mass-ratios.983227/.

It seems I misunderstood this concept. I'll need to go over the chapter on collisions again, more carefully.

 

[haruspex]

I believed that, in general, the force exerted on particle 2 by particle 1 is not aligned with the line connecting their centers. But it is, yes?

In the idealisation of uniform spheres, no friction, it will be aligned with the line of centres.

 

[haruspex]

Output of my work as a GIF: (this is the 1st version)

View attachment 355387

Excellent!

 

[MatinSAR]

In the idealisation of uniform spheres, no friction, it will be aligned with the line of centres.

I understand.

Excellent!

Thank you for your help. It has been very helpful.