Light Bulb stays lit during short circuit

[ariel-phet]

A twitter user pointed out that in the Java version during a short circuit the bulb stays lit (confusing to students). This is incorrect and should be addressed in the HTML5 version. See screenshot below, in this scenario the short circuit electrons are moving quickly and the bulb side are frozen (as they should be) but the bulb is still lit.

@samreid please be aware of this issue as you are dealing with the "fire" code. Not sure if it is still a problem or not.

[samreid]

If I understand correctly, for an ideal battery, the introduction of a short circuit doesn't change the voltage or current through the light bulb. What does change is that the simulation is now running at reduced speed (to prevent strobe effect of electron motion). Hence it appears the electrons aren't moving through the light bulb (and it says speed reduced to <1% normal), but the electrons are moving at the same speed (just the sim is in extreme slow motion). Reassigned to @ariel-phet and @arouinfar for discussion.

[ariel-phet]

@samreid there is a conflict here:

1. an ideal battery would also not catch fire (no internal resistance, so no reason to heat up)

2. We are trying to depict the real world...especially in a basics version, allowing students to see the effects of a short circuit seems an important learning goal (for instance the twitter user specifically pointed out the students were confused the bulb stayed lit in this situation).

Not sure of the correct solution here, but the bulb staying lit in this situation is problematic as it does not reflect what happens in the real world.

[arouinfar]

We had another user write into phethelp about this same issue:

I am an education student at Towson University and I noticed a problem with one of the simulations, the Circuit Construction Kit (DC) only, which shows that the lightbulbs will light up even when there is an alternate circuit where they wouldn't show up. I think this could cause some confusion for students, so I figured I would mention it.

This is something we'll clearly need to address, though I'm conflicted. I'm not convinced that this behavior is wrong (though certainly confusing). In an ideal short, the current through the bulbs would be zero. However the wires do have some internal resistance, so while the current through the bulbs is negligible compared to the current through the short, it is non-zero and the bulbs remain lit.

I think the real confusion arises from the reduction in animation speed. The electrons do not appear to move through the bulbs, though there is still a non-zero current.

We can chat more about it at design meeting.

[arouinfar]

@samreid will play with the animation speed limit so that the electrons through the bulb do not appear frozen.

[samreid]

Here's what happens with the naive approach:

[samreid]

The circuit dynamics assume that no electron can go around 2 corners or more in one time step (and time is slowed down enough to make this so). When we limit the amount the speed can be reduced, (say to 10% or so), the electrons in the short circuit get bunched up. I tried subdividing the dt by 100 and running it 100 times, but this is computationally demanding and still did not have the correct behavior (not subdivided enough). We could look into physics that allows electrons to go around multiple corners per frame, but that will also be computationally demanding. Or we could discuss other ways of addressing this problem. @arouinfar what do you think?

[arouinfar]

@samreid let's discuss during design meeting. I think we'll want to avoid computationally demanding features wherever possible. Perhaps we can make a compromise and turn off the light bulb when shorted?

Suppose these circuits are both in the play area and use the default bulb. The circuit on the right is shorted, so the animation speed is reduced. The electrons through both bulbs will appear frozen, but the light bulb that is connected to the short would no longer light up.

[arouinfar]

Discussed in 6/1/17 design meeting.

For 1.0, the behavior is fine as-is, as it does no harm over the Java version.

To reduce the animation speed of the shorted electrons, we would need to model a current-limited battery (or one that has an internal resistance that scales with the current). We could consider this for 1.1+.

[arouinfar]

I'll also need to document consequences of an ideal battery in the teacher's tips.

[samreid]

Reopening based on the changes in #676. We would like to try reverting the changes in this issue to see if it is already covered by #676.

[samreid]

I removed the code that changes the battery internal resistance when a current is exceeded, and observed that the light bulb still lit up in this case:

However, when I specified: wireResistivity=1E-11&batteryMinimumResistance=1E-6 then it was correct:

Since we were leaning towards these lower values, I'll go ahead and commit, but we are considering changing the values further in #676 and we'll need to make sure this case is still handled by the new values.

[samreid]

Committed, @arouinfar can you please test this in a few cases?

[arouinfar]

@samreid I tested several circuits in #676 (comment). The compromise is that we won't be able to completely turn off the bulb in all situations without turning the internal resistance up high enough to see numerical artifacts, but for most reasonable circuits the bulb will go out.

[samreid]

It sounds promising, but I wanted to clarify if this issue can be closed (i.e. without a battery current threshold that increases its resistance).

[arouinfar]

I'm comfortable closing this issue @samreid. Under normal circumstances (standard batteries with standard bulbs, high-V batteries with high-R bulbs), the bulb will not stay lit when shorted.

[samreid]

Reopening and marking for cherry-picking.

[phet-steele]

Looks good in phetsims/qa/issues/633.