Change pressure noise algorithm to be more realistic.

[pixelzoom]

Related to https://github.com/phetsims/gas-properties/issues/236 ...

@matthew-blackman will lead this. @pixelzoom will review.

[pixelzoom]

The implementation looks OK, straightforward.

What I have been concerned with is having to revisit the behavior, and the time that's going to take.

From model.md (which also needs to be updated):

On each time step, pressure is computed precisely as P = NkT/V. The pressure gauge is given a bit of "noise" to make it look more realistic. The noise is a function of pressure and temperature. More noise is added at lower pressures, but the noise is suppressed as temperature decreases. Noise is disabled when pressure is being held constant. See PressureGauge if you'd like more specifics. If desired, noise can be disabled via query parameter pressureNoise=false.

The new implementation of noise is based only on pressure. Noise is no longer suppressed as temperature increases. MAX_NOISE was deleted, which had been tuned by committe in https://github.com/phetsims/gas-properties/issues/92.

Is the new behavior of pressure noise significantly different? Is it acceptable to the design team? I can't tell. At the very least, we'll need sign-off from @arouinfar and @kathy-phet.

[pixelzoom]

Reviewed briefly with @arouinfar and here are the concerns that came up. @arouinfar please correct/augment.

• Is the behavior of noise in a pressure gauge really Gaussian?
• If it is Gaussian, the width of the Gaussian should change with temperature.
• If students plug the values from pressureKilopascalsNoiseProperty(the pressure with noise added) into PV = nRT, they'll find that the temperature values displayed are inaccurate, because the thermometer view does not include noise. Is this something we want to expose?
• Is learning about the noise behavior of a pressure gauge relevant to this sim's learning goals? Is this change worth having to revisit this feature, which involves several people? The original intention of this feature was to add a bit of visible jiggle to the meter, not to plot that jiggle and try to learn something from it.

[matthew-blackman]

@arouinfar and I had a follow-up discussion on the above points and came to the following agreements:

• The noise we are representing in the pressure sensor is caused by the random variables that affect the sensor - vibrations in the room, fluctuations in electrical signals, and any other sources of uncertainty that may arise. Since these are truly random variables, the result will be a Gaussian distribution. This is the simplest model of instrument uncertainty, and aligns will with the learning goals of the data fluency work.
• @arouinfar and @ariel-phet were receptive to the idea of designing an overarching model for instrument noise that is consistent across all sims. We felt that the noise of the sensor should be related to its instrument uncertainty, which is generally a fixed value dependent on the precision of the instrument. This is consistent with the specifications of real gas pressure sensors, shown below:
• We did not feel that there was any need to include noise in the thermometer. @arouinfar, @ariel-phet and I agree that the numbers do not need to work out perfectly in PV=nRT if the data is being taken from sensors with noise. In a real lab, this equation would not always work out perfectly either given the measurement uncertainty, which makes this behavior useful for students to encounter.
• This work is relevant to the data fluency learning goals, and allows us to include this sim as part of the data fluency deliverables. Now that the measurements are visible in CODAP, it makes sense to spend a small effort making the model as accurate and consistent with the learning goals as possible.

[pixelzoom]

@matthew-blackman @arouinfar Let's discuss this.

Problems:

(1) Was https://github.com/phetsims/gas-properties/commit/c77e004b4f498e7ddad4a9fad79edbd83eeecd36 tested? When I add particles to the container, the sim fails validation of pressureKilopascalsNoiseProperty immediately after a particle contacts a wall, because the temperature is negative. Adding this assertion indicates that noise is negative:

        noise = dotRandom.nextGaussian() * 100;
+       assert && assert( noise >= 0, `invalid noise: ${noise}` );

(2) Using dotRandom.nextGaussian is getting the next Gaussian-distributed random number from the same Random instance that is used throughout the sim for other randomness in the sim (e.g. particle positions) and common code. That will almost certainly affect the distribution that you're getting for the pressure model. Have you tested with CODAP to verify that you're getting the desired distribution? Should you be using a separate Random instance specifically for the noise?

(3) I don't understand why the amount of noise is now dotRandom.nextGaussian() * 100 kPA ("constant uncertainty model"), unaffected by pressure or temperature. If I add 1 particle to the container with noise off, the pressure is 12kPa. With noise on, the pressure will now vary from [12,120] kPA. That seems like way too much noise.

(4) model.md has not been updated, as noted in https://github.com/phetsims/gas-properties/issues/245#issuecomment-2120954347.

[pixelzoom]

Perhaps you're assuming that nextGaussian returns a value in the range [0,1]? That's not the case. Read doc and see browser console tests below.

> phet.dot.dotRandom.nextGaussian()
1.153788985390105
> phet.dot.dotRandom.nextGaussian()
0.453536062809
> phet.dot.dotRandom.nextGaussian()
-0.03803220771840494

[pixelzoom]

Also noting that gas-properties and gases-intro have been broken in CT since https://github.com/phetsims/gas-properties/commit/c77e004b4f498e7ddad4a9fad79edbd83eeecd36 was pushed.

[matthew-blackman]

https://github.com/phetsims/gas-properties/commit/c77e004b4f498e7ddad4a9fad79edbd83eeecd36 was tested and is exhibiting behavior consistent with the most recent design consensus. We can certainly have a broader discussion about the amount of noise and the overall design of the noise, but the possibility of a negative pressure reading with variability was agreed to be realistic for ultra-low pressure values.

There is also the issue that the sim is combining a micro view of the particles with a macro view of the sensor, which can sometimes make things look odd but I think overall works okay.

Would removing the validators for pressureKilopascalsProperty and pressureAtmospheresNoiseProperty be sufficient to handle the CT errors? I'm not seeing anywhere else that these values need to be positive.

[pixelzoom]

https://github.com/phetsims/gas-properties/commit/c77e004b4f498e7ddad4a9fad79edbd83eeecd36 was tested

I can't run the sim, and neither can CT.

but the possibility of a negative pressure reading with variability was agreed to be realistic for ultra-low pressure values.

Who agreed to this?

Would removing the validators for pressureKilopascalsProperty and pressureAtmospheresNoiseProperty be sufficient to handle the CT errors? I'm not seeing anywhere else that these values need to be positive.

No, that is not acceptable because:

1. Pressure is not a negative quantity, regardless of whether it contains noise.
2. GaugeNode (common code) will show the needle going below the 0 tick mark.
3. The sim will display negative pressure values. If the goal here is to indeed be "realistic", that is impossible.

Please fix the algorithm so that pressure is not negative.

[arouinfar]

I haven't reviewed this behavior in detail, my discussion with @matthew-blackman in https://github.com/phetsims/gas-properties/issues/245#issuecomment-2123119656 was more about the Gaussian approach, in general, and removing the temperature dependence. We still need to decide on the Gaussian width and what to do about negative values. I agree with @pixelzoom -- negative pressures are problematic.

[pixelzoom]

This work has become too distuptive in main, blocking my progress. I've reverted the commits that have been made so far (linked above). Please continue your work in a branch.

[matthew-blackman]

@arouinfar @pixelzoom and I met and discussed the following:

• The existing pressure noise algorithm provides a good distribution for different mean pressure values, including those close to zero (see screenshot):

  

• We did not feel that a redesign of the pressure noise algorithm was necessary. The data looks realistic, and we did not feel that this behavior warranted additional scrutiny within the scope of the data fluency work.

• When implementing sensor noise into other sims, dotRandom should be used carefully to ensure that there is no overlap with other randomly seeded values.

Feel free to close this issue if that is all.

[pixelzoom]

Thanks for the nice summary @matthew-blackman.

Closing.