Should the ?theory lines show on the "Interference" screen?

[samreid]

From #191 and #136, the ?theory query parameter only shows for the "Slits" screen. Would we like it to show fo the "Interference" screen as well?

[arouinfar]

Good question @samreid. I think ?theory is particularly useful for slit interference because it can be a bit trickier to get the interference pattern to converge on the screen. It's much easier to set up two-source interference examples that converge on the screen. I also think it would also be a bit odd to see the ?theory lines on Interference, because the origin would be at the midpoint of the sources. I'd prefer to pass on adding ?theory support to Interference.

If you agree, feel free to close @samreid. Otherwise, please tag this issue for further consideration at design meeting.

[samreid]

I also think it would also be a bit odd to see the ?theory lines on Interference, because the origin would be at the midpoint of the sources.

That part doesn't bother me at all, for the same reason it is acceptable showing the origin at the center of the barrier on the slits screen (for two slits).

I agree this feature will be very helpful to teachers that want to leverage it for the slits screen, but it could be confusing to teachers that want to draw correspondence between the slits screen and the interference screen. That being said, I don't think this query parameter will be used by a large fraction of teachers and it also doesn't seem essential for 1.0. If it was a more important feature, I'd suggest we add a user interface control for it in the simulation, but we decided against that in a design meeting. I estimate it would take a couple of hours to add it to the Interference screen. I won't work on it until we discuss it further.

[arouinfar]

@samreid I think we could defer ?theory on Interference for 1.1+. Given the tight timeline, it doesn't seem worth it for 1.0.

[samreid]

Agreed, I'll self-assign for now to document accordingly, then we can decide how best to address for 1.1+.

[samreid]

Documented accordingly, and deferring until 1.1+

[samreid]

In my opinion, the value of this feature would not exceed its cost and I recommend to close without fixing. Assigning for design meeting to discuss.

[arouinfar]

I don't think ?theory is essential for the Interference screen, so I'd be fine with closing.

[samreid]

@kathy-phet says it would be nice to make sure the empirical result matches the theoretical result, and it could potentially be something to share with teachers as well. @samreid gave a time estimate of 2-3 hours.

[samreid]

I adapted the existing ?theory code to show for the interference screen, with the assumption that 2 sources are oscillating. Testing the default value for water:

Testing the max frequency for sound:

Testing the min frequency for light:

Correspondence seems reasonable. Reassigning to @arouinfar to take a closer look, let me know if there's more to do for this issue.

[arouinfar]

@samreid the correspondence in the screenshots you've posted looks fine to me. However, the lines don't appear to shift when the separation changes. I'm also seeing a pretty big delay between changing the frequency and the shift in the ?theory lines for the water scene.

[arouinfar]

There are actually "invisible drops" that send a signal to the lattice to stop oscillating.

Ah, got it. Thanks for the clarification.

Is this acceptable for this use case, or want me to investigate wiring things up to the "desired" instead of "actual" for the water drops?

Since I was fine with limiting ?theory to only the Slits screen, I would lean towards not spending any more time on this issue. However, I think it's best to defer to @kathy-phet on this one.

[arouinfar]

@kathy-phet can you review the behavior of ?theory on the Interference screen? There is good correspondence between the ?theory overlay and the lattice. However, the overlay is quite slow to update on water because as @samreid described:

changing the separation or frequency via the user interface doesn't immediately change the oscillatory behavior of the model. Instead, it schedules the new frequency/separation for when the next droplets hit the surface of the water.

@kathy-phet is this acceptable? @samreid also proposed this alternative:

Should I investigate wiring up the theory overlay for water to the values set in the user interface? It could take 30-60 minutes up-front effort and would introduce a bit more complexity for this feature that would need to be maintained.

[samreid]

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

[arouinfar]

Should I investigate wiring up the theory overlay for water to the values set in the user interface? It could take 30-60 minutes up-front effort and would introduce a bit more complexity for this feature that would need to be maintained.

Discussed at the 6/20/19 design meeting, and we decided that @samreid should proceed with this.

[samreid]

In the commit, I made it so the theory lines update immediately for water. @arouinfar can you please fully test the ?theory query parameter, including but not limited to this new change and let me know if everything is OK? Close if all is well.

[arouinfar]

@samreid ?theory is looking good on the Interference screen for all scenes. However, I'm noticing things look a bit off for water on the Slits screen (sound and light are ok). Comparing to latest reveals that things are indeed different for water.

In latest (1.0.4) there is good agreement between ?theory and the lattice.

Recreating the same situation in master, the ?theory lines are clearly different, and do not align with the pattern seen in the lattice (red lines look centered between two minima).

[samreid]

Good discovery @arouinfar, I'll look into it.

[samreid]

Proposed fix is committed, @arouinfar please review.

[arouinfar]

Looking good in master @samreid!