User suggestion: more precise 'Damping' control

[oliver-phet]

I tried to use the new HTML5 veriod of wave-on-a-string, but I ran into a problem. The Damping control is too coarse and the ability to type in the damping values is gone.This means my class can't do a cool resonance experiment that was possible with the Flash version.

So for now, I will keep using the Flash version.

[ariel-phet]

@arouinfar we could make damping here have a tweaker (so that you could set a repeatable amount of damping) but I believe our reason for removing a readout is that the readout was sort of arbitrary where "100" meant critically damped. We could do zero percent to 100 percent and in the tips explain what "100 %" means, but it seems just having 0-100 (like in the flash sim) is a bit problematic.

Thoughts?

[arouinfar]

@ariel-phet I think it would be very helpful to add readout/tweakers. The 0-100% range seems reasonable, so long as we keep the % in the readout. I have a feeling it would be challenging to quantify further, as I suspect the damping may also be hollywooded like the tension.

[ariel-phet]

@arouinfar can you make a mockup with tweakers and a readout, as well as a more granular tension slider? We might need to adjust a few things to make everything fit in the bottom control panel. (and make the slider knobs a bit more slender or such)

We are getting enough requests we should probably have some (perhaps Aadish) address these concerns.

[arouinfar]

Will do @ariel-phet!

[arouinfar]

@ariel-phet here are some updated mockups. They're a little Frankensteined, so you may spot some flaws. I haven't resized any of the components, other than creating a longer slider for Tension. I expanded the panel, and it comes a bit close to the edges of the play area, but I kept 40px between the each control. We could probably reduce this a bit and free up some space.

I created a tension slider with 7 notches, because the data looks pretty good. The Tension vs. Velocity plot (in arbitrary units) is clearly non-linear.

With 5 notches, the Tension vs. Velocity plot could be mistaken for a linear relationship.

[ariel-phet]

@arouinfar lets change the Damping slider to be the same style as frequency or amplitude (no tick marks) to distinguish it from the slider with just a few positions.

[arouinfar]

Ah, good suggestion @ariel-phet. If we go with the smooth slider, I would think the tweakers would need to step by 1% (unless the slider knob would be snappy).

[ariel-phet]

@arouinfar that all looks good, can you do some polishing so we can give to @aadish an exact mockup at some point soon. Basically just that lower control panel...space things out evenly and bring things together a little between the controls so the panel is not so wide (pretty tight to the reset button and such right now).

[arouinfar]

Sounds good @ariel-phet. In the most recent screenshot, there are exactly 40 px (red lines) between the controls in the lower panel. I can reduce that somewhat to give more padding to the reset all button.

[arouinfar]

@ariel-phet here's an updated mockup with the space between the controls reduced to 35 px. There are some visual differences between the tweakers because the mockup is a combination of screenshots and Illustrator assets.

[ariel-phet]

@arouinfar - final tweak in the mockup I think ...could you move the lower control panel to the left so it aligns on the left edge with the top control panel? Or move the top control panels in a bit from both edges (which evener you think looks better. Those top panels seem a bit tight to the edges perhaps.

[arouinfar]

@ariel-phet here's what it looks like if we move the lower control panel to the left.

I think this is a better option. I've moved both of the upper control panels in a bit to have equal padding with the dev boundary. The bottom control panel and reset all have been shifted so that they align with the upper controls.

Back to you @ariel-phet.

[ariel-phet]

Agreed @arouinfar the second one looks best. Leaving assigned to me until we figure out who is going to make the upgrade.

[ariel-phet]

Since Jesse has decided to take on Gravity Force Lab: Basics it makes sense for @aadish to work on this modification.

@aadish please schedule a time with @arouinfar to discuss the changes

@aadish feel free to do this work as you are finishing up Gene Expression.

[arouinfar]

Just spoke with @aadish. We've scheduled a meeting for Monday morning at 11:15.

[arouinfar]

Met with @aadish to discuss the proposed changes, which I'll summarize here

• Damping does not need to be rescaled. None/lots will correspond to 0%/100%.
• Step size for damping tweakers is 1%.
• Tension slider will have 4 additional notches, and the first three correspond to low/med/high in published version. (We can revisit if this proves to be problematic.)
• Default values for tension and damping will remain the same.

@aadish here's the latest mockup

[aadish]

https://github.com/phetsims/wave-on-a-string/commit/863d901c2f9601aa3c8a2606fe3fcb55c77276b6

[aadish]

@arouinfar

I made the changes could you take a look. For the tension I increased the range but I don't know what effect to observe how to generate the graphs you posted above

[arouinfar]

@aadish I took a look at master. The damping controls look good. My one request would be for the value of the Amplitude, Frequency, and Damping to be vertically centered.

The tension slider doesn't appear change beyond the 3rd position. The wavelength at the 3rd and 7th position on the slider is identical:

Tension is proportional to velocity squared (and velocity = wavelength * frequency).

The tension slider should increase in powers of 2. Using arbitrary units/values, the tick marks on the slider would operate as 2, 4, 8, 16, 32... The velocity of the wave can be measured at each value of the tension, and then plotted versus the tension.

When writing the Teacher Tips (see #114), I had to do a little digging into the tension model previously

WOASModel.js, line 34: this.tensionProperty = new Property( 2 ); // tension 0..2

WOASModel.js, lines 187-188 (fps hardcoded as 50):

//dt for tension effect
      var minDt = (1 / (fps * (0.2 + this.tensionProperty.get() * 0.4) * this.speedProperty.get()));

It looks like this.tensionProperty is still confined to 0..2. Perhaps it needs to change to 0..6?

[aadish]

@arouinfar the value for tensionProperty goes from 0 to 6 and I checked that they value is ranging from 0 to 6. I will see the code and see how tension value is being used in the sim

[arouinfar]

@aadish I don't think that's done the trick. I pulled master, and I'm still seeing the same result. Tick marks 3-7 all have the same wavelength, so the tension is not being changed.

Can you instead keep the same tension range as the published version? The first tick mark would correspond to Low, the seventh tick mark would correspond to High, and the rest is scaled. The only challenge would be that the slider operates in powers of 2 instead of linearly, so things may get tricky.

[aadish]

@arouinfar tension ranges from 0 to 2 only but has 9 notches hope this helps. Let me know if anything else has to be done

[arouinfar]

Something's still not quite right @aadish.

Assuming the slider behaves linearly, I'm seeing tension is proportional to velocity, rather than velocity squared.

I don't believe the slider increases by powers of 2 anymore, because these are the resulting graphs

[aadish]

@ariel-phet

In the code base tension is not being used directly and is used to manipulate the frame rate. Might be good ideas if some developer has worked before on this sim can chime in how is tension being used. I was not able to decipher that piece of code. But the value is no where being squared before using it

[ariel-phet]

@aadish I will have @jonathanolson advise, he has worked on this sim before.

Marking for dev meeting as a reminder to myself to bring up to @jonathanolson tomorrow, but if he sees it before then feel free to take off the label

[jonathanolson]

Ok, so after a lot of digging (cutting off at 1.5 hours):

The general current model formulation is based on the variable names of some random .docx from 2013:

The current value of 'b' is damping * 0.002, where the range of the damping variable is defined as [sic] dumping 0..100 with a default of 20.

The value for 'v' is 1. Doesn't change. Vague memories of changing it causing the numerical solution to blow up, but could be wrong.

So the sim looks like it somehow modifies how many times (and when) the fixed-timestep model is run based on the tension. There look to be bugs in there, and that code is a jungle. I'd recommend https://github.com/phetsims/wave-on-a-string/issues/64 gets handled (cleaning up all of that) so that we're left with a simplistic "here's the fixed-timestep model" and "here's how time interacts with the model, and how we step through it".

Note that the weird way tension is handled could (from my reading of the code to be cleaned up in #64) could result in the tension changing but having no effect on the model (depending on the speed of the computer).

I see the following approaches:

1. Clean up the code for how the model deals with fixed timesteps (https://github.com/phetsims/wave-on-a-string/issues/64), and adjust the speed of model steps based on the tension such that it has the correct relationship with velocity. This probably doesn't handle damping-tension interaction properly.
2. Modify the wave speed ('v') based on tension in the underlying model, remove the timestep-slowing compensation, and if there is instability in the solver, handle it there. wave-on-a-string/assets/test-model.html is a result of my previous investigation into different methods of solving the differential equation, and increasing the wave speed above a certain point (1?) during animation causes things to blow up (probably due to it looking like energy was added/removed). Maybe triggering a zeroing of the string when changing tension would work. Maybe tracking down the filtering approach I was attempting to use would work (http://www.me.jhu.edu/fsag/Publications/Papers/JCP92.pdf is a broken link). Maybe just keeping the wave speed well below those bad speeds would work (with adjusting the damping and framerate to compensate).

[samreid]

@ariel-phet said:

Marking for dev meeting as a reminder to myself to bring up to @jonathanolson tomorrow, but if he sees it before then feel free to take off the label

@jonathanolson has responded above. Hence I'll remove the meeting label. @ariel-phet or @jonathanolson please restore the label if necessary.

[arouinfar]

@jonathanolson thanks for looking into this. Before you and/or @aadish dig into the tension any further, I'd like to clarify the goals for the tension adjustment, as it may help guide your choice of approach.

One of the learning goals is for students to identify the relationship between the tension and the wave speed (tension is proportional to velocity squared). Typically, this would be done by measuring the speed (either by v=l*f or v=d/t) and plotting it against the tension in arbitrary units.

Currently, there are two challenges (described in more detail in https://github.com/phetsims/wave-on-a-string/issues/114#issuecomment-231145489 and onward)

1. A three-step slider does not have enough range for students to notice the difference between linear and non-linear data.
2. The slider appears to increase in powers of two, so the arbitrary tension values need to increase like 2, 4, 8 or even 128, 256, 512. The values themselves don't matter, just the relationship between them. While this is documented in the teacher tips, many may still assume that the tension slider behaves linearly.

The first challenge can be addressed by extending the tension range OR by adding more steps to the current range. @aadish most recently did the latter, and divided the tension slider into nine steps.

The second challenge doesn't necessarily need to be addressed, though it would be nice. A linear slider is far more intuitive for teachers/students. However, if the slider behavior is known, it is easy to get reasonably clean data if there are a sufficient number of steps on the tension slider.

[ariel-phet]

@arouinfar I think it is going to be quite some time before we mess with the model in this sim. It should be done at some point...perhaps when the sim becomes critical for iO, but the sim has been published as is for quite some time, so I think we have to live with the "as is" model.

I think anything you wish to do within the constraints of not changing the model is reasonable, and in this case, I am fine with a nonlinear slider. So feel free to have a readout/or labels that make clear the nonlinearity.

[arouinfar]

@ariel-phet I am fine with a nonlinear slider, so long as its behavior is known and can be documented. What I am not so keen on is the 3-step slider. Three data points is simply not enough to determine that tension is proportional to velocity squared, which is a learning goal.

The Flash sim had significantly more range in the tension. Did we not port the Flash model?

Is there anything that can be done (that doesn't require a model rewrite) to add more steps to the tension? I frankly do not care if the resulting slider is linear or logarithmic or powers of two, so long as the behavior is known so that we can tell teachers how to get clean data when plotting arbitrary tension vs. v^2.

[arouinfar]

If it turns out that we absolutely cannot add more range to the tension (or subdivide the current range) without rewriting the model, I'm okay with tabling it.

[aadish]

@arouinfar if you pull the latest branch the range 0 to 2 is divided into 9 notches with step difference from 0.25 and the drag handler snaps to the notches

Its not linear as you have pointed out earlier. Do you want it more fine grained. It is achievable

[arouinfar]

@arouinfar if you pull the latest branch the range 0 to 2 is divided into 9 notches with step difference from 0.25 and the drag handler snaps to the notches

@aadish is this the same behavior as the slider I tested in https://github.com/phetsims/wave-on-a-string/issues/116#issuecomment-260815840? If so, the problem is that I don't what know arbitrary units to use for tension so that the resulting graphs show the correct relationships.

[oliver-phet]

Please enable a very small damping setting (again, as with the old Flash-based sim)!

The old Wave on a String sim allowed Damping values between 0-100. When introducing standing waves and resonance to students, we would use that Damping=1 value to allow oscillations at resonant frequency to grow significantly, but not without limit. The current HTML5 sim only allows 10 coarse damping settings, and the lowest non-zero setting does not allow resonant standing waves to grow to amplitudes significantly larger than the oscillator amplitude. (At the lowest damping setting and High tension in the current sim, a pulse is reduced to less than 1/4 of its original height after 1 round trip on the string. In the old sim at Damping=1, that fraction was more like 80 or 90% of original.)

To demonstrate resonance with standing waves with significant amplitude in the current sim, I have to use zero damping, which means perturbations never die out, and (at resonance) waves grow without bound!

Perhaps a range of logarithmically-spaced damping values would be good?

[jonathanolson]

For the tension slider, we're going to make it look like the damping control (no interior ticks, same slider behavior), but going from 20% to 80%, with arrows adjusting by 5% and applying a squaring effect (keeping the min and max behaviors the same with the current version).

[jonathanolson]

Implemented the change above, @arouinfar can you see how it looks?

[arouinfar]

@jonathanolson the control itself look good, but something's still not right with the model. Tension should be proportional to the speed squared. (T = μv^2, where μ is the linear mass density of the string.)

If I assume the tension slider is linear, I'm seeing that tension is linearly proportional to speed. If I instead plot the tension vs. v^2, the data looks sort of linear, but a power series gives a better fit. The published version of the simulation has a power of 2 relationship between the tension tick marks. If I assume the same relationship here, tension increases exponentially with speed squared.

[jonathanolson]

I've added what I believe should show that effect above, can you check?

[arouinfar]

@jonathanolson I think that did the trick! The data now behaves as expected. The speed data is cleaner if I measure it using distance/time, so I will make that recommendation in the Teacher Tips. Wavelength measurements tend to have more error (especially at lower tension) due to the ruler's low precision.

[oliver-phet]

Documenting another email into phethelp:

Is it possible to have lower, non-zero values of damping for your "Waves on a string" simulation? We would like to demonstrate resonance, but the lowest available damping makes the steady-state amplitude at resonance only slightly larger than the amplitude midway between resonance frequencies.

[oliver-phet]

Documenting another email into phethelp:

I have a concern about the approach to damping as implemented in the Wave on a String 1.1.22 simulation. The simulation behaves very differently as compared to the legacy Flash version where damping is concerned. Specifically, the damping introduced by even the smallest non-zero setting is too strong (certainly stronger than was the case in the legacy version).

The basis for this claim is that, in the past with the legacy version, it was possible to have students explore resonant behaviour by mapping the standing wave amplitude as a function of frequency with a small amount of damping included. However, the current version applies so much damping at even the smallest non-zero setting that no resonant behaviour is observed unless damping is turned off. For example, using settings of two fixed ends, medium tension, and zero damping, driving the string at a frequency of 0.25 Hz and a driving amplitude of 0.05 cm results in the expected resonant behaviour. But apply even one increment of damping and resonant behaviour vanishes almost instantly as if the amount of damping had become huge. That behaviour at the very least not consistent with the intuitive sense one would get from moving the damping slider by 1/10th of its maximum.

Applying less damping would allow for the exploration of the resonance curve, as could be once done with the legacy version. Given that no HTML5 version of the resonance simulation currently exists, this would be a valuable addition to the string simulation's capabilities.

[oliver-phet]

Documenting another email into phethelp:

The current, HTML5 version of Wave on a String doesn’t allow a truly tiny amount of damping (like the old flash version did).

When we set up standing waves on the string, for example with settings:

• oscillate, Amplitude 0.05 cm, and frequency 1.25 Hz
• Tension high
• fixed end

Setting Damping to None creates lovely standing waves—but they continue to slowly build until the wave peaks don’t fit in the browser view anymore.

Setting Damping to the smallest nonzero setting by contrast damps the motion so quickly that it’s hard to set up a satisfactory standing wave at all.

Consider adding a new, tiny damping amount; or changing the scaling for the damping slider to make it nonlinear so that the first choice is much smaller than currently. The old Flash version is a good model to compare to.

[oliver-phet]

Another user email:

Can anyone tell me a frequency I can use to demonstrate a harmonic standing wave? I tried 0.76 Hz to get the 2nd harmonic and it's close but not stable. Any help is appreciated!