Total Energy is changing sporadically

[phet-steele]

@samreid @ariel-phet this is revealed via PhET-iO. It's very obvious every time the skater goes airborne; you can see the TE decrease. I'm sorry if the numbers are too small, the value you should be watching is blue and underneath the highlighted text.

[ariel-phet]

@samreid this bug would obviously be good to address before we deliver an iO version of the sim. In basics, I doubt it is causing any pedagogical damage since the exact energy never gets read out (but that will be possible to readout in an iO version)

[ariel-phet]

In addition, if we can identify a straightforward fix that would certainly be the ideal situation, and once a stable fix for html5 has been identified we should at least discuss the work involved to propagate the fix to the java full version of ESP

[samreid]

It seems unlikely that we will find a numerical algorithm that preserves energy conservation to full numerical precision of JS floating point numbers. Our algorithms are currently a precision/computation time tradeoff: if we make it run twice as slow, we could gain a bit more precision. I'm guesstimating here, but to get full JS precision, current algorithms may take several hours per frame? Some ideas: (a) shield the true floating point values behind "surrogates"--perform the computation on the true floating point numbers but when querying the model always round to the nearest 1E-2 Joules and make sure this value never changes. (b) may be a good problem to investigate or discuss with @jonathanolson or @veillette

@ariel-phet please advise

[ariel-phet]

@samreid isn't there a trick that can be played where the numbers are treated as integers and then displayed as some some divided and truncated number?

For example 365.115678 joules is actually 3651145678 integer value in the code, and only ever displayed as something like 365.1 Joules? So there are no rounding errors?

[ariel-phet]

I suppose part of what I am suggesting above is an algorithm that assumes discrete steps in energy change, where the smallest change possible is "1" (where "1" actually represents a small amount of energy perhaps 0.000001 joules or such)

[ariel-phet]

Also marking for dev meeting for a bit of brain storming

[andrewadare]

The change in @phet-steele's recording is

(5362.30195 - 5362.2996)/5362.30195 = 4.382446236081805e-7

In any model, deviations from mathematical perfection at small levels like this are normal and expected. Why is it a problem? The people looking at this output are primarily researchers, not students, correct? They should have enough sophistication to appreciate this.

[andrewadare]

I'd go a bit further beyond my previous comment and explicitly recommend not to sweep the full precision under the rug with some kind of representational coarsening or print formatting. I also think it's unfair to label this as a bug. Just as error bars on measured data points carry important and useful information, the runtime fluctuations on the total energy convey the precision of the model, which is impressively good.

[samreid]

Unassigning until after we discuss it further.

[veillette]

Pendulum-lab has a neat approach to keep the energy conserved.

The angle as a function of time is calculated using a Runge-Kutta approach, taking into account the friction force, the force of gravity.

All the energies are derived from the angle. There are three energies: Potential, kinetic, and friction.

• The potential energy can easily be obtained from the angle.
• The kinetic energy can be calculated by evaluating a numerical derivative to the angle.
• The energy dissipated through friction could be calculated in principle, it is friction force times displacement). At this point @jonathanolson just didn't bother. Instead, he assumed that the total energy is conserved in the first place and therefore works backward to find the friction energy.

In this way, the total energy is guaranteed to be conserved, because it is baked in.

A crucial point here: none of the calculations for the "derived" properties (energies) feeds back into the algorithm for the angle. In fact the RK algorithm itself does not guarantee that the energy will be conserved at every step. However as long as the error is minuscule (and it is), none is the wiser.

[veillette]

In a case where only kinetic and potential energies are present, then one could calculate the kinetic energy using the speed and then, using the fact that the total energy is conserved, work backward to find the potential energy PE=TE - KE.

It is preferable to work out the kinetic energy first because 1/2mv^2 guarantees that the KE is positive, whereas using KE= TE-PE, could potentially lead to negative values for the kinetic energy, due to some fp error.

[andrewadare]

Those are good suggestions. I'm not familiar with ESPB, as far as whether dissipative forces are modeled (seems unlikely).

The second suggestion pushes the inconsistency into the PE term, so it deviates from mgh at some small level. In my view it's a lateral step, and I guess it's a matter of preference.

[ariel-phet]

@andrewadare in regards to https://github.com/phetsims/energy-skate-park-basics/issues/355#issuecomment-242501400 it is not true this is only for researchers. If that were the case, we might consider not addressing.

However, this error was pointed out by a teacher in the original Java version of ESP, he was having his students take data in a table (something PhET-iO is specifically designed to do). It could be pedagogically very confusing if the entire point of the simulation is to stress the conservation of energy, and then total energy is changing. I agree a sophisticated discussion could involve the precision of models, but that may be beyond the scope of someone using this simulation in middle school/beginning high school.

[andrewadare]

@ariel-phet that makes sense. Sounds like the option to ignore/accept the inconsistency is out then (at least in quantities that are exposed to users).

[samreid]

If we are using floating point math for the Energy Skate Park: Basics model, then we must accept the limitations of floating point math. For instance, here is some JavaScript code adding one tenth to one fifth:

Asking for infinite precision seems problematic.

As @andrewadare said, computing PE as Total Energy - KE- Thermal is problematic because it could get out of sync with mgh, and it isn't possible to position the skater at an arbitrary height when it must travel along the spline.

[samreid]

In @phet-steele's video, it looks like the troublesome points are when the skater leaves the track--we investigate what is happening there. Conservation is easier in the air where the skater is not constrained to the spline.

[samreid]

@andrewadare volunteered to help investigate this when it's time.

[samreid]

Priority and timeline: @ariel-phet said we should investigate this before publishing and sharing a phet-io version. Doing soon may be good since QA time will be needed. We may want this ready in 3 months or so, then we should leave a 1-1.5 month buffer.

[andrewadare]

@ariel-phet asked me to document some of the things mentioned during the meeting:

• Because the PE term is not the dominant source of error, it probably should not be the place where "corrections" are applied (i.e. an additive quantity forcing the total energy to be constant).
• It's most likely that the error is mainly from numerically integrating the equations of motion, and @samreid said his experience corroborates that. Therefore, if corrections are needed, they should be applied to the KE term, (or specifically v).
• It was suggested that one way to force consistency is to try and solve the energy equation for v. But that would involve making invasive changes. There's been a large investment in testing this sim, and making nontrivial changes to the core numerics could easily introduce "ripple" bugs that are hard to track down, reproduce, and fix.
• Therefore, it may be most prudent/expedient to add refining "leap joules" to the KE term (or to the speed), either at each time step or at key places like the skater landing on the next ramp, where there might naturally be an inelastic interaction between bodies. This would preserve the carefully-tested code that computes the dynamics.

[samreid]

Therefore, if corrections are needed, they should be applied to the KE term, (or specifically v).

When the skater is near the top of the parabola, correcting the energy by modifying the velocity brings the skater to a halt. When the skater is at the bottom of the parabola (or where derivative is 0), height cannot be used to fine tune.

[samreid]

I'm wondering if this approach might work:

Keep all of the dynamics exactly as it is right now, but rename the variables to private (uninstrumented) inner variables. Then create 4 new energy variables: E, KE, PE, TE which are computed based on the private fluctuating inner variables and for which we guarantee consistency and constant E. These would be the variables that we use for showing the energy onscreen and for accessing over phet-io. I feel like there will still be errors somewhere (perhaps PE won't exactly equal mgh), but this way we can guarantee (a) E is constant and (b) that the dynamics won't be perturbed.

But as said before, the first thing to do will be to check if the problem is isolated to when the user leaves the track.

[oliver-phet]

We just had a report of a bug happening in Forces and Motion: Basics and, after Steele investigated, it appears to be caused by a similar issue. Marking for Dev meeting to discuss.

[jessegreenberg]

This issue will apply to both energy-skate-park and energy-skate-park-basics now.

[jessegreenberg]

Regarding https://github.com/phetsims/energy-skate-park/issues/164#issuecomment-242501400,

There are a number of heuristics used in this sim to attempt to conserve energy when the skater state changes. In many of these we ensure that total energy is only conserved within 1E-8 Joules.

[marlitas]

This is not within the scope of the upcoming character set publication. Marking as deferred.