Improve interference from "reflection" in single wave light screen for v2

[kathy-phet]

When we just have one source in the first or second screens, the "reflection" or lack of complete absorption that is happening on the far right of the lattice is causing interference to be visible on the light screen. I would like to spend some time investigating options for reducing this for this v2 work (see oscillatory behavior here). Can the model be tweaked so that after the wave has propogated out of the window and to the edge it can no longer propogate backwards? Perhaps consulting with Mike D for additional options on suppressing that backward reflection? (Note - I am connecting this to a reflection of the back of the lattice because it takes a while for the oscillations to appear and at first they are not there).

[arouinfar]

@samreid is it possible that increasing the lattice size in #315 could be the culprit here?

The apparent interference pattern in screen on Waves was previously discussed/addressed in #171 and #197. The brightness of the screen has also been extensively discussed in #161. Would we need to revisit/recalibrate the work done in these issues?

[arouinfar]

Sorry for the potato quality, but here's a comparison of dev.61 (top) and rc.2 (bottom).

[samreid]

On Thursday, March 21, @kathy-phet reiterated that it would be good to eliminate this interior reflection that is leading to a pattern in the signal. I previously experimented with several approaches to eliminate or reduce reflections at the edge of the barriers, and the best approach we have implemented so far is described in this comment: #197 (comment)

This approach has better behavior than any of the exponential decay function envelopes we tried, but it does not eliminate reflections 100%.

I mentioned to @kathy-phet that as a last resort, we could superimpose the desired result on the screen and graph.

It would be good to touch base on this issue before I spend more time on it.

[samreid]

The brightness of the screen has also been extensively discussed in #161. Would we need to revisit/recalibrate the work done in these issues?

Note we expect to perform some recalibration in #323 (comment)

[samreid]

In discussion, @arouinfar and I decided to try a hollywood or larger averaging window, only for the waves screen. You would still see this problem on the interference screen if one source is on, but that is a rarer case.

[samreid]

For the screens with a single source, I increased the averaging window for the screen. This smooths out the noise. @arouinfar can you please review?

[arouinfar]

@samreid this looks great! Since the Waves screen has its own averaging window, I think it would be good to also change the brightness calibration for Waves too. With the amplitude at 50%, the brightness is quite low, and would seem closer to the brightness I would expect at 10%.

Amplitude	Screen Brightness
100%
50%
10%

[samreid]

If I multiply the overall brightness scaling by a factor of 3, the 50% value seems better:

but even 25% seems very dark:

Do you think we will need to introduce a nonlinearity for this display?

[samreid]

@arouinfar and I reviewed this and decided we would like to try a piecewise linear function to get better behavior across the range of intensities.

[arouinfar]

@samreid the updated brightness on Waves looks great!

However, the screen is broken elsewhere in the sim. The intensity graph appears undisturbed, though.

[samreid]

Good catch, thanks! I'll take a look.

[samreid]

I committed a proposed fix, can you please take a look on phettest?

[arouinfar]

Looks great @samreid! I'll tag for design meeting review.

[samreid]

Raw notes for archival purposes, in case we come back to this.

80% (default) 0.13
100% 0.21 (oversaturated)
50% => 0.05 (looks good)
40% => 0.036 (this is what 25% should look like)
30% => 0.019 (this is what 10% should look like)

Maybe take sqrt for the display? This idea did not pan out quickly, we investigated linear piecewise instead.

amplitude intensity brightess                            desired brightness
100% 0.2096934692889395 0.9063853228610702 fully bright  0.9
80% 0.13422634397144692 0.5801839634279833 good          0.5
50% 0.05372277438413573 0.23221292666039975 too dim      0.4
20% 0.008937089269640335 0.03862994193652949             0.3
0% 0.000000000000000000 0.00000000000000000 off          0.0

new piecewiselinearfunction([0,0,  0.008, 0.3,  0.05,0.4,  0.134,0.5, 0.2,0.9]  )

a	b
0	0
0.00223709	0.4
0.00893709	0.5
0.05372277	0.64
0.13422634	0.8
0.20969347	0.9
1	1

[samreid]

In the design meeting, we agreed this is looking much better. @kathy-phet said she will take a closer look later on.

@kathy-phet asks if it is important to be dimmer on the edges, @ariel-phet says not that important.

[samreid]

@ariel-phet can you help move this issue forward?

[ariel-phet]

@samreid said proposed version is in Master. Will take a look.

[ariel-phet]

@samreid @arouinfar I am tempted to go ahead and close this issue. The fix appears to address the areas of concern. I will note that even with the fix the interference can still be seen with a single source that is slightly off center. But really on the interference screen both sources being "on" is the pedagogically useful case.

[arouinfar]

Discussed in 6/20/19 design meeting, and decided that we can defer this issue.

The current behavior is an improvement over 1.0, but we would like to leave this open for the possibility of future investigation/improvements.