Wave amplitude changes when frequency is changed

[samreid]

@arouinfar forwarded this message from a client. Keeping the amplitude slider at the same value and changing the frequency ends up changing the amplitude of the wave:

[samreid]

I tested this and observed the same phenomenon in master. At min frequency and max amplitude for water, I recorded a level of about 81px in the graph. At max frequency and max amplitude, I recorded a level of about 55px in the graph. That is about 68% of the original value.

I am not aware of any code that would be explicitly responsible for this deviation. I hypothesized that it's a numerical sampling issue: that the long wavelength waves have a better opportunity to reach the full amplitude and that short wavelength waves may skip over it. I output the values for each case and observed behavior like this:

High Frequency wave:

1.6588655910781196
3.675888235278973
5.583616771798437
7.325329267121131
8.849239894031692
10.110038664441708
11.070238617988393
11.701290410838853
11.984431164966356
11.911242339302628
11.4839000357531
10.715110297796544
9.62773132541826
8.25409383894693
6.635039799224324
4.818708065548787
2.8591030970829783

Low frequency wave:

0.11037872588567416
0.6280314749125606
1.1445144351296566
1.6588655910781196
2.170126898056754
2.677346066603091
3.1795783362529257
3.675888235278648
4.1653513231234545
4.6470559122912265
5.120104766479758
5.583616771798437
6.036728577955798
6.478596206358628
6.908396622131042
7.325329267120861
7.728617551042524
8.117510297974677
8.491283145521669
8.849239894031346
9.190713803354958
9.515068834736748
9.821700835516452
10.110038664441616
10.379545255490386
10.629718618225874
10.86009277281767
11.070238617988197
11.259764730269247
11.428318093077616
11.575584754254058
11.701290410838853
11.80520091999631
11.887122735135753
11.946903266416541
11.984431164966338
11.999636530282457
11.992491040430567
11.963008004797848
11.911242339302628
11.837290464106369
11.741290124018947
11.623420131931175
11.483900035753198
11.322989709478174
11.140988869134093
10.93823651452428
10.715110297796773
10.472025820019441
10.209435857069346
9.927829516280513
9.627731325418361
9.309700255680422
8.974328680540848
8.622241272378828
8.2540938389473
7.870572101846377
7.472390419280114
7.060290455472822
6.635039799224324
6.197430534178757
5.748277763466545
5.288418091471889
4.8187080655490995
4.340022580594842
3.8532532494442377
3.3593067421276226
2.8591030970829783
2.3535740074655727
1.843661085751811
1.330314109864444
0.8144892540910894
0.29714730808703355

Note how the high frequency wave maxes out at 11.984431164966356 whereas the low frequency wave hits 11.999636530282457. That may be a factor, but it doesn't seem strong enough to create the 68% difference we observed.

Note also how the high frequency wave takes a value of >=11 for 5 sample steps, whereas the low frequency wave takes a value of >=11 for 19 sample steps. I wonder if the high frequency peak is getting "washed out" during the propagation whereas the low frequency peak is more resilient. If we were using an analytical model we wouldn't see this problem at all, and I presume this problem would disappear even for the emergent model as the lattice density tended toward infinity.

@arouinfar or @ariel-phet can you please recommend how to proceed?

[ariel-phet]

@samreid @arouinfar as a note, I just tested and this bug appears in the Java version, so it is assuredly part of the original model.

@samreid my instinct would be that this discrepancy is related to the damping in the model. Basically the higher the frequency, the more cycles to damp. Would it be possible to try a frequency dependent damping constant in the model and see if that alleviates the issue?

[samreid]

We currently do not apply damping in the main part of the wave area lattice. We experimented with it briefly a few times and ultimately decided it caused more problems than it solved. Here's a brief history:

October 8, 2017: Model is introduced with no damping

March 13, 2018: Added damping, with a scale factor of 0.99 April 11, 2018: Removed damping to match Java model

Jan 6, 2019: Added damping scale factor of 0.999 as part of #302 Jan 7, 2019: Changed damping scale factor to 0.9999 as part of #304 Jan 10, 2019: Damping was removed as part of https://github.com/phetsims/wave-interference/issues/306

Brainstorming some ideas:

1. Introduce frequency-dependent damping and tune it so lower frequencies are damped more, probably leaving high frequencies undamped. I'm happy to experiment with this if we agree it is a good use of time, but the model feels pretty finicky with respect to this parameter and it affects the interference pattern, wave decay and propagation physics, so it would require extensive testing.
2. Change the amplitude of the oscillation to be frequency-dependent. Give the high frequencies a bit of a boost at the oscillation site. This seems like a hack, and astute students would maybe notice this discrepancy and maybe think it is a different bug.
3. Switch to an analytical model instead of the lattice-based emergent model. This would be an intensive rewrite, but would give us more control over details like this. We previously discussed the analytical model in https://github.com/phetsims/wave-interference/issues/59 and decided against it, but we could reopen that or try other ideas in that realm.
4. Increase the resolution of the lattice to see if that weakens this effect. We already increased the resolution once and are close to the limit of acceptable performance on iPad Air 2. This would be an expensive change as it would require recalibrating the entire model.
5. Live with the decay in amplitude and document it in the teacher tips as an unfortunate side effect.

[ariel-phet]

@samreid what then causes the wave to decrease in amplitude as it gets farther from the source, what factor is doing that in the model? It seems that would be the first place to investigate

[samreid]

We are using the discretized wave equation approximation described in http://www.mtnmath.com/whatth/node47.html, in combination with a numerical approximation of absorbing boundary conditions along the edges described in https://www.phy.ornl.gov/csep/sw/node22.html. Here is the main part of the physics:

for ( let i = 1; i < width - 1; i++ ) {
  for ( let j = 1; j < height - 1; j++ ) {
    const neighborSum = matrix1.get( i + 1, j ) +
                        matrix1.get( i - 1, j ) +
                        matrix1.get( i, j + 1 ) +
                        matrix1.get( i, j - 1 );
    const m1ij = matrix1.get( i, j );
    const value = m1ij * 2 - matrix2.get( i, j ) + WAVE_SPEED_SQUARED * ( neighborSum + m1ij * -4 );
    matrix0.set( i, j, value );

    if ( Math.abs( value ) > LIGHT_VISIT_THRESHOLD ) {
      this.visitedMatrix.set( i, j, 1 );
    }
  }
}

The decrease in amplitude as a function of position is an implicit emergent behavior from this computation rather than an explicit factor.

I ran two experiments to test different hypotheses for what is causing this problem:

1. I hypothesized that problem was due in part to the resolution of the lattice. To test this hypothesis, I compared a lattice of size 101 x 101 cells to one 501 x 501 cells. I saw about the same discrepancy there at either lattice size.
2. I tested whether (difficult to see) internal reflections from the border were responsible for this behavior. To test this hypothesis, I placed the sensor at the center of the lattice and recorded the initial wave values--before the reflections had a time to reach the center. I saw the same discrepancy as before.

One thing noticed while investigating (1) was that simply increasing the lattice size yielded a decrease in the amplitude of the wave further from the source. Is that as expected since the source is still a point source (and hence proportionately smaller)?

That led to a following idea to try: instead of a single cell on the lattice oscillating, I tried a 5-point "plus sign" shape like so:

lattice.setCurrentValue( i, j, waveValue );
lattice.setCurrentValue( i + 1, j, waveValue * 0.8 );
lattice.setCurrentValue( i - 1, j, waveValue * 0.8 );
lattice.setCurrentValue( i, j + 1, waveValue * 0.8 );
lattice.setCurrentValue( i, j - 1, waveValue * 0.8 );

and the amplitude boosted from here to here (animated gif to help see the difference)

I thought we could use that to artificially inflate the source for low frequency waves, however it is unclear how we could change this into a continuous rather than discrete change. I tried using something like:

lattice.setCurrentValue( i, j, waveValue );
lattice.setCurrentValue( i + 1, j, waveValue * alpha );
lattice.setCurrentValue( i - 1, j, waveValue * alpha );
lattice.setCurrentValue( i, j + 1, waveValue * alpha );
lattice.setCurrentValue( i, j - 1, waveValue * alpha );

but it's not obvious how to compute alpha as a function of the frequency. Having alpha go to 0 or averaging it with the previous lattice value seems problematic, and I'm not sure what other ramifications of this pattern might be.

What do you think might be happening?

[samreid]

Also, I noticed something else when looking at the examples at the bottom of http://www.mtnmath.com/whatth/node47.html

At Time=-1, the first wave values starts as 100, so the total value over the lattice sums up to 100. At time = 0, same deal, sum is 100 At time = 1, it splits out to 4*25 = 100 At time = 2, it becomes 6*4+12*4+25*4-75 = 97

And it seems it is basically preserving the total "amount" on the lattice, just spreading it out. I tested to see if our wave equation has the same preservation property by running a similar experiment (a single cell set to v=100), and it seems it preserved the value nicely until it hit the boundaries:

```diff Index: js/common/model/Lattice.js IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- js/common/model/Lattice.js (revision a0a15cc4500ca34f6fec065cebb21ce192894883) +++ js/common/model/Lattice.js (date 1566442285723) @@ -270,15 +270,37 @@ */ step() { + window.count = window.count || 0; + window.count++; + // Move to the next matrix this.currentMatrixIndex = ( this.currentMatrixIndex - 1 + this.matrices.length ) % this.matrices.length; - const matrix0 = this.matrices[ ( this.currentMatrixIndex + 0 ) % this.matrices.length ]; - const matrix1 = this.matrices[ ( this.currentMatrixIndex + 1 ) % this.matrices.length ]; - const matrix2 = this.matrices[ ( this.currentMatrixIndex + 2 ) % this.matrices.length ]; + const matrix0 = this.matrices[ ( this.currentMatrixIndex + 0 ) % this.matrices.length ]; // current + const matrix1 = this.matrices[ ( this.currentMatrixIndex + 1 ) % this.matrices.length ]; // previous + const matrix2 = this.matrices[ ( this.currentMatrixIndex + 2 ) % this.matrices.length ]; // 2 steps ago + const width = matrix0.getRowDimension(); const height = matrix0.getColumnDimension(); + if ( window.count === 100 ) { + matrix1.set( Math.round( width / 2 ), Math.round( height / 2 ), 100 ); + matrix2.set( Math.round( width / 2 ), Math.round( height / 2 ), 100 ); + // + // matrix1.set( Math.round( width / 2 )+1, Math.round( height / 2 ),1000 ); + // matrix2.set( Math.round( width / 2 )+1, Math.round( height / 2 ),1000 ); + // + // matrix1.set( Math.round( width / 2 )-1, Math.round( height / 2 ),1000 ); + // matrix2.set( Math.round( width / 2 )-1, Math.round( height / 2 ),1000 ); + // + // matrix1.set( Math.round( width / 2 ), Math.round( height / 2 )+1,1000 ); + // matrix2.set( Math.round( width / 2 ), Math.round( height / 2 )+1,1000 ); + // + // matrix1.set( Math.round( width / 2 ), Math.round( height / 2 )-1,1000 ); + // matrix2.set( Math.round( width / 2 ), Math.round( height / 2 )-1,1000 ); + } + + let sum = 0; // Main loop, doesn't update cells on the edges for ( let i = 1; i < width - 1; i++ ) { for ( let j = 1; j < height - 1; j++ ) { @@ -289,12 +311,14 @@ const m1ij = matrix1.get( i, j ); const value = m1ij * 2 - matrix2.get( i, j ) + WAVE_SPEED_SQUARED * ( neighborSum + m1ij * -4 ); matrix0.set( i, j, value ); + sum += value; - if ( Math.abs( value ) > LIGHT_VISIT_THRESHOLD ) { + if ( Math.abs( value ) > LIGHT_VISIT_THRESHOLD || true ) { this.visitedMatrix.set( i, j, 1 ); } } } + console.log( sum ); // Numerical computation of absorbing boundary conditions, under the assumption that the wave is perpendicular // to the edge, see https://www.phy.ornl.gov/csep/sw/node22.html. This assumption does not hold everywhere, but @@ -305,36 +329,36 @@ // cb => WAVE_SPEED // Left edge - let i = 0; - for ( let j = 0; j < height; j++ ) { - const sum = matrix1.get( i, j ) + matrix1.get( i + 1, j ) - matrix2.get( i + 1, j ) + WAVE_SPEED * - ( matrix1.get( i + 1, j ) - matrix1.get( i, j ) + matrix2.get( i + 1, j ) - matrix2.get( i + 2, j ) ); - matrix0.set( i, j, sum ); - } - - // Right edge - i = width - 1; - for ( let j = 0; j < height; j++ ) { - const sum = matrix1.get( i, j ) + matrix1.get( i - 1, j ) - matrix2.get( i - 1, j ) + WAVE_SPEED * - ( matrix1.get( i - 1, j ) - matrix1.get( i, j ) + matrix2.get( i - 1, j ) - matrix2.get( i - 2, j ) ); - matrix0.set( i, j, sum ); - } - - // Top edge - let j = 0; - for ( let i = 0; i < width; i++ ) { - const sum = matrix1.get( i, j ) + matrix1.get( i, j + 1 ) - matrix2.get( i, j + 1 ) + WAVE_SPEED * - ( matrix1.get( i, j + 1 ) - matrix1.get( i, j ) + matrix2.get( i, j + 1 ) - matrix2.get( i, j + 2 ) ); - matrix0.set( i, j, sum ); - } - - // Bottom edge - j = height - 1; - for ( let i = 0; i < width; i++ ) { - const sum = matrix1.get( i, j ) + matrix1.get( i, j - 1 ) - matrix2.get( i, j - 1 ) + WAVE_SPEED * - ( matrix1.get( i, j - 1 ) - matrix1.get( i, j ) + matrix2.get( i, j - 1 ) - matrix2.get( i, j - 2 ) ); - matrix0.set( i, j, sum ); - } + // let i = 0; + // for ( let j = 0; j < height; j++ ) { + // const sum = matrix1.get( i, j ) + matrix1.get( i + 1, j ) - matrix2.get( i + 1, j ) + WAVE_SPEED * + // ( matrix1.get( i + 1, j ) - matrix1.get( i, j ) + matrix2.get( i + 1, j ) - matrix2.get( i + 2, j ) ); + // matrix0.set( i, j, sum ); + // } + // + // // Right edge + // i = width - 1; + // for ( let j = 0; j < height; j++ ) { + // const sum = matrix1.get( i, j ) + matrix1.get( i - 1, j ) - matrix2.get( i - 1, j ) + WAVE_SPEED * + // ( matrix1.get( i - 1, j ) - matrix1.get( i, j ) + matrix2.get( i - 1, j ) - matrix2.get( i - 2, j ) ); + // matrix0.set( i, j, sum ); + // } + // + // // Top edge + // let j = 0; + // for ( let i = 0; i < width; i++ ) { + // const sum = matrix1.get( i, j ) + matrix1.get( i, j + 1 ) - matrix2.get( i, j + 1 ) + WAVE_SPEED * + // ( matrix1.get( i, j + 1 ) - matrix1.get( i, j ) + matrix2.get( i, j + 1 ) - matrix2.get( i, j + 2 ) ); + // matrix0.set( i, j, sum ); + // } + // + // // Bottom edge + // j = height - 1; + // for ( let i = 0; i < width; i++ ) { + // const sum = matrix1.get( i, j ) + matrix1.get( i, j - 1 ) - matrix2.get( i, j - 1 ) + WAVE_SPEED * + // ( matrix1.get( i, j - 1 ) - matrix1.get( i, j ) + matrix2.get( i, j - 1 ) - matrix2.get( i, j - 2 ) ); + // matrix0.set( i, j, sum ); + // } } } Index: js/common/WaveInterferenceConstants.js IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- js/common/WaveInterferenceConstants.js (revision a0a15cc4500ca34f6fec065cebb21ce192894883) +++ js/common/WaveInterferenceConstants.js (date 1566441304471) @@ -85,7 +85,7 @@ FEMTO: 1E-15, // Cell that oscillates, specified as an offset from the origin of the lattice (includes damping region). - POINT_SOURCE_HORIZONTAL_COORDINATE: Util.roundSymmetric( 3 * CALIBRATION_SCALE ) + LATTICE_PADDING, + POINT_SOURCE_HORIZONTAL_COORDINATE: Math.round( WaveInterferenceQueryParameters.latticeSize / 2 ), // The lattice must have an odd dimension, so that there can be a cell exactly in the middle (for a single-cell // oscillator), symmetry for the two oscillator screen, and so the 1-cell wide barrier can appear directly in the ```

Next, I moved the point source to the center of the lattice, turned off damping and created this patch to test the sum vs time for our oscillator. I found the sum is not preserved, but increased linearly (note the wave starts on the negative amplitude side). I wonder if the time-dependent slope at the oscillator creates this? Or maybe something is wrong? I'm confused and uncertain.

```diff Index: js/common/model/Lattice.js IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- js/common/model/Lattice.js (revision a0a15cc4500ca34f6fec065cebb21ce192894883) +++ js/common/model/Lattice.js (date 1566440838367) @@ -270,15 +270,20 @@ */ step() { + window.count = window.count || 0; + window.count++; + // Move to the next matrix this.currentMatrixIndex = ( this.currentMatrixIndex - 1 + this.matrices.length ) % this.matrices.length; - const matrix0 = this.matrices[ ( this.currentMatrixIndex + 0 ) % this.matrices.length ]; - const matrix1 = this.matrices[ ( this.currentMatrixIndex + 1 ) % this.matrices.length ]; - const matrix2 = this.matrices[ ( this.currentMatrixIndex + 2 ) % this.matrices.length ]; + const matrix0 = this.matrices[ ( this.currentMatrixIndex + 0 ) % this.matrices.length ]; // current + const matrix1 = this.matrices[ ( this.currentMatrixIndex + 1 ) % this.matrices.length ]; // previous + const matrix2 = this.matrices[ ( this.currentMatrixIndex + 2 ) % this.matrices.length ]; // 2 steps ago + const width = matrix0.getRowDimension(); const height = matrix0.getColumnDimension(); + let sum = 0; // Main loop, doesn't update cells on the edges for ( let i = 1; i < width - 1; i++ ) { for ( let j = 1; j < height - 1; j++ ) { @@ -289,12 +294,14 @@ const m1ij = matrix1.get( i, j ); const value = m1ij * 2 - matrix2.get( i, j ) + WAVE_SPEED_SQUARED * ( neighborSum + m1ij * -4 ); matrix0.set( i, j, value ); + sum += value; - if ( Math.abs( value ) > LIGHT_VISIT_THRESHOLD ) { + if ( Math.abs( value ) > LIGHT_VISIT_THRESHOLD || true ) { this.visitedMatrix.set( i, j, 1 ); } } } + console.log( sum ); // Numerical computation of absorbing boundary conditions, under the assumption that the wave is perpendicular // to the edge, see https://www.phy.ornl.gov/csep/sw/node22.html. This assumption does not hold everywhere, but @@ -305,36 +312,36 @@ // cb => WAVE_SPEED // Left edge - let i = 0; - for ( let j = 0; j < height; j++ ) { - const sum = matrix1.get( i, j ) + matrix1.get( i + 1, j ) - matrix2.get( i + 1, j ) + WAVE_SPEED * - ( matrix1.get( i + 1, j ) - matrix1.get( i, j ) + matrix2.get( i + 1, j ) - matrix2.get( i + 2, j ) ); - matrix0.set( i, j, sum ); - } - - // Right edge - i = width - 1; - for ( let j = 0; j < height; j++ ) { - const sum = matrix1.get( i, j ) + matrix1.get( i - 1, j ) - matrix2.get( i - 1, j ) + WAVE_SPEED * - ( matrix1.get( i - 1, j ) - matrix1.get( i, j ) + matrix2.get( i - 1, j ) - matrix2.get( i - 2, j ) ); - matrix0.set( i, j, sum ); - } - - // Top edge - let j = 0; - for ( let i = 0; i < width; i++ ) { - const sum = matrix1.get( i, j ) + matrix1.get( i, j + 1 ) - matrix2.get( i, j + 1 ) + WAVE_SPEED * - ( matrix1.get( i, j + 1 ) - matrix1.get( i, j ) + matrix2.get( i, j + 1 ) - matrix2.get( i, j + 2 ) ); - matrix0.set( i, j, sum ); - } - - // Bottom edge - j = height - 1; - for ( let i = 0; i < width; i++ ) { - const sum = matrix1.get( i, j ) + matrix1.get( i, j - 1 ) - matrix2.get( i, j - 1 ) + WAVE_SPEED * - ( matrix1.get( i, j - 1 ) - matrix1.get( i, j ) + matrix2.get( i, j - 1 ) - matrix2.get( i, j - 2 ) ); - matrix0.set( i, j, sum ); - } + // let i = 0; + // for ( let j = 0; j < height; j++ ) { + // const sum = matrix1.get( i, j ) + matrix1.get( i + 1, j ) - matrix2.get( i + 1, j ) + WAVE_SPEED * + // ( matrix1.get( i + 1, j ) - matrix1.get( i, j ) + matrix2.get( i + 1, j ) - matrix2.get( i + 2, j ) ); + // matrix0.set( i, j, sum ); + // } + // + // // Right edge + // i = width - 1; + // for ( let j = 0; j < height; j++ ) { + // const sum = matrix1.get( i, j ) + matrix1.get( i - 1, j ) - matrix2.get( i - 1, j ) + WAVE_SPEED * + // ( matrix1.get( i - 1, j ) - matrix1.get( i, j ) + matrix2.get( i - 1, j ) - matrix2.get( i - 2, j ) ); + // matrix0.set( i, j, sum ); + // } + // + // // Top edge + // let j = 0; + // for ( let i = 0; i < width; i++ ) { + // const sum = matrix1.get( i, j ) + matrix1.get( i, j + 1 ) - matrix2.get( i, j + 1 ) + WAVE_SPEED * + // ( matrix1.get( i, j + 1 ) - matrix1.get( i, j ) + matrix2.get( i, j + 1 ) - matrix2.get( i, j + 2 ) ); + // matrix0.set( i, j, sum ); + // } + // + // // Bottom edge + // j = height - 1; + // for ( let i = 0; i < width; i++ ) { + // const sum = matrix1.get( i, j ) + matrix1.get( i, j - 1 ) - matrix2.get( i, j - 1 ) + WAVE_SPEED * + // ( matrix1.get( i, j - 1 ) - matrix1.get( i, j ) + matrix2.get( i, j - 1 ) - matrix2.get( i, j - 2 ) ); + // matrix0.set( i, j, sum ); + // } } } Index: js/common/WaveInterferenceConstants.js IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- js/common/WaveInterferenceConstants.js (revision a0a15cc4500ca34f6fec065cebb21ce192894883) +++ js/common/WaveInterferenceConstants.js (date 1566441304471) @@ -85,7 +85,7 @@ FEMTO: 1E-15, // Cell that oscillates, specified as an offset from the origin of the lattice (includes damping region). - POINT_SOURCE_HORIZONTAL_COORDINATE: Util.roundSymmetric( 3 * CALIBRATION_SCALE ) + LATTICE_PADDING, + POINT_SOURCE_HORIZONTAL_COORDINATE: Math.round( WaveInterferenceQueryParameters.latticeSize / 2 ), // The lattice must have an odd dimension, so that there can be a cell exactly in the middle (for a single-cell // oscillator), symmetry for the two oscillator screen, and so the 1-cell wide barrier can appear directly in the ```

[ariel-phet]

@samreid not sure if this data point helps, but in playing around, I noticed that this amplitude discrepancy does not appear to occur if in Pulse mode (if looking at the positive peak of the pulse, it is the same height above zero for the lowest and highest frequency light wave).

[samreid]

I tested and confirmed this problem is not present in pulse mode for light waves. However, I also noticed this problem is not present for continuous light waves. This is likely because the range between frequencies on the lattice is much smaller. I am still seeing the problem for max and min amplitude for water waves. But this may lead us to a potential solution: we could narrow the range of frequencies allowed for water and sound.

[samreid]

Aug 29 notes

AP: Tweak the initial amplitude base, fudge factor in the model but not in the view. AP: This problem has been around for a long time, may not need to be solved for 2.0 AR: We should reply to the client AP: I'll do so.

[samreid]

@arouinfar suggests deferring this for RC.2.

[arouinfar]

This is likely because the range between frequencies on the lattice is much smaller. I am still seeing the problem for max and min amplitude for water waves. But this may lead us to a potential solution: we could narrow the range of frequencies allowed for water and sound.

I would push against this a bit. I think it's important to have a range that would allow for doubling or quadrupling the frequency. For light, that's not physically possible. Currently the sound scene allows for doubling the frequency, which corresponds to one octave. Water allows for quadrupling the frequency, which is nice because you can see really long wavelengths.

[samreid]

The proposal at the bottom of https://github.com/phetsims/wave-interference/issues/435#issuecomment-523663066 (expanding the radius of the source) may be preferable to running one model for the model (with the fudge factor) and another model for the view (without the fudge factor).

[ariel-phet]

Leaving deferred until we publish the diffraction screen, but still keeping assigned to @samreid as this issue could be investigated independent of the RC cycle presumably if he has some time.

[samreid]

It seems like making the next release contingent on a robust solution here may push out the publication date too far. Should this be deferred until a future release?

[arouinfar]

Yes, it seems reasonable to continue deferring.

[ariel-phet]

Considering this sim has been out in the wild for sometime without complaints, I am fine with continuing to defer. Unassigning myself.