Mass position may be incorrect when amplitude is increased while sim is paused

[Nancy-Salpepi]

Test device MacBook Air (m1 chip)

Operating System 12.0.1

Browser Safari 15

Problem description https://github.com/phetsims/qa/issues/733

Sometimes when the sim is paused and amplitude values are changed, the positions of the masses don't accurately reflect that change.

Steps to reproduce This behavior is very inconsistent, but here are some steps that have worked for me:

1. Open the One Dimension Screen
2. Increase the number of masses to 6
3. Press the pause button
4. Move the slider for the 6th normal mode all the way up--the position of the masses barely changes. If you did not get this result, press the 'Reset All' button and follow the same steps again.
5. Step forward a little and then press the 'Initial Positions' button. The initial positions are now correct for that amplitude value.

Visuals

I do not see this behavior in the flash version

Troubleshooting information: !!!!! DO NOT EDIT !!!!! Name: ‪Normal Modes‬ URL: https://phet-dev.colorado.edu/html/normal-modes/1.0.0-rc.1/phet/normal-modes_all_phet.html Version: 1.0.0-rc.1 2021-11-03 19:33:33 UTC Features missing: touch Flags: pixelRatioScaling User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Safari/605.1.15 Language: en-US Window: 1427x698 Pixel Ratio: 2/1 WebGL: WebGL 1.0 GLSL: WebGL GLSL ES 1.0 (1.0) Vendor: WebKit (WebKit WebGL) Vertex: attribs: 16 varying: 30 uniform: 1024 Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32) Max viewport: 16384x16384 OES_texture_float: true Dependencies JSON: {}

[pixelzoom]

Reproduced in master.

Notes to self: Pressing the "Initial Positions" button calls setExactPositions, which is implemented separately by OneDimensionModel and TwoDimensionsModel.

[pixelzoom]

Here's another easier way to reproduce:

1. Start the sim, go to One Dimension screen
2. Pause the sim
3. Set amplitude slider for Normal Mode 3 to its maximum. Doing this 5 times, I got 5 very different results, all of them incorrect. Ther first result is close, but still a little off. Very odd that there is a different result each time.

4. Press the "Initial Positions" button to see the correct result. The is the same every time.

5. Press "Zero Positions" button.
6. Set amplitude slider for Normal Mode 3 to its maximum. This will now show the correct result. Verify by pressing "Initial Positions" button.

[pixelzoom]

After poking around in OneDimensionModel, I now understand what's going on here.

When you pause the sim in step 2 above, you do so at some time t. That t is not zero, and is used in the computation of the "waveform" by setExactPositions. Each time I paused the sim, I was doing so at a different t. So that's why there are different results for step 3 above - the waveform depends on what value of t is being used. If you want the waveform to be identical to "Initial Positions", then t must be zero (or a positive integer multiple of the waveform's period).

Some options:

(1) Do nothing. (2) If any Amplitude slider is changed while the sim is paused, reset t to zero. This could be confusing because the waveform change will be based on all sliders, not just the one that the user is moving.

My recommendation is (1).

@arouinfar How would you like to proceed for the prototype, and for the final version?

[arouinfar]

@pixelzoom I think (1) is fine for the purposes of the prototype.

I would prefer (2) in the final version of the simulation. Generally, people are likely to pause the simulation to set up a new initial condition. That could involve adjusting mode sliders and/or displacing the masses. Once the sim is playing, I would expect "initial positions" to return the sim to the state it was in just before pressing play. That also means that if I pause the sim and then move some sliders or masses around, hitting "initial positions" wouldn't appear to do anything because the sim is overriding the latest state as the new "initial positions".

[pixelzoom]

Unassigning and deferring, since this will not be addressed for the prototype.