migrate BicyclePumpNode to scenery-phet

[pixelzoom]

The Gas Properties design document description of the bicycle pump UI component (see screenshot below) points to "similar in States of Matter". I see STATES_OF_MATTER/BicyclePumpNode, but it's coupled to that sim. So we'll need to allocate a chunk of time to generalize it and move it to scenery-phet, so that I can use it in Gas Properties.

Assigning to me, @jbphet and @ariel-phet to discuss.

[ariel-phet]

@jbphet not to overload @chrisklus but I wonder if this might be a good reasonable scope intro to common code. Thoughts?

@kathy-phet is also interested in getting SOM republished before the school year, so we will want to set aside some time for that anyhow. You and I should probably discussed what needs to be done there.

[jbphet]

Porting this to common code would probably be a decent introduction for @chrisklus. We could have a short discussion with @pixelzoom, @chrisklus, and me to decide what generalization is needed and then I could support him during the work. The original port was done by Actual Concepts, then refined by me, and there are some things that could likely be simplified.

[jbphet]

I have a pretty clear list of what needs to be done on SOM to get it published, so we can discuss at any time. Probably the biggest effort is some generalization of the color scheme handling.

[ariel-phet]

Since we agree this would be a nice intro to common code for @chrisklus we will have @jbphet on this with him when @jbphet dives back into trying to get SOM republished

[pixelzoom]

@ariel-phet I need this sometime in the next couple of weeks.

[ariel-phet]

@chrisklus lets get this back on your radar. Definitely higher priority than the dispose work you have been doing with Saurabh, so feel free to forgo that for this work.

[pixelzoom]

Heads up! The pump in Gas Properties deviates from the pump in SOM. I don't fully understand the implications of this yet, but here's the comment thread from the Gas Properties design doc:

@pixelzoom: How many particles are added? Are more particles added based on how far the handle moves? If so, what is the range of how many particles are added?

@arouinfar: In Java, the number depends on how far/fast the handle moves. I think we'll want similar behavior in HTML5. Perhaps an appropriate max number of particles/pump is 10-20% of the max number of particles. With the current ranges, that would be a maximum of 100-200 particles/pump. We can confirm the exact number in design meeting.

@arouinfar: As a heads up, this is a deviation from the way bicyclePumpNode behaves in SOM, which always adds a set number of particles. When migrating the pump to common code, there will need to be options for either adding a set number or tying the number to the dynamics of the handle.

[arouinfar]

Beat me to it, thanks @pixelzoom.

I think we'll need to have some design discussion about how the dynamics of the handle should affect the number of particles added, so I'll open an issue in gas-properties for that.

[pixelzoom]

@chrisklus Be sure to see related discussion over in https://github.com/phetsims/gas-properties/issues/33.

[pixelzoom]

I don't know how SOM implemented the pump. But in Gas Properties, I'm planning on having 1 pump for each type of particle ('heavy' and 'light'), then switching between them based on which type of particle is selected via radio buttons. Mockup from the design doc:

[chrisklus]

@pixelzoom do you know the approximate time when it would be nice for this to be done? I think it's going to take me a long time so I'm trying to plan out how much I should allocate per week (or day, if needed very soon).

[pixelzoom]

From the design document:

Milestones January 2019: Design progress will be included in grant report. If there is a workable dev, that might be included, but not required. January 2020: Grant report is due, so sim must be published

That doesn't give me any meaningful milestones for when we might need to show this to anyone outside of PhET. So let's ask @arouinfar: When do we need to show this sim to an audience outside of PhET? I'd like to have a working BicyclePumpNode around 2 weeks before that date.

[arouinfar]

@pixelzoom we don't necessarily need to show this sim to anyone outside of PhET. Occasionally, we like to show feature-complete (ideally close to rc) sims off at conferences. The only such conferences would be NSTA (April 11-14) or ISTE (June 23-26). I don't think it's a particularly realistic expectation for this sim to be feature complete by then. However, if you feel the first two screens would be ready, then you can use either of those conferences as a target for BicyclePumpNode.

[pixelzoom]

Thanks @arouinfar.

@chrisklus Let's shoot for completing this work by the end of March 2019. Does that seem reasonable?

[chrisklus]

Thanks @pixelzoom and @arouinfar, yes @pixelzoom that sounds great. @SaurabhTotey and I will continue to chip away, and I'll add in more time as needed.

I was originally concerned because of https://github.com/phetsims/states-of-matter/issues/217#issuecomment-438118562.

[pixelzoom]

@chrisklus said:

I was originally concerned because of https://github.com/phetsims/states-of-matter/issues/217#issuecomment-438118562.

That was before I implemented this barebones placeholder, which has allowed me to move forward:

[pixelzoom]

Mentioned at last week's dev meeting... We should discuss how the ends of the hose are attached -- to the pump, and to whatever is on the other end. I'm not sure if this should be the responsibility of BicyclePumpNode or the client. It would be nice to have a HoseNode (similar to WireNode) that makes this easy. And it should be possible to attach the hose to either side of the pump.

[pixelzoom]

In In https://github.com/phetsims/states-of-matter/issues/217#issuecomment-442283609, my WAG for when this would need to be completed was:

Let's shoot for completing this work by the end of March 2019. Does that seem reasonable?

In https://github.com/phetsims/states-of-matter/issues/217#issuecomment-442282755, @arouinfar indicated that it would be nice to show off this Gas Properties at NSTA (April 11-14) or ISTE (June 23-26), if the first 2 screens are ready. Given where it's at now, that's still a possibility. But as I said in https://github.com/phetsims/states-of-matter/issues/217#issuecomment-442277409:

I'd like to have a working BicyclePumpNode around 2 weeks before that date.

That means that this issue would need to be completed by April 4. @chrisklus is that possible?

[chrisklus]

That means that this issue needs to be completed by April 4. @chrisklus is that possible?

@pixelzoom yep! Good timing.

[kathy-phet]

:) ... Happy to hear its still possible to show off the first 2 screens by these upcoming conferences!

[pixelzoom]

@chrisklus FYI, see discussion about color-related parameters/options in https://github.com/phetsims/scenery/issues/962#issuecomment-480034075.

[chrisklus]

@pixelzoom I've been having a hard time fixing the buggy behavior of the "number of particles added per pump action" situation. Could you take a look at this patch?

```js Index: js/common/view/BicyclePumpNode.js IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- js/common/view/BicyclePumpNode.js (revision 781afefd5a64aef8419760510176fd71becde83d) +++ js/common/view/BicyclePumpNode.js (date 1554961489000) @@ -14,13 +14,13 @@ // modules const BooleanProperty = require( 'AXON/BooleanProperty' ); const Color = require( 'SCENERY/util/Color' ); + const DragListener = require( 'SCENERY/listeners/DragListener' ); const LinearGradient = require( 'SCENERY/util/LinearGradient' ); const Node = require( 'SCENERY/nodes/Node' ); const Path = require( 'SCENERY/nodes/Path' ); const Rectangle = require( 'SCENERY/nodes/Rectangle' ); const SegmentedBarGraphNode = require( 'STATES_OF_MATTER/common/view/SegmentedBarGraphNode' ); const Shape = require( 'KITE/Shape' ); - const SimpleDragHandler = require( 'SCENERY/input/SimpleDragHandler' ); const statesOfMatter = require( 'STATES_OF_MATTER/statesOfMatter' ); const Util = require( 'DOT/Util' ); const Vector2 = require( 'DOT/Vector2' ); @@ -90,8 +90,6 @@ // @private - used to track where the current position is on the handle when drawing its gradient this.handleGradientPosition = 0; - let currentPumpingDistance = 0; - // create the base of the pump const baseWidth = width * PUMP_BASE_WIDTH_PROPORTION; const baseHeight = height * PUMP_BASE_HEIGHT_PROPORTION; @@ -183,44 +181,10 @@ const maxHandleYOffset = pumpHandleNode.centerY; const minHandleYOffset = maxHandleYOffset + ( -PUMP_SHAFT_HEIGHT_PROPORTION * height / 2 ); - // How far the pump shaft needs to travel before the pump releases a particle. -1 is added to account for minor drag - // listener and floating-point errors. - const pumpingDistanceRequiredToAddParticle = ( -minHandleYOffset + maxHandleYOffset ) / - options.numberOfParticlesPerPumpAction - 1; - - pumpHandleNode.addInputListener( new SimpleDragHandler( { - - drag: event => { - - // the position at the start of the drag event - const handleStartYPos = pumpHandleNode.centerY; - - // update the handle and shaft position based on the user's pointer position - const dragPositionY = pumpHandleNode.globalToParentPoint( event.pointer.point ).y; - pumpHandleNode.centerY = Util.clamp( dragPositionY, minHandleYOffset, maxHandleYOffset ); - pumpShaftNode.top = pumpHandleNode.bottom; - - const travelDistance = handleStartYPos - pumpHandleNode.centerY; - if ( travelDistance < 0 ) { - - // This motion is in the downward direction, so add its distance to the pumping distance. - currentPumpingDistance += Math.abs( travelDistance ); - while ( currentPumpingDistance >= pumpingDistanceRequiredToAddParticle ) { - - // Enough distance has been traveled to inject a new particle. - if ( rangeProperty.value.max - numberProperty.value > 0 && options.enabledProperty.get() ) { - numberProperty.value++; - } - currentPumpingDistance -= pumpingDistanceRequiredToAddParticle; - } - } - else if ( travelDistance > 0 ) { - - // This motion is in the upward direction, so reset any accumulated pumping distance. - currentPumpingDistance = 0; - } - } - } ) ); + pumpHandleNode.addInputListener( + new HandleNodeDragListener( numberProperty, rangeProperty, options.enabledProperty, + minHandleYOffset, maxHandleYOffset, pumpHandleNode, pumpShaftNode, options.numberOfParticlesPerPumpAction ) + ); // create the node that will be used to indicate the remaining capacity const remainingCapacityIndicator = new SegmentedBarGraphNode( @@ -535,5 +499,74 @@ } } - return statesOfMatter.register( 'BicyclePumpNode', BicyclePumpNode ); + statesOfMatter.register( 'BicyclePumpNode', BicyclePumpNode ); + + /** + * Drag listener for the pump's handle. + */ + class HandleNodeDragListener extends DragListener { + + /** + * + * @param numberProperty + * @param rangeProperty + * @param enabledProperty + * @param minHandleYOffset + * @param maxHandleYOffset + * @param pumpHandleNode + * @param pumpShaftNode + * @param numberOfParticlesPerPumpAction + */ + constructor( numberProperty, + rangeProperty, + enabledProperty, + minHandleYOffset, + maxHandleYOffset, + pumpHandleNode, + pumpShaftNode, + numberOfParticlesPerPumpAction + ) { + + let handlePosition = null; + let lastHandlePosition = 0; + let pumpingDistanceAccumulation = 0; + + // How far the pump shaft needs to travel before the pump releases a particle. -1 is added to account for minor drag + // listener and floating-point errors. + const pumpingDistanceRequiredToAddParticle = ( -minHandleYOffset + maxHandleYOffset ) / + numberOfParticlesPerPumpAction - 1; + + super( { + drag: ( event, listener ) => { + + // update the handle and shaft position based on the user's pointer position + const dragPositionY = pumpHandleNode.globalToParentPoint( event.pointer.point ).y; + handlePosition = Util.clamp( dragPositionY, minHandleYOffset, maxHandleYOffset ); + pumpHandleNode.centerY = handlePosition; + pumpShaftNode.top = pumpHandleNode.bottom; + + const travelDistance = handlePosition - lastHandlePosition; + if ( travelDistance > 0 ) { + + // This motion is in the downward direction, so add its distance to the pumping distance. + pumpingDistanceAccumulation += travelDistance; + while ( pumpingDistanceAccumulation >= pumpingDistanceRequiredToAddParticle ) { + + // inject a particle + if ( rangeProperty.value.max - numberProperty.value > 0 && enabledProperty.get() ) { + numberProperty.value++; + } + pumpingDistanceAccumulation -= pumpingDistanceRequiredToAddParticle; + } + } + + lastHandlePosition = handlePosition; + } + } ); + } + } + + statesOfMatter.register( 'BicyclePumpNode.HandleNodeDragListener', HandleNodeDragListener ); + + return BicyclePumpNode; } ); ```

My intent is for it to handle the varying sizes of dx that come from different pumping speeds. And it does so pretty well for a limited range of speeds, but not well at all for fast speeds. Observe the behavior when numberOfParticlesPerPumpAction is 8 - at the fastest speed I can test, only 3 particles are added. Am I implementing this pattern incorrectly?

Maybe I'm going about this the wrong way and should instead calculate fixed points in the drag range where new particles should be added? Or something of that nature that isn't as reliant on getting drag events?

[pixelzoom]

@chrisklus I'll have a look, but it might not be until next week.

[pixelzoom]

@chrisklus and I collaborated on HandleNodeDragListener. It appears to be operating correctly, and there problem with number of particles added is in SOM.

Assign back to me when ready for next steps.

[pixelzoom]

For the purposes of connecting the hose to the container in Gas Properties, here's what that looks like in the design doc:

[chrisklus]

@pixelzoom ready for review.

In https://github.com/phetsims/gas-properties/issues/59, I integrated BicyclePumpNode (BPN) into Gas Properties, so check out that branch if you'd like. I moved the injection point down to where it is in the mockup.

In https://github.com/phetsims/scenery-phet/commit/cef194e3f713063ccd1c8dcdeef8e6bec6e325b2, I added a small constant to fix the calculation for numberOfParticlesPerPumpAction, because without it, SOM was pumping out 2 and Gas Props was pumping out 19 when set to 3 and 20, respectively. I tested various numbers between 1 and 30 and this constant appears to fix those cases.

I also added reset() that puts the handle back in the starting position, which SOM's implementation did not have.

There is no dispose yet, since I would think that BPNs will live for the life of the sim. Let me know if you disagree.

[pixelzoom]

I've integrated BicyclePumpNode into master. It was a little time-consuming because the changes in bicycle-pump branch contained lots of formatting changes, so it was a little difficult to identify the relevant changes. But I got it sorted out.

The first thing I noticed is the excessive touchArea for the pump handle. So I added options for pointer areas in the above commit:

        // pointer areas
        handleTouchAreaXDilation: 15,
        handleTouchAreaYDilation: 15,
        handleMouseAreaXDilation: 0,
        handleMouseAreaYDilation: 0

I set them to the old values in SOM/PhaseChangesScreenView:

146        handleTouchAreaXDilation: 100,
147        handleTouchAreaYDilation: 100

A few things that we need to work on:

• [x] (1) setHoseAttachmentPosition looks like it should be doable through options. Having to make a separate call is inconvenient.

• [x] (2) The API for setting the pump location and hose attachment position needs work. I should be able to set the location of the pump (e.g. bottom center of the base), then specify the offset of the hose attachment relative to the pump's location. Currently, I can't directly specify the pump location - I have to specify the offset of the hose attachment position (via options.hoseAttachmentOffset), then call a function to set the specify where that hose attachment position is (via setHoseAttachmentPosition), and then the pump location is derived from that.

• [x] (3) We're going to need some control over the shape of the hose. The current shape is a little too curvy for Gas Properties. If we can't come up with a general "look" that is acceptable, then we may need to add option(s) for control points.

• [x] (4) Changing options.height doesn't give me a bigger pump, it just scales the pump. So if I want a pump that is a little taller or short (by changing options.height) then the entire pump scales down, in all dimensions. So there's no way for me to have a longer handle, or a taller cylinder. This may be OK for now, but I don't think it's going to cut it longterm. I'd like to hear what designers (and especially @ariel-phet) have to say.

• [x] (5) The origin is in an inconvenient location, see red dot in the screenshot below. For coordinating positioning of the pump and the hose, centerBottom would be a better place for the origin. (EDIT: When running with ?dev, I've added a red dot at the origin.)

[pixelzoom]

In the above commits, I took care of (1) and (2). I eliminated setHoseAttachmentPosition. You position a pump using the typical scenery translation options. Then you provide options.hoseAttachmentOffset to indicate where the far end of the hose is, relative to the pump position. See example in SOM and Gas Properties. Here's a simplified version of GasPropertiesScreenView:

// Bicycle pump is centered above the radio buttons.
const bicyclePumpLocation = new Vector2( particleTypeRadioButtonGroup.centerX, particleTypeRadioButtonGroup.top - 30 );

// Bicycle pump hose attaches to the container.
const hoseLocation = model.modelViewTransform.modelToViewPosition( model.container.hoseLocation );

const heavyBicyclePumpNode = new BicyclePumpNode( ..., {
  translation: bicyclePumpLocation,
  hoseAttachmentOffset: hoseLocation.minus( bicyclePumpLocation ),
  ..
} );

Does this look acceptable?

[pixelzoom]

Re (3) shape of the hose...

If I change this line in BicyclePumpNode

173    .cubicCurveTo( 1.5 * ...

to this:

173    .cubicCurveTo( 0.75 * ...

.. then things look much better in Gas Properties (and arguably in SOM).

In Gas Properties, here's before (left, 1.5) and after (right, 0.75):

In SOM, here's before (left, 1.5) and after (right, 0.75):

We can either change this multiplier to 0.75, or add an option (name suggestions?)

[chrisklus]

You position a pump using the typical scenery translation options. Then you provide options.hoseAttachmentOffset to indicate where the far end of the hose is, relative to the pump position. Does this look acceptable?

Yep, that looks great, thanks for making the change.

Re (3) shape of the hose... ...add an option (name suggestions?)

Indeed, I was thinking we might need to expose the control points with options. It seems like the desired values will vary depending on the distance that the hose extends away from the pump. But, given your demonstration in https://github.com/phetsims/states-of-matter/issues/217#issuecomment-488205854, it seems like we gain a fair amount of flexibility with changing just that one multiplier (instead of messing with 2-4 control point values). What do you think about something like (best name I can think of so far):

hoseCurvynessMultiplier: 1 // {number} - greater value = curvy hose, smaller value = straighter hose

(4) Changing options.height doesn't give me a bigger pump, it just scales the pump. So if I want a pump that is a little taller or short (by changing options.height) then the entire pump scales down, in all dimensions. So there's no way for me to have a longer handle, or a taller cylinder. This may be OK for now, but I don't think it's going to cut it longterm. I'd like to hear what designers (and especially @ariel-phet) have to say.

Right, yeah this was the way the pump was originally coded - I'm not crazy about it either. I could remove all of those multiplier constants at the beginning of the file, replace all of the drawings with absolute numbers (instead of calculated percentages), and then expose a few dimensions via options?

e.g.

handleWidth: 200,
handleHeight: 30,
bodyHeight: 450

(5) The origin is in an inconvenient location, see red dot in the screenshot below. For coordinating positioning of the pump and the hose, centerBottom would be a better place for the origin. (EDIT: When running with ?dev, I've added a red dot at the origin.)

Whoops, looks like I was a little off when redrawing the components to position the whole node from the center bottom. I'll correct this to be the true center bottom.

[pixelzoom]

hoseCurvynessMultiplier: 1

That sounds fine.

I could remove all of those multiplier constants at the beginning of the file, replace all of the drawings with absolute numbers (instead of calculated percentages), and then expose a few dimensions via options?

Check with @ariel-phet or some of the designers. If the designers are happy with size/proportions of the pump in Gas Properties, I'm happy for now. If we were going to do this, I would recommend options handleWidth, handleHeight, bodyWidth, bodyHeight, then scale the bottom piece based on bodyWidth.

Whoops, looks like I was a little off when redrawing the components to position the whole node from the center bottom. I'll correct this to be the true center bottom.

Let me know what the difference is, so I can adjust Gas Properties. Remember to do the same in SOM.

[pixelzoom]

hoseCurvynessMultiplier: 1

Whoops, that's spelled wrong, should be hoseCurvinessMultiplier. Or just hoseCurviness would probably be fine.

And you should probably verify that hoseCurvinessMultiplier behaves correctly when the hose attachment point is below the pump's origin.

[chrisklus]

And you should probably verify that hoseCurvinessMultiplier behaves correctly when the hose attachment point is below the pump's origin.

yeah i'm betting it won't ha...

[pixelzoom]

Hmmm, why is this issue closed? Reopening.

[chrisklus]

Oops, probably me by mistake, thanks.

[pixelzoom]

Nope, it was me 6 days ago. Doh!

[chrisklus]

I've added hoseCurviness as an option, and to my surprise, it worked well when the bike pump was above the hose attachment point. If the bike pump is too close in the x-direction then the hose overlaps with the pump base, but I verified that that can be fixed by just increasing the hoseCurviness value.

I also updated the SOM usage to the previously used value and @pixelzoom's preference for Gas Properties.

[pixelzoom]

@chrisklus hoseCurviness looks great, thanks for doing that. Do we need an assertion to verify that it's > 0?

Another thing we need related to BicyclePumpNode is a demo on SCENERY_PHET/ComponentsScreenView.

[pixelzoom]

Self-unassigning. Feel free to assign back to me when there's more to review.

Reducing priority to medium, since this is now usable in GP and SOM.

Remaining work is items (4) and (5) in https://github.com/phetsims/states-of-matter/issues/217#issuecomment-488186493. Item (5) is probably the more important to address sooner rather than later.

[pixelzoom]

@chrisklus we're having some problems with BicyclePumpNode over in https://github.com/phetsims/gas-properties/issues/62.

From https://github.com/phetsims/gas-properties/issues/62#issuecomment-489337799, another thing we need to look at:

The other odd thing that I've discovered about BicyclePumpNode is that it will only add particles one at a time. That's going to be generally problematic in this sim, because we want to add groups of particles simultaneous, with a gaussian distribution of initial temperature values, so that we don't end up with "waves" of particles.

The problematic code is:

// inject a particle
if ( rangeProperty.value.max - numberProperty.value > 0 && enabledProperty.get() ) {
  numberProperty.value++;
}

For Gas Properties, we need something like numberProperty.value += numberAddedOnThisDrag.

Does SOM require adding particles one at a time?
Do we need to add an option that determines how numberProperty is modified?

[chrisklus]

Does SOM require adding particles one at a time?

Yes, I think it would be weird if we changed the behavior to match what you're requesting for Gas Properties. Perhaps @arouinfar would have more thoughts on this.

Do we need to add an option that determines how numberProperty is modified?

Yeah, that sounds like the best way to go.

we need something like numberProperty.value += numberAddedOnThisDrag

There's some room for variation here - how do you want me to implement it? Here's some options I've thought about:

1. We could add the "acquired" particles at the end drag event. But if you pumped the handle up an down repeatedly, all of the particles would be added at once at the end, instead of at the end of each pumping motion.

2. We could add the acquired particles when the handle is in the same place for two drag events in a row. This probably wouldn't happen that naturally, and would likely result in a similar behavior to (1).

3. We could add the acquired particles when the handle reaches the "closed" end of its range. This could be nice, but a user probably shouldn't be required to drag the handle all the way down to add particles before starting another drag motion.

4. We could add the acquired particles whenever the handle changes direction to an upwards motion. This option makes the most sense to me, as the user is given the control to define how large of a drag they want per pumping motion, and particles are added immediately at the end of that pumping motion.

   UPDATE: This should also include whenever the handle is not going down, so that the particles are still added when a pumping motion is stopped by the bottom of the pump (instead of having to move the handle up again in order to add the particles).

   The code for that could look something like this:

if ( this.lastHandlePosition !== null ) {
  const travelDistance = handlePosition - this.lastHandlePosition;
  if ( travelDistance > 0 ) {

    // This motion is in the downward direction, so add its distance to the pumping distance.
    pumpingDistanceAccumulation += travelDistance;
    if( options.addParticlesOneAtATime ) {
      while ( pumpingDistanceAccumulation >= pumpingDistanceRequiredToAddParticle ) {

        // inject a particle
        if ( rangeProperty.value.max - numberProperty.value > 0 && enabledProperty.get() ) {
          numberProperty.value++;
        }
        pumpingDistanceAccumulation -= pumpingDistanceRequiredToAddParticle;
      }
    }
  }

  // This motion is in the upward direction or the motion has stopped
  else {
    if( !options.addParticlesOneAtATime ) {
      numberProperty.value += Util.roundSymmetric( pumpingDistanceAccumulation / pumpingDistanceRequiredToAddParticle );
    }
    pumpingDistanceAccumulation = 0;
  }
}

[chrisklus]

@pixelzoom I tried out option (4) from https://github.com/phetsims/states-of-matter/issues/217#issuecomment-490162681, and the behavior is looking nice. I'm also no longer seeing any particles sticking at the hose attachment point (as described in https://github.com/phetsims/gas-properties/issues/62#issue-440271129).

I added nested options for the drag listener - let me know if you think that is unnecessary or too much exposure.

[pixelzoom]

(4) results in very odd behavior.

Example 1:

1. Grab the pump handle.
2. Pull the pump handle up, then push the pump handle 90% of the way down.
3. Stop for 5 seconds, do not release the pump handle. Nothing comes out of the pump.
4. Pull the pump handle up. Particles come out of the pump.

Example 2:

1. Grab the pump handle.
2. Pull the pump handle up, then push the pump handle 90% of the way down.
3. Stop for 5 seconds, do not release the pump handle. Nothing comes out of the pump.
4. Release the pump handle. Nothing comes out of the pump.

So waiting until the handle is pulled up is not a good strategy.

[pixelzoom]

I think the next thing we should do is add BicyclePumpNode to scenery-phet demo, so that we're testing it in a test harness, vs in a sim that may have problems.

[chrisklus]

Yeah I'm confused why my edit to option (4) works for when the pump is all the way down but not stopped at an arbitrary place.

[chrisklus]

@pixelzoom I worked with @SaurabhTotey today and we finished (5) from https://github.com/phetsims/states-of-matter/issues/217#issuecomment-488186493 and updated the offset in your usage so that the pumps in Gas Properties are in the same place (the change was +11).

Remaining work for this issue:

• [x] fix the implementation from https://github.com/phetsims/states-of-matter/issues/217#issuecomment-490162681
• [ ] wait to hear from @ariel-phet about (4) in https://github.com/phetsims/states-of-matter/issues/217#issuecomment-488186493.
• [x] add BicyclePumpNode to scenery-phet demo

[chrisklus]

Yeah I'm confused why my edit to option (4) works for when the pump is all the way down but not stopped at an arbitrary place.

I understand now. When the pump handle is dragged all the way down, the drag listener is still firing because you typically drag your mouse past the bottom of the range, so the drag events know that the handle is not moving in a downward direction. But in @pixelzoom's examples in https://github.com/phetsims/states-of-matter/issues/217#issuecomment-490289661, the mouse is not moving, so there are no drag events after the most recent downward motion.

Any ideas on how to handle this @pixelzoom?

[arouinfar]

Does SOM require adding particles one at a time?

Yes, I think it would be weird if we changed the behavior to match what you're requesting for Gas Properties. Perhaps @arouinfar would have more thoughts on this.

I'm not sure, actually. I know the model for SOM can't handle a sudden influx of particles, which is why the BicyclePumpNode only adds a max of 3 particles/pump. That said, I don't know if anything bad would happen if all 3 of those particles were added at the same time. From a pedagogical perspective, adding the particles simultaneously would be just fine. From a model perspective, I don't know. That'd be a question from @jbphet.

[pixelzoom]

@chrisklus in the above commit I changed how option addParticlesOneAtATime is handled. I also moved the default for dragListenerOptions into HandleNodeDragListener constructor. This seems to be working nicely in both SOM and GP. Review and let me know if you see any issues.

I'm still seeing one particle get stuck where it enters the container at the hose. See screenshot below. No idea why this is happening and it's intermittent. Any ideas?

[pixelzoom]

I said:

This seems to be working nicely in both SOM and GP.

Guess I have to eat my words. Temperature in the GP container is still behaving erratically and I'm not sure why.