Oscillatory spiking in capacitors

[samreid]

From #784 (comment)

First, in this video (the resistance is 0.0 ohm), you will see the capacitors not appearing to reach a steady state solution when connected across a battery.

In my testing in dev.52, I do see a steady state solution reached soon. I'm not sure if I had the same battery voltage or capacitances in your test, since they were not reported. I'm using default values for capacitance, and a 120V battery in this test.

However, notice the oscillation in the voltage graph. That is new in dev.52 (not present in dev.48) and looks buggy.

And then when the capacitors are shorted, they should fully discharge, but appear to retain charge and have a voltage across them

I saw it go to 0.0V but still showed some charge.

Likely this could be solved with a different tolerance in the voltage-to-charge mapping, but we should understand the oscillation behavior first.

For the 2nd video, I'm seeing all the same behaviors in dev.48 (the first QA dev test, before we changed any signs), so presumably that buggy behavior predates any sign changes in this issue. So perhaps I'll move that aspect to a new issue.

So this issue will be about correcting the buggy oscillation behavior in the capacitors. Or, we have the option of reverting the changes in this issue and going back to a dev.48 behavior which did not have the buggy oscillation.

[samreid]

Or, we have the option of reverting the changes in this issue and going back to a dev.48 behavior which did not have the buggy oscillation.

I am seeing the same spiking oscillatory behavior in dev.48:

[samreid]

In yesterday's meeting, we wondered if this issue relates to #787 .

In Java, I'm seeing a spike but no oscillation. Could this be why we require the initial bias calculation?

Java has different values for wire resistance and default capacitances, maybe that explains it?

[samreid]

@arouinfar and I discussed that shorting capacitors is somewhat nonphysical, and that the behavior is as expected as soon as the resistance is 0.1 ohms or higher. Therefore this doesn't need to be addressed for RC.1. @arouinfar confirmed this is already documented in the teacher tips. We may not ever fix this ourselves with our hand-written model, but maybe leave this open in case we explore spice or another model implementation.