Increase lattice size

[samreid]

In #314 we decided to increase the lattice size to 201x201. We'll keep the same padding areas (20+20x20+20), I suspect. We'll need to make this core change and recalibrate the model. Regarding timing and priority, on Slack, I said:

It’s trivial to change the lattice size for performance feasibility testing, but to make it production-worthy, will take some time to recalibrate several parts of the model. I’ve never done this and don’t know exactly how long it would take. I’m guessing 2-10 hours? But that is a wild guess.

@ariel-phet replied:

@samreid should make top priority recalibrating the model, and then we can move to dev.2 test

[samreid]

iPad Air drops to 40 FPS on Interference screen, showing waves and particles, showing graph and with the wave detector in the wave area. But with the EventTimer, the physics is preserved. Still seems responsive enough to move forward (in my opinion).

[samreid]

With a lattice size of 201, the simplest way to recalibrate the physics was to increase the EVENT_RATE by the corresponding dimension of the visible part of the lattice, which was ( WaveInterferenceQueryParameters.latticeSize - LATTICE_PADDING * 2 ) / ( 101 - 20 * 2 ). However, at this rate, the iPad Air drops to 15 frames per second. Maybe (a) this is acceptable, or (b) we need a different way to recalibrate-- though the increased EVENT_RATE looks great on desktop or (c) we could choose an intermediate lattice size.

[samreid]

Regarding the preceding comment, using the simplest calibration via changing the EVENT_RATE, I measured performance on Interference Screen, Sound Scene, timer on, wave detector on, "Both" displayed and both sources on, for iPad Air.

201: 8 fps (questionable) (EVENT_RATE 52)
101: 42 fps (EVENT_RATE 20)
151: 19 fps (looks OK in my opinion) (EVENT_RATE 36)

I'm inclined to check with @jonathanolson about whether I should be changing EVENT_RATE or some other parameter.

[samreid]

In discussion with @jonathanolson we confirmed that an increase in lattice size must be met with a corresponding increase in number of steps (so the wave speed and frequency will remain the same).

[samreid]

@arouinfar and I decided to commit 151 as the default and test that on Chromebooks now that it has the corresponding change in EVENT_RATE.

[samreid]

In the above commits, I calibrated the water wave speed and the time scale for sound and light. Sound and light were measured to have proper frequency, wavelength and wave speed. For the water wave, we choose the time scale to match wall time and measure the empirical wave speed and wavelengths.

[arouinfar]

@samreid I took master for a test drive on iPad Air (iOS 11.4) and Chromebook, focusing on the worst-case scenario described in #315 (comment) (but with the graph also on). I also spent a fair amount of time with light with Screen/Intensity on.

Interference Screen, Sound Scene, timer on, wave detector on, "Both" displayed and both sources on

On the iPad Air, I generally observed 12-16 FPS. However, even at this frame rate, the animation looked smooth, and I did not experience laggy behavior when dragging around tools/probes. I would have never had realized the frame rate was so low had it not been for ?profiler telling me so. The wave clearing introduced in #316 also seems to have done the trick. I never noticed a drop in performance when adjusting the source separation.

On the Chromebook, the frame rate was generally 45-55 FPS, but would occasionally dip into the 30's when the lattice got a bit noisy. Again, even when the frame rate was low, the animation looked good and moving tools around was never laggy.

@samreid also mentioned the possibility that the sound particle physics may have been disturbed by changing the lattice resolution and EVENT_RATE, but the particle/wave correspondence still looks good to me.

I think a lattice resolution of 151x151 is a happy medium, so let's proceed with that, @samreid.

[samreid]

If we recalibrate in the future, we should just need to change the lattice size then do the steps in #315 (comment) for water wave speed, and sound and light time scale. The rest should be handled automatically by CALIBRATION_SCALE.

[samreid]

My initial draft of recalibration at 151x151 (minus 20 on each edge for padding) is complete and published in a dev version here: https://phet-dev.colorado.edu/html/wave-interference/1.0.0-dev.63/phet/wave-interference_en_phet.html. Please note these changes spanned many parts, including but not limited to:

• the sound particle physics
• recalibrating the time scale for sound and light to make sure they have the right wave speeds.
• tuning the point source initial amplitude so that the decay rate is the same as prior versions
• tuning the width of the barrier so it looks similar

This draft will require careful testing of nearly every aspect of the physics. @arouinfar can you please test it out?

[arouinfar]

@samreid I took dev.63 for a pretty thorough test drive, and I'm happy to report the physics looks good.

• The correspondence between the particle and wave views of sound looks great.
• Sound speed came in at 343 m/s, and speed of light 3.02x10^8 m/s. (Due to the scaling of the light screen -- a few px corresponds to several nm -- there's a bit more measurement error.)
• Min and max wavelengths of sound mapped correctly to A3/A4. The measured wavelength of light was acceptable within measurement error
• Amplitude decay looks about the same as before
• Barrier also looks about the same as before.
• Interference patterns do not appear to have been disturbed