Pulse isn't symmetrical

[samreid]

During #258, I noted that the pulse isn't symmetrical. I'm not sure what can be done about this, but thought I should bring it up for discussion:

@arouinfar what do you think?

[arouinfar]

@samreid this looks really problematic to me.

In dev.56 the wavefront looks nice and symmetric, both in the lattice and in the graph.

In dev.57, the pulse is quite deformed.

As the wave propagates, half the wavelength is gone. This makes me suspect that something is not quite right in the model. Can you look into it @samreid?

[arouinfar]

Pulsed light is pretty atrocious. Again, it looks like there's only half of a wavelength.

[arouinfar]

@samreid I don't think this is necessarily a problem with the pulse -- I think it might be a general issue with the leading edge of the wave.

Here's a continuous water wave in dev.57. The leading edge of the wave disappears as it propagates across the lattice. I think this is the same phenomena as the pulse losing half of its wavelength in my previous comments..

[samreid]

@jonathanolson and I discovered that the wave speed was incorrect, we also added a slight tolerance around the mask to prevent cramping the leading wave front. Committed and pushed to master, @arouinfar can you please take a look?

[arouinfar]

@samreid things are definitely looking better, but there's still a bit of cramping on the leading wavefront, so perhaps the mask tolerance needs a bit more tuning.

I think it's a bit more noticeable with light, which has the most closely spaced wavefronts.

[samreid]

I found that disturbance in the wave was caused by the 0.999 scaling factor for the wave that was meant to wash out numerical artifacts. Tuning that to 0.9999 still seems to wash out the numerical artifacts, but doesn't disturb the wave as much.

The new masking effect seems promising, but involves several new parameters that need tuning.

1. Leading edge tolerance (4) - how much ahead of the theoretical edge of the wave to mask
2. Tailing edge tolerance (4) - how far behind the theoretical edge of the wave to mask
3. DAMPING_COEFFICIENT (0.9999) - cumulative scale factor for lattice values to wash out numerical artifacts introduce by masking
4. Mask reducer: (0.95) - cumulative scale factor for damping out waves in regions where they shouldn't exist

What we want to optimize:

1. Making sure there is no overall bias in the wave, as depicted in Letting the wave sit for 5 minutes causes it to oversaturate: 2 sources. #302. This can be tested by setting WavesModel dt *50, turning on the faucet and the graph and waiting 10+ seconds.
2. Making sure the shape of the wave isn't disturbed. This can be done by comparing a side-view wave to a version like https://phet-dev.colorado.edu/html/wave-interference/1.0.0-dev.56/phet/wave-interference_en_phet.html
3. Making sure the black window around light is the right size
4. Making sure trailing wave zeroes out at an appropriate radius.

Now that I've further tuned the Mask reducer and DAMPING_COEFFICIENT, we may be at a good spot. @arouinfar can you please review again on phettest? If it still needs tinkering, perhaps we should add query parameters or meet for a parameter tuning session?

[samreid]

I also noticed that at ?latticeSize=201, there is something fishy happening in the leading wavefront:

Perhaps the wave speed isn't exactly the theoretical value of 0.5?

[arouinfar]

@samreid water and sound look pretty reasonable, but light isn't looking so great. The larger the wavelength, the better the light looks. The default frequencies and higher look pretty awful.

If it still needs tinkering, perhaps we should add query parameters or meet for a parameter tuning session?

@samreid if query parameters would be pretty straightforward, let's try that. If not, we can meet for further parameter tuning.

[samreid]

I agree it is difficult to see the pulses on the chart for green and higher frequencies of light. However, this does not seem to be caused by the new masking approach. For instance, here are three pulses of violet light from https://phet-dev.colorado.edu/html/wave-interference/1.0.0-dev.56/phet/wave-interference_en_phet.html

I'm not saying the screenshot in @arouinfar's preceding comment (using masking) is perfect, but it does seem preferable to dev.56 (no masking).

In #234 (comment) we discussed the jaggedness of the graph curve, particularly for high frequency light but decided not to do anything. Is there a new artifact at play here? Do we want to re-evaluate our decision from #234? It seems the best long-term approach way to solve this problem would be to increase the lattice size or recalibrate the light lattice so that high frequency light has a longer wavelength on the lattice (and hence red light would have an even longer wavelength on the lattice). Neither of those approaches is trivial though.

[arouinfar]

In #234 (comment) we discussed the jaggedness of the graph curve, particularly for high frequency light but decided not to do anything. Is there a new artifact at play here? Do we want to re-evaluate our decision from #234?

The jaggedness isn't ideal, but I don't think it's what's causing the problem. My worry is that the leading trough completely disappears. You can see the same effect on a continuous wave -- the leading trough will disappear as the wave propagates across the lattice. This is simply non-physical.

I don't think it's a mis-match between the lattice and the graph. The graph shows the leading trough disappearing because it is actually disappearing in the lattice.

It seems the best long-term approach way to solve this problem would be to increase the lattice size or recalibrate the light lattice so that high frequency light has a longer wavelength on the lattice (and hence red light would have an even longer wavelength on the lattice).

I think this might be the way to go, but it seems a bit like we'd be sweeping the problem under the rug. It doesn't address the root issue of why the leading trough has a strange attenuation. It's just that the problem is less obvious for larger wavelengths (in terms of % of lattice).

I don't think this is something we should tackle for 1.0, but I would consider it for 2.0.

I'm not saying the screenshot in @arouinfar's preceding comment (using masking) is perfect, but it does seem preferable to dev.56 (no masking).

I didn't realize dev.56 was so awful. @samreid has made significant improvement, and I can live with the current behavior. I think it would be helpful for @ariel-phet to review this issue before we go any further.

[samreid]

My worry is that the leading trough completely disappears.

Thanks for clarifying about the nature of the problem. @jonathanolson and I identified that some combination of the masking and the boundary conditions are leading to an overall "bias" effect that raises or lowers all values across the entire lattice--this could be causing the trough to disappear. We found we could mute the effect a little by damping each wave value in every frame (this is the 0.9999 scale factor), but it still looks like the bias is present. To clarify, I think the last image in #304 (comment) does have a "trough", but the entire wave is shifted up past the origin.

[samreid]

I know we have already fine tuned the amplitude of the oscillator based on other concerns, but it seems one way to approach this problem is to increase it. For instance, here is violet light with amplitude*10:

Note it is still not symmetrical, but it does have a trough at least. Also, I want to note that I wouldn't expect these waves to be 100% symmetrical, because the leading edge has attenuated more than the tail (but this asymmetry seems to have more to it).

[samreid]

@arouinfar reviewed this in https://phet-dev.colorado.edu/html/wave-interference/1.0.0-dev.59/phet/wave-interference_en_phet.html and said it is good to go. I'll create a new issue about the first trough being smaller than subsequent.