Series ammeter completes a circuit or something?

[phet-steele]

I don't know how to explain this, just set up a similar situation on the Lab screen. Note the wire resistivity and battery voltage:

• The circuit is not complete, yet there is current
• The conventional current arrows do not agree on direction

@ariel-phet said not for AAPT

Seen in http://www.colorado.edu/physics/phet/dev/html/circuit-construction-kit-dc/1.0.0-dev.87/circuit-construction-kit-dc_en.html on Win 10 Chrome. For phetsims/QA#26.

[phet-steele]

If you are having trouble reproducing, try repeatedly disconnecting and reconnecting the battery from the ammeter.

[samreid]

I reduced the resistance to 0 in the above commit and it behaves much better, though https://github.com/phetsims/circuit-construction-kit-common/issues/391 is still a problem.

@phet-steele can you test this issue in this new dev version? http://www.colorado.edu/physics/phet/dev/html/circuit-construction-kit-dc/1.0.0-dev.97/circuit-construction-kit-dc_en.html

[phet-steele]

Looks great. Closing for now.

[BryceAG]

This crept up again in phetsims/QA#48. Also odd is how the arrows point in opposite directions randomly, and occasionally there is a blank spot across a component.

Here is an image that shows odd arrow directions and blank spots for an incomplete circuit:

And here is an image that shows the ammeter doesn't have to be connected to all parts of the circuit for arrows to appear. It does need to have one connection though:

[BryceAG]

Seems to (still?) be windows 10 chrome specific

[samreid]

Possible solutions:

1. increase the threshold at which current is rendered and animated. The threshold right now is 1E-6 amps. This would be the easiest solution to implement.
2. Add an explicit rule that incomplete loops will have current of 0.0. This would not address loops with voltage supplies adding up to zero. We would either have to add a separate algorithm to detect that case, or suffer bugs in that case.
3. Leave the current behavior as-is for 1.0 if we determine it is not too likely to cause problems in practice.

@arouinfar or @ariel-phet can you please advise?

[ariel-phet]

@phet-steele @BryceAG can you show a "minimum reproducible case"? Does it need this many batteries and such? Do you see this behavior with just 2 or 3 batteries?

[phet-steele]

Seems to (still?) be windows 10 chrome specific

I reproduced on macOS 10.12.6 Chrome, so not windows specific.

can you show a "minimum reproducible case"? Does it need this many batteries and such? Do you see this behavior with just 2 or 3 batteries?

@ariel-phet you only need 1 high-voltage battery that is at max voltage. Yo do not need an ammeter. Connect a wire to each end of the battery and a dog to one of the wires as shown below. You will likely have to make the wires short to see the issue; the arrows show up to a varying degree based on the wire length in the "circuit":

[brroberts1231]

Also reproduced on iPad iOS 9.3.5 (Bjork), so not specific to chrome either. Didn't need a dog either, just max voltage battery and two wires.

[BryceAG]

Able to reproduce on iPad 9.3.5 and 10.3.3 and windows 10 chrome with just one high voltage battery and one wire. Minumum required voltage of battery found was 11500 V, but needed a very short wire. Only works with some orientations. And at orientations where it doesn't work, having any object other than a battery on the screen (not connected) may make it work.

[ariel-phet]

@samreid can you help me understand what you think is going on here?

[samreid]

Modified nodal analysis works by setting up an equation Ax=z and solving for x (which contains unknown currents and voltages). A and z come from the characteristics of the circuit. You can see the matrices if you use this query parameter: ?debugModifiedNodalAnalysis. For the case of a high voltage battery plus one attached wire, we have:

A= 
0 0 1 0 0 0 
1 0 0 0 0 0 
0 -1 0 53660.280986207326 -53660.280986207326 0 
0 0 0 -53660.280986207326 53660.280986207326 0 
-1 1 0 0 0 0 
0 0 -1 0 0 1 
0 0 0 -1 0 1 

z = 
0 
0 
0 
0 
0 
100000 
0 

Our matrix solver gives this result for x:

7.786718186642893e-7 
0.0000015573436373285788 
6.825196439764652e-8 
100000.00000013651 
100000.00000013647 
100000.0000001365 

The resulting current is greater than the threshold of 1E-6 (see https://github.com/phetsims/circuit-construction-kit-dc/issues/96#issuecomment-328352082) so it is rendered in the animation.

3 possible solutions are identified in https://github.com/phetsims/circuit-construction-kit-dc/issues/96#issuecomment-328352082

[samreid]

When I tried plugging those matrices into http://www.bluebit.gr/matrix-calculator/solve.aspx it gave the more accurate solution:

     0.000
     0.000
     0.000
100000.000
100000.000
100000.000

I'm not sure what algorithm they are using or we are using.

[samreid]

It looks like for non-square matrices, dot is using QR decomposition to solve for x.

[samreid]

I asked @jonathanolson if he can take a look, since it would be great if we can solve this on the linear algebra side.

[samreid]

@jonathanolson discussed a bit and would like to discuss more. We aren't sure if there is another algorithm that will deal with this case well or not, but @jonathanolson recommended increasing the threshold for now to see if that's sufficient.

[samreid]

Turning up the wire resistance also alleviates this problem (if the wire is long enough).

[samreid]

Crazy hack idea: any unconnected vertices could get attached to an infinitely resistive synthetic wire?

[samreid]

I tried connecting a synthetic vertex to each battery and it did not seem to help. @jonathanolson recommended looking into 3rd party matrix solvers that may have better behavior for ill conditioned matrices (still using QR algorithm probably)

I tried changing the conventional current visibility from 1E-6 Amps to 1E-3 Amps and changing the current animation threshold from 1E-10 Amps to 1E-3 Amps and it seemed to alleviate these symptoms. I'm not sure why the motion was turned all the way down to 1E-10 previously--wondering if it could cause symptoms. I think I'll commit these changed thresholds for further testing.

[samreid]

I brought both thresholds to 1E-3 in the preceding commit. Worst case scenario is if someone can create a circuit that has numerical instability that puts one part of the circuit >1E-3 and another part at <1E-3 then the current will bunch up. I tried for a few minutes to create such a case but could not do so. So I think this solution is ready for @phet-steele @BryceAG and @brroberts1231 to review. It would be good to get this one reviewed sooner rather than later because it could have ramifications for the rest of testing.

Ready to test in master (no dev version).

[brroberts1231]

@samreid I kept playing around with this and it looks like it is at least fixed for open circuits. However, I still found ways of creating a circuit with some parts at 1E-3 A, and some <1E-3 A. Putting the dog, the eraser, and the dollar bill in parallel, with the 4 batteries at max voltage creates 1E-3 A through the batteries, which would be divided by 3 for the currents going through each object, making those below the threshold. This appears a bit misleading because in reality, there is an equal amount of current going through each object, but this essentially shows current only going to the dog.

[brroberts1231]

Playing around with the voltages and wire lengths in the above circuit, and also looking at a circuit with the hand, which has lower resistance, I was able to create these two cases where current is not the same on both sides of a loop. Wire resistivity is set to tiny in all 3 of these cases.

[samreid]

@ariel-phet and @arouinfar can you please review the problem and make a recommendation how to proceed?

[ariel-phet]

@samreid you found a matrix solver that gives the accurate solution, since that seems to be the culprit I would really like to solve this on the linear algebra side. I worry that fiddling with thresholds and hacky solutions are likely to introduce other potential edge cases.

I suggest trying a few 3rd party solvers to see if you can find one that gives better results as @jonathanolson had suggested earlier.

[ariel-phet]

@samreid according to wikipedia:

The Gram-Schmidt process is inherently numerically unstable. While the application of the projections has an appealing geometric analogy to orthogonalisation, the orthogonalisation itself is prone to numerical error. A significant advantage however is the ease of implementation, which makes this a useful algorithm to use for prototyping if a pre-built linear algebra library is unavailable.

Perhaps we are using Gram-Schmidt?

Perhaps we should see if there is a 3rd party solver using one of the other listed algorithms

1. Householder reflections

The use of Householder transformations is inherently the most simple of the numerically stable QR decomposition algorithms due to the use of reflections as the mechanism for producing zeroes in the R matrix. However, the Householder reflection algorithm is bandwidth heavy and not parallelisable, as every reflection that produces a new zero element changes the entirety of both Q and R matrices.

2. Givens rotations

The QR decomposition via Givens rotations is the most involved to implement, as the ordering of the rows required to fully exploit the algorithm are not trivial to determine. However, it has a significant advantage in that each new zero element affects only the row with the element to be zeroed and the row above.[clarification needed] This makes the Givens rotation algorithm more bandwidth efficient and parallelisable, in contrast to the Householder reflection technique.

[ariel-phet]

This appears to have an MIT license for instance:

https://github.com/scijs/ndarray-householder-qr-complex

[samreid]

@zepumph and I investigated numeric-1.2.6.js and discovered it only supports square matrices. We tried to use lalolib which describes itself as solving nonsquare matrices. We used this code:

//Matrix.js
    to2DArray: function() {
      return _.chunk( this.entries, this.m );
    },

        var a2 = array2mat(A.transpose().to2DArray());
        var z2 = array2mat(z.transpose().to2DArray());

        x = A.solve( z );

        var x2 = solve(a2,z2);

And it gave us near zeroes instead of the correct answers.

[samreid]

@jonathanolson said since this is an anaytical exact solution and not an approximation, the matrix should be square. I found that a redundant equation was being incorporated because in getEquations it has this rule:

// For each node, charge is conserved

Imagine that there is one wire with node 0 and node 1. Then current conservation at node 0 would be I_01 = -I_10. At node 1 there would be another equation I_10=-I_01. These are redundant. To remove the redundant equation, I choose the reference node in each connected subgraph and eliminate its current conservation equation. In my brief testing this yielded all square matrices and more accurate solutions (presumably LU is being used instead of QR).

[samreid]

I also put on fuzzMouse and didn't find any nonsquare matrices after about a minute.

[samreid]

The solution for https://github.com/phetsims/circuit-construction-kit-dc/issues/96#issuecomment-328608932 without the redundant equation:

x=
dim: 6x1
0 
0 
0 
10000 
10000 
10000 

It seems I should relax the thresholds and send this back to QA.

[samreid]

Restored thresholds in the aforementioned commit. This code also has a new assertion that the number of equations matches the number of unknowns, so you may run into new assertion errors in corner cases (though fuzzing hasn't found any yet). @BryceAG and @phet-steele can you please test this new implementation?

[jonathanolson]

Perhaps we are using Gram-Schmidt?

My checks yesterday showed that our ported JAMA code uses Householder reflections for QR.

[brroberts1231]

@samreid This appears better, but it's still possible to create situations where there is current shown going into something but no current coming out. Moving the dollar bill around will sometimes show current coming out of the left side, but sometimes shows this.

[BryceAG]

A more minimal use case example:

[samreid]

@arouinfar and @ariel-phet I'll need help figuring out what to do with the conventional current. If we have a threshold at which it becomes visible then it seems it will always be possible to create cases like the one in the preceding image where visible current is divided into invisible current (because the current gets cut below threshold).

[arouinfar]

@samreid if the conventional current is always visible (like electrons), I think things would look a bit odd at times. For example, it seems weird to show the conventional current arrows when pulling a circuit element out of the toolbox since the conventional current isn't really physical.

Perhaps a reasonable compromise would be to to show the conventional current whenever the circuit is complete, even if I=0. Is this possible to detect? If not, then I'd be willing to consider having the arrows always visible.

[samreid]

Which direction should the arrows point when I=0?

[arouinfar]

@samreid great question. Unfortunately, I don't have a great answer.

Can you detect which way the battery(ies) are oriented and predict which way the current would eventually point? This would work so long as all the batteries point in the same direction, but cases like this would be problematic:

Maybe you could instead always show the conventional current going in the counter-clockwise direction? Once I > 0, the arrows could flip if necessary? I have a feeling that the arrows may start to animate in the wrong direction and then flip once the current threshold is reached.

Actually, I don't like either option... just trying to throw some ideas out there.

Thinking about this a bit more, having the conventional current always visible (like the electrons) is inherently problematic, because the arrows imply a direction. What does it mean for a disconnected resistor to have a conventional current pointing to the left? It's completely non-physical.

Maybe @ariel-phet has some ideas?

[samreid]

To clarify: this issue comes down to 2 somewhat related problems:

1. The problem where current was depicted even though the circuit wasn’t complete. This comes from numerical inaccuracy in the linear algebra which was reduced but not eliminated by moving to LU when we eliminated the redundant equations.
2. The problem where we create conventional current above and below the visible threshold in one circuit

We need to solve both of these problems (the issue started talking about problem 1 but the latter several comments have been about problem 2).

[samreid]

In https://github.com/phetsims/QA/issues/48#issuecomment-329846175 @phet-steele requested another dev version after this issue regarding current is complete.

[ariel-phet]

@samreid what about scaling the transparency of conventional current. For instance, in the case shown in https://github.com/phetsims/circuit-construction-kit-dc/issues/96#issuecomment-329837923 the current everywhere "reads" zero on the current meter.

Perhaps below a certain current we fade conventional current out? I am thinking 0.015 A would be "full opacity" since that is the first place you can start to see the current arrows just barely creep along. Then below that and to the current threshold that we consider effectively "zero" we fade the arrows. Since they are not moving, it might be a nice cue that the current is effectively going to zero. I think then you also don't have as much of a current/no current binary representation. It is more measurable current. I would also then be less concerned about the arrows no showing in some cases, since they can be imagined to have faded to nearly invisible.

Would that be tough to try?

[ariel-phet]

@samreid I also think the transparency could help mitigate both issues from a UX point of view.

[arouinfar]

Perhaps below a certain current we fade conventional current out? I am thinking 0.015 A would be "full opacity" since that is the first place you can start to see the current arrows just barely creep along.

Love this idea @ariel-phet!!

@samreid is this something that we could test out?

[samreid]

Sounds good, I'll look into implementing it.

[samreid]

The above commit fades out conventional current between 0.015 Amps and 1E-6 Amps. It seemed nice in my brief testing, but it would be great if @arouinfar and @ariel-phet could test it out on phettest.

[arouinfar]

I like it @samreid! I wasn't able to reproduce any of the circuits with a partially-visible conventional current like https://github.com/phetsims/circuit-construction-kit-dc/issues/96#issuecomment-329837923, and I think the fade looks pretty good.

[ariel-phet]

I think this is working great, shows a just barely visible current at 0.001 A, and nothing when the current reads 0.00 A.

Closing since we all seem happy. Hopefully it does not cause performance concerns.