Balls merge at slow/high speeds with inelastic collisions

Question

Balls merge at slow/high speeds with inelastic collisions

Closed this issue 4 years ago · 19 comments

Test device
MacBook Pro

Operating System
Catalina 10.15.1

Browser
Safari

Problem description
This is for phetsims/qa#562
At both slow and high speeds with inelastic collisions, some of the balls will merge. In addition, after changing the initial state of the simulation with the balls still merged, the reset button (not reset-all button) will not "un-merge" the balls. However, the balls do become un-merged once the reset-all button is pressed.

Steps to reproduce

Open the simulation
Click on the Explore 1D section of the simulation
Start off with two balls and start the simulation
Add the additional balls to get a total of four balls and allow them to interact
Wait for some of the balls to get going in the same direction and then turn on inelastic collisions to the max
Wait for the balls to all collide and if done correctly observe how 1 or more of the balls merge

NOTE: If you need help reproducing the bug, feel free to message me on Slack

Visuals
https://drive.google.com/file/d/1fhDVRmawgrr1xX3k6on_TyQMlsxueTCB/view?usp=sharing

Troubleshooting information:
!!!!! DO NOT EDIT !!!!!
Name: ‪Collision Lab‬
URL: https://phet-dev.colorado.edu/html/collision-lab/1.1.0-dev.10/phet/collision-lab_all_phet.html
Version: 1.1.0-dev.10 2020-10-15 01:57:00 UTC
Features missing: touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Safari/605.1.15
Language: en-US
Window: 1260x720
Pixel Ratio: 2/1
WebGL: WebGL 1.0
GLSL: WebGL GLSL ES 1.0 (1.20)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 15 uniform: 1024
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 16)
Max viewport: 8192x8192
OES_texture_float: true
Dependencies JSON: {}

Answer 1 · 2020-11-18T21:07:53.000Z

Reproducing ball states:

  new BallState( new Vector2( -1, 0 ), new Vector2( 1.22, 0 ), 0.5 ),
  new BallState( new Vector2( -0.35, 0 ), new Vector2( 0.45, 0 ), 1.5 ),
  new BallState( new Vector2( 0.2, 0 ), new Vector2( 0.14, 0 ), 1 ),
  new BallState( new Vector2( 0.9, 0 ), new Vector2( 1.10, 0 ), 1 )

Answer 2 · 2020-12-09T01:51:38.000Z

There are a whole lot of numeric precision issues here, where what is effectively happening is when the first 3 collide, it goes through a number of iterations that set the velocity of 2 balls at a time to be the same. This would converge at the correct value, but we cut off the number of iterations. The ball on the left ends up with a slightly higher velocity, and thus passes INTO the other ball imperceptibly as the 3 go to the right.

I've sunk a lot of time into trying to figure out a good way to solve this that works with the existing code and setup, and I have some general ideas but they would be fairly intensive to implement and maintain.

@arouinfar and @ariel-phet, is the 100% inelastic setup on the Explore 1D screen important, AND is this buggy case important enough to solve for the first publication?

Answer 3 · 2020-12-10T03:03:26.000Z

@jonathanolson I played around for awhile and I can reproduce this buggy situation pretty easily. I found a more "minimum reproducible case:

Go to Explore 1d screen
Set balls to 3
Set the elasticity slider to 0%
Set the velocity of ball one to be to the right and reasonably sized (0.5 to 2 m/s appears to work)
Set ball 2 and 3 to zero velocity
Run the experiment (play button) - the balls reliably merge

I would like to discuss with you as I have a few thoughts. The 100% inelastic maybe not be necessary on this screen (but it would be nice). If there is not a simple solution, it would probably be reasonable to have this screen act like the explore 2D screen and have elasticity limited to 5%.

Answer 4 · 2020-12-10T03:22:17.000Z

Discussed a solution where on this screen ONLY, it will inspect on collisions to determine all "connected" balls, and will use the combined momentum to determine the group velocity.

Answer 5 · 2020-12-10T04:55:00.000Z

I believe this should be patched with the above commit. @ariel-phet can you give it a try?

Answer 6 · 2020-12-10T16:57:09.000Z

@jonathanolson this solution seems to be working quite well! Closing

Answer 7 · 2021-02-26T22:40:30.000Z

I'm still seeing this behaviour in 1.1.0-rc.3 on the Exlpore 1D screen under the following conditions:

5 balls
Elasticity at 5% (5% is important!)
Then these initial values:

Constant Size didn't seem to matter. When running this experiment, Balls 3 & 5 overlap for me.

Seen on Win 10 Chrome. For phetsims/qa/issues/615.

Troubleshooting Information

URL: https://phet-dev.colorado.edu/html/collision-lab/1.1.0-rc.3/phet/collision-lab_all_phet.html
Version: 1.1.0-rc.3 2021-02-24 17:20:08 UTC
Features missing: applicationcache, applicationcache, touch
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.182 Safari/537.36
Language: en-US
Window: 1920x937
Pixel Ratio: 1/1
WebGL: WebGL 1.0 (OpenGL ES 2.0 Chromium)
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 30 uniform: 4096
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 32767x32767
OES_texture_float: true

Answer 8 · 2021-02-26T23:51:54.000Z

CollisionLabClip.mp4

Answer 9 · 2021-02-26T23:52:35.000Z

@arouinfar and I looked at this, and yes, hoping this can be fixed @jonathanolson. Do you have ideas?

Nice catch Steele!

Answer 10 · 2021-03-01T18:45:24.000Z

Great catch!

Answer 11 · 2021-03-01T22:51:06.000Z

I encountered this again in the wild with a different set up, and moving the balls around a bit still allowed it to occur, so it may be more general and/or reproducible.

Image.from.iOS.MOV

Answer 12 · 2021-03-01T23:47:55.000Z

Saw an instance on 2D screen

Image.from.iOS.1.MOV

Answer 13 · 2021-03-03T22:50:37.000Z

I think I've adjusted the thresholds to a sufficient level in both master and the 1.1 branch. It's tricky trying to find the right level, or other bad behavior could occur.

@KatieWoe and @phet-steele, are you able to test in master to see if this seems resolved? If so, I'll probably need to ask for some more physics testing, as this could potentially trigger issues with more parallel-moving balls.

Answer 14 · 2021-03-04T17:02:38.000Z

Once this is verified in master, I'll create an RC for the spot-check.

Answer 15 · 2021-03-04T23:18:15.000Z

The above buggy behaviors looked fixed on master, but beyond that I am in no way comfortable signing off on this when it may need "more physics testing". I did mess around with it for about 1.25 hours now, and I didn't see any merging balls.

Answer 16 · 2021-03-04T23:21:36.000Z

Sounds best then if I create an RC for spot-checking (both this, and ensuring that it doesn't cause other physics issues?)

Answer 17 · 2021-03-04T23:35:44.000Z

Yeah, a strong focus on physics for this one is a good idea. We've been keeping an eye on it, but as this shows there are so many set ups that something can still slip by.

Answer 18 · 2021-03-04T23:43:16.000Z

Sounds good. RC up at phetsims/qa#620.

Answer 19 · 2021-03-11T16:44:27.000Z

Does seem fixed in rc.4.