GasLab Pressure Box

GasLab Pressure Box preview image

1 collaborator

Uri_dolphin3 Uri Wilensky (Author)

Tags

(This model has yet to be categorized with any tags)
Model group CCL | Visible to everyone | Changeable by group members (CCL)
Model was written in NetLogo 5.0.4 • Viewed 224 times • Downloaded 41 times • Run 0 times
Download the 'GasLab Pressure Box' modelDownload this modelEmbed this model

Do you have questions or comments about this model? Ask them here! (You'll first need to log in.)


WHAT IS IT?

This model is one in a series of GasLab models. They use the same basic rules for simulating the behavior of gases. Each model integrates different features in order to highlight different aspects of gas behavior.

The basic principle of the models is that gas particles are assumed to have two elementary actions: they move and they collide - either with other particles or with any other objects such as walls.

This model simulates the behavior of gas particles trapped in a container with a fixed volume, such as inflating a bike tire. The number of particles in the box can be changed by adding particles through a valve on the side.

This model is part of the Connected Chemistry curriculum, which is part of the Modeling Across the Curriculum (MAC) Project.

HOW IT WORKS

The particles are modeled as hard balls with no internal energy except that which is due to their motion. Collisions between particles are elastic. Particles are colored according to speed --- blue for slow, green for medium, and red for high speeds.

Coloring of the particles is with respect to one speed (10). Particles with a speed less than 5 are blue, ones that are more than 15 are red, while all in those in-between are green.

Particles behave according to the following rules:

  1. A particle moves in a straight line without changing its speed, unless it collides with another particle or bounces off the wall.
  2. Two particles "collide" if they find themselves on the same patch (the world is composed of a grid of small squares called patches).
  3. A random axis is chosen, as if they are two balls that hit each other and this axis is the line connecting their centers.
  4. They exchange momentum and energy along that axis, according to the conservation of momentum and energy. This calculation is done in the center of mass system.
  5. Each turtle is assigned its new velocity, energy, and heading.
  6. If a turtle finds itself on or very close to a wall of the container, it "bounces" -- that is, reflects its direction and keeps its same speed.

Pressure is defined as the force per unit area (or length in this two-dimensional model). Pressure is calculated by adding up the momentum transferred to the walls of the box by the particles when they bounce off and divided by the length of the wall, which they hit.

Initially, the particles are not moving, and cannot hit the wall. Therefore the initial pressure is zero. As the particles start moving, they all first have the same speed in random directions. As the particles repeatedly collide, they exchange energy and head off in new directions, and the speeds are dispersed --- some particles get faster, some get slower.

HOW TO USE IT

Initial settings

  • BOX-SIZE: The size of the box as a percentage of the world-width
  • INITIAL-NUMBER-PARTICLES: the number of gas particles in the box when the simulation starts

The SETUP button puts in the initial conditions you have set with the sliders. Be sure to wait until the SETUP button stops before pushing GO.

The GO button runs the code again and again. This is a "forever" button.

Additional settings

COLLIDE?: determines whether or not the particles collide among themselves
ADD PARTICLES: pressing this button adds particles to the container through a valve, before and while the model is running
NUMBER-TO-ADD: number of particles that are added to the box with each press of the "ADD PARTICLES" button

Monitors

  • NUMBER OF PARTICLES: the number of particles in the box
  • PRESSURE: the pressure of the gas particles in the box
  • WALL HITS PER PARTICLE:
  • AVERAGE SPEED: average speed of the particles.
  • AVERAGE ENERGY: average kinetic energy of the particles.

Plots

  • PRESSURE: plots the pressure in the box
  • PARTICLE COUNT: plots the number of particles in the box
  • WALL HITS PER PARTICLE: plots the number of times a particle hits a wall every big tick

THINGS TO NOTICE

What is happening to the particles in the box as a new group of particles is injected? How is this related to the way pressure changes over time?

Can you observe collisions with the walls as they happen (you can pendown a particle or slow down the model)? For example, do the particles change their color? Direction?

Can you relate what you can see happening to the particles in the box with changes in pressure? The average speed? The average energy?

Why does the pressure fluctuate, even though the number of particles is the same? How long does it take for the pressure to stabilize? Does the number of particles in the box affect this time?

In what ways is this model an incorrect idealization of the real world?

THINGS TO TRY

Try different settings, especially the extremes. Are the particles behaving in a similar way? How does this effect the pressure? The energy?

How are the number of particles and the pressure in the box related to each other? Can you quantify this relationship? Does it change if collisions among particles are removed?

Does the same relationship hold for the number of wall hits per particle and the number of particles? Why? How are the two relationships connected?

Can you make the pressure graph smooth? Can you do it in more than one way?

The ideal gas equation shows that when keeping a constant temperature and volume, increasing the number of particles increases the pressure as well. Keeping a constant temperature means that the average kinetic energy of the particles, does not change, nor does their average speed. How is this related to the behavior of particles that you have seen so far? Are there any other observations that could be made to test this relationship between the number of particles and the pressure?

Notice that the pressure does not go up immediately after particles are added. What is the reason for this delay? Try adding particles into the box in different ways to increase or decrease this delay. Can you think of real-life situations, with a similar delay?

Sometimes, when going up in an elevator, airplane or up a mountain we feel a 'popping' sensation in our ears. This is associated with changes in pressure. Can you relate between this model and these changes in pressure? Are the temperature and volume constant in this situation?

EXTENDING THE MODEL

What would happen if particles were added continuously rather than instantly? Add a switch that allows for particles to continuously be added to the box.

Can you "puncture" the box, so that particles will escape?

What would happen if the box were heated? How would the particles behave? How would this affect the pressure? Add a slider and code that increases the temperature inside the box.

If you could change the shape of the box, so that the volume remains the same: Does the shape of the box make a difference in the way the particles behave, or the values of pressure?

CREDITS AND REFERENCES

This model was developed as part of the GasLab curriculum (http://ccl.northwestern.edu/curriculum/gaslab/) and has also been incorporated into the Connected Chemistry curriculum (http://ccl.northwestern.edu/curriculum/ConnectedChemistry/)

HOW TO CITE

If you mention this model in a publication, we ask that you include these citations for the model itself and for the NetLogo software:

COPYRIGHT AND LICENSE

Copyright 2002 Uri Wilensky.

CC BY-NC-SA 3.0

This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Commercial licenses are also available. To inquire about commercial licenses, please contact Uri Wilensky at uri@northwestern.edu.

This model and associated activities and materials were created as part of the project: MODELING ACROSS THE CURRICULUM. The project gratefully acknowledges the support of the National Science Foundation, the National Institute of Health, and the Department of Education (IERI program) -- grant number REC #0115699. Additional support was provided through the projects: PARTICIPATORY SIMULATIONS: NETWORK-BASED DESIGN FOR SYSTEMS LEARNING IN CLASSROOMS and/or INTEGRATED SIMULATION AND MODELING ENVIRONMENT -- NSF (REPP & ROLE programs) grant numbers REC #9814682 and REC-0126227.

Comments and Questions

Click to Run Model

globals
[
  tick-delta                         ;; how much we advance the tick counter this time through
  max-tick-delta                     ;; the largest tick-delta is allowed to be
  init-particle-speed particle-mass  ;; default particle settings
  box-edge                           ;; distance of box edge from axes
  pressure
  pressure-history
  wall-hits-per-particle     ;; average number of wall hits per particle
  length-horizontal-surface  ;; the size of the wall surfaces that run horizontally - the top and bottom of the box
  length-vertical-surface    ;; the size of the wall surfaces that run vertically - the left and right of the box

  init-avg-speed init-avg-energy  ;; initial averages
  avg-speed avg-energy            ;; current averages
  fast medium slow                ;; current counts

]

breed [ particles particle ]
breed [ flashes flash ]

flashes-own [birthday]

particles-own
[
  speed mass energy          ;; particle info
  wall-hits                  ;; # of wall hits during this cycle ("big tick")
  momentum-difference        ;; used to calculate pressure from wall hits
  last-collision
]

to setup
  clear-all
  set-default-shape particles "circle"
  set-default-shape flashes "plane"
  set init-particle-speed 10.0
  set particle-mass 1.0
  set max-tick-delta 0.1073
  ;; box size is determined by the slider
  set box-edge (round (max-pxcor * box-size / 100))
  ;;; the length of the horizontal or vertical surface of
  ;;; the inside of the box must exclude the two patches
  ;; that are the where the perpendicular walls join it,
  ;;; but must also add in the axes as an additional patch
  ;;; example:  a box with an box-edge of 10, is drawn with
  ;;; 19 patches of wall space on the inside of the box
  set length-horizontal-surface  ( 2 * (box-edge - 1) + 1)
  set length-vertical-surface  ( 2 * (box-edge - 1) + 1)
  make-box
  make-particles
  set pressure-history [0 0 0]  ;; plotted pressure will be averaged over the past 3 entries
  update-variables
  set init-avg-speed avg-speed
  set init-avg-energy avg-energy
  reset-ticks
end 

to update-variables
  set medium count particles with [color = green]
  set slow   count particles with [color = blue]
  set fast   count particles with [color = red]
  set avg-speed  mean [speed] of particles
  set avg-energy mean [energy] of particles
end 

to go
  ask particles [ bounce ]
  ask particles [ move ]
  ask particles
  [ if collide? [check-for-collision] ]
  tick-advance tick-delta
  if floor ticks > floor (ticks - tick-delta)
  [
    ifelse any? particles
      [ set wall-hits-per-particle mean [wall-hits] of particles ]
      [ set wall-hits-per-particle 0 ]
    ask particles
      [ set wall-hits 0 ]
    calculate-pressure
    update-variables
    update-plots
  ]
  calculate-tick-delta
  ask flashes with [ticks - birthday > 0.4]
    [ die ]
  display
end 

to calculate-tick-delta
  ;; tick-delta is calculated in such way that even the fastest
  ;; particle will jump at most 1 patch length in a tick. As
  ;; particles jump (speed * tick-delta) at every tick, making
  ;; tick length the inverse of the speed of the fastest particle
  ;; (1/max speed) assures that. Having each particle advance at most
  ;; one patch-length is necessary for it not to "jump over" a wall
  ;; or another particle.
  ifelse any? particles with [speed > 0]
    [ set tick-delta min list (1 / (ceiling max [speed] of particles)) max-tick-delta ]
    [ set tick-delta max-tick-delta ]
end 

;;; Pressure is defined as the force per unit area.  In this context,
;;; that means the total momentum per unit time transferred to the walls
;;; by particle hits, divided by the surface area of the walls.  (Here
;;; we're in a two dimensional world, so the "surface area" of the walls
;;; is just their length.)  Each wall contributes a different amount
;;; to the total pressure in the box, based on the number of collisions, the
;;; direction of each collision, and the length of the wall.  Conservation of momentum
;;; in hits ensures that the difference in momentum for the particles is equal to and
;;; opposite to that for the wall.  The force on each wall is the rate of change in
;;; momentum imparted to the wall, or the sum of change in momentum for each particle:
;;; F = SUM  [d(mv)/dt] = SUM [m(dv/dt)] = SUM [ ma ], in a direction perpendicular to
;;; the wall surface.  The pressure (P) on a given wall is the force (F) applied to that
;;; wall over its surface area.  The total pressure in the box is sum of each wall's
;;; pressure contribution.

to calculate-pressure
  ;; by summing the momentum change for each particle,
  ;; the wall's total momentum change is calculated
  set pressure 15 * sum [momentum-difference] of particles
  set pressure-history lput pressure but-first pressure-history
  ask particles
    [ set momentum-difference 0 ]  ;; once the contribution to momentum has been calculated
                                   ;; this value is reset to zero till the next wall hit
end 

to bounce  ;; particle procedure
  ;; get the coordinates of the patch we'll be on if we go forward 1
  let new-patch patch-ahead 1
  let new-px [pxcor] of new-patch
  let new-py [pycor] of new-patch

  ;; if we're not about to hit the edge of the wall, we don't need to do any further checks
  ;; note: we check the new coordinates, and not the color, to make sure particles
  ;; do not go into the nozzle
  if (abs new-px != box-edge and abs new-py != box-edge)
    [ stop ]
  ;; if hitting left or right wall, reflect heading around x axis
  if (abs new-px = box-edge)
    [ set heading (- heading)
      set wall-hits wall-hits + 1
  ;;  if the particle is hitting a vertical wall, only the horizontal component of the speed
  ;;  vector can change.  The change in velocity for this component is 2 * the speed of the particle,
  ;;  due to the reversing of direction of travel from the collision with the wall
      set momentum-difference momentum-difference + (abs (dx * 2 * mass * speed) / length-vertical-surface) ]
  ;; if hitting top or bottom wall, reflect heading around y axis
  if (abs new-py = box-edge)
    [ set heading (180 - heading)
      set wall-hits wall-hits + 1
  ;;  if the particle is hitting a horizontal wall, only the vertical component of the speed
  ;;  vector can change.  The change in velocity for this component is 2 * the speed of the particle,
  ;;  due to the reversing of direction of travel from the collision with the wall
      set momentum-difference momentum-difference + (abs (dy * 2 * mass * speed) / length-horizontal-surface)  ]

  ;; if we are at the entrance of the nozzle, do not make a flash
  if (new-py = 0 and new-px = (- box-edge))
    [stop]

  ask patch new-px new-py
  [ sprout-flashes 1 [
      set color pcolor - 2
      set birthday ticks
      set heading 0
    ]
  ]
end 

to move  ;; particle procedure
  if patch-ahead (speed * tick-delta) != patch-here
    [ set last-collision nobody ]
  jump (speed * tick-delta)
end 

to check-for-collision  ;; particle procedure
  ;; Here we impose a rule that collisions only take place when there
  ;; are exactly two particles per patch.  We do this because when the
  ;; student introduces new particles from the side, we want them to
  ;; form a uniform wavefront.
  ;;
  ;; Why do we want a uniform wavefront?  Because it is actually more
  ;; realistic.  (And also because the curriculum uses the uniform
  ;; wavefront to help teach the relationship between particle collisions,
  ;; wall hits, and pressure.)
  ;;
  ;; Why is it realistic to assume a uniform wavefront?  Because in reality,
  ;; whether a collision takes place would depend on the actual headings
  ;; of the particles, not merely on their proximity.  Since the particles
  ;; in the wavefront have identical speeds and near-identical headings,
  ;; in reality they would not collide.  So even though the two-particles
  ;; rule is not itself realistic, it produces a realistic result.  Also,
  ;; unless the number of particles is extremely large, it is very rare
  ;; for three or more particles to land on the same patch (for example,
  ;; with 400 particles it happens less than 1% of the time).  So imposing
  ;; this additional rule should have only a negligible effect on the
  ;; aggregate behavior of the system.
  ;;
  ;; Why does this rule produce a uniform wavefront?  The particles all
  ;; start out on the same patch, which means that without the only-two
  ;; rule, they would all start colliding with each other immediately,
  ;; resulting in much random variation of speeds and headings.  With
  ;; the only-two rule, they are prevented from colliding with each other
  ;; until they have spread out a lot.  (And in fact, if you observe
  ;; the wavefront closely, you will see that it is not completely smooth,
  ;; because some collisions eventually do start occurring when it thins out while fanning.)

  if count other particles-here = 1
  [
    ;; the following conditions are imposed on collision candidates:
    ;;   1. they must have a lower who number than my own, because collision
    ;;      code is asymmetrical: it must always happen from the point of view
    ;;      of just one particle.
    ;;   2. they must not be the same particle that we last collided with on
    ;;      this patch, so that we have a chance to leave the patch after we've
    ;;      collided with someone.
    let candidate one-of other particles-here with
      [who < [who] of myself and myself != last-collision]
    ;; we also only collide if one of us has non-zero speed. It's useless
    ;; (and incorrect, actually) for two particles with zero speed to collide.
    if (candidate != nobody) and (speed > 0 or [speed] of candidate > 0)
    [
      collide-with candidate
      set last-collision candidate
      ask candidate [ set last-collision myself ]
    ]
  ]
end 

;; implements a collision with another particle.
;;
;; THIS IS THE HEART OF THE PARTICLE SIMULATION, AND YOU ARE STRONGLY ADVISED
;; NOT TO CHANGE IT UNLESS YOU REALLY UNDERSTAND WHAT YOU'RE DOING!
;;
;; The two particles colliding are self and other-particle, and while the
;; collision is performed from the point of view of self, both particles are
;; modified to reflect its effects. This is somewhat complicated, so I'll
;; give a general outline here:
;;   1. Do initial setup, and determine the heading between particle centers
;;      (call it theta).
;;   2. Convert the representation of the velocity of each particle from
;;      speed/heading to a theta-based vector whose first component is the
;;      particle's speed along theta, and whose second component is the speed
;;      perpendicular to theta.
;;   3. Modify the velocity vectors to reflect the effects of the collision.
;;      This involves:
;;        a. computing the velocity of the center of mass of the whole system
;;           along direction theta
;;        b. updating the along-theta components of the two velocity vectors.
;;   4. Convert from the theta-based vector representation of velocity back to
;;      the usual speed/heading representation for each particle.
;;   5. Perform final cleanup and update derived quantities.

to collide-with [ other-particle ] ;; particle procedure
  ;;; PHASE 1: initial setup

  ;; for convenience, grab some quantities from other-particle
  let mass2 [mass] of other-particle
  let speed2 [speed] of other-particle
  let heading2 [heading] of other-particle

  ;; since particles are modeled as zero-size points, theta isn't meaningfully
  ;; defined. we can assign it randomly without affecting the model's outcome.
  let theta (random-float 360)



  ;;; PHASE 2: convert velocities to theta-based vector representation

  ;; now convert my velocity from speed/heading representation to components
  ;; along theta and perpendicular to theta
  let v1t (speed * cos (theta - heading))
  let v1l (speed * sin (theta - heading))

  ;; do the same for other-particle
  let v2t (speed2 * cos (theta - heading2))
  let v2l (speed2 * sin (theta - heading2))



  ;;; PHASE 3: manipulate vectors to implement collision

  ;; compute the velocity of the system's center of mass along theta
  let vcm (((mass * v1t) + (mass2 * v2t)) / (mass + mass2) )

  ;; now compute the new velocity for each particle along direction theta.
  ;; velocity perpendicular to theta is unaffected by a collision along theta,
  ;; so the next two lines actually implement the collision itself, in the
  ;; sense that the effects of the collision are exactly the following changes
  ;; in particle velocity.
  set v1t (2 * vcm - v1t)
  set v2t (2 * vcm - v2t)



  ;;; PHASE 4: convert back to normal speed/heading

  ;; now convert my velocity vector into my new speed and heading
  set speed sqrt ((v1t ^ 2) + (v1l ^ 2))
  set energy (0.5 * mass * speed ^ 2)
  ;; if the magnitude of the velocity vector is 0, atan is undefined. but
  ;; speed will be 0, so heading is irrelevant anyway. therefore, in that
  ;; case we'll just leave it unmodified.
  if v1l != 0 or v1t != 0
    [ set heading (theta - (atan v1l v1t)) ]

  ;; and do the same for other-particle
  ask other-particle [
    set speed sqrt ((v2t ^ 2) + (v2l ^ 2))
    set energy (0.5 * mass * (speed ^ 2))
    if v2l != 0 or v2t != 0
      [ set heading (theta - (atan v2l v2t)) ]
  ]



  ;; PHASE 5: final updates

  ;; now recolor, since color is based on quantities that may have changed
  recolor
  ask other-particle
    [ recolor ]
end 

to recolor  ;; particle procedure
  ifelse speed < (0.5 * 10)
  [
    set color blue
  ]
  [
    ifelse speed > (1.5 * 10)
      [ set color red ]
      [ set color green ]
  ]
end 


;;;
;;; drawing procedures
;;;

;; draws the box

to make-box
  ask patches with [ ((abs pxcor = box-edge) and (abs pycor <= box-edge)) or
                     ((abs pycor = box-edge) and (abs pxcor <= box-edge)) ]
    [ set pcolor yellow ]
  ;; make nozzle
  ask patches with [ pycor = 0 and pxcor < (1 - box-edge) ]
  [
    set pcolor yellow - 5  ;; trick the bounce code so particles don't go into the inlet.
    ask patch-at 0  1 [ set pcolor yellow ]
    ask patch-at 0 -1 [ set pcolor yellow ]
  ]
end 

;; creates initial particles

to make-particles
  create-particles initial-number-of-particles
  [
    setup-particle
    random-position
    recolor
  ]
  calculate-tick-delta
end 

;; adds new particles into the box from the left nozzle

to add-particles [n]
  if n > 0
    [ create-particles n
        [ setup-particle
          setxy (- box-edge) 0
          set heading 90 ;; east
          rt 45 - random-float 90
          recolor
        ]
      calculate-tick-delta
    ]
end 

to setup-particle  ;; particle procedure
  set speed init-particle-speed
  set mass particle-mass
  set energy (0.5 * mass * speed ^ 2)
  set last-collision nobody
  set wall-hits 0
  set momentum-difference 0
end 

;; place particle at random location inside the box.

to random-position ;; particle procedure
  setxy ((1 - box-edge) + random-float ((2 * box-edge) - 2))
        ((1 - box-edge) + random-float ((2 * box-edge) - 2))
  set heading random-float 360
end 


; Copyright 2002 Uri Wilensky.
; See Info tab for full copyright and license.

There are 15 versions of this model.

Uploaded by When Description Download
Uri Wilensky almost 11 years ago Updated to NetLogo 5.0.4 Download this version
Uri Wilensky over 11 years ago Updated version tag Download this version
Uri Wilensky over 11 years ago Updated to version from NetLogo 5.0.3 distribution Download this version
Uri Wilensky over 12 years ago Updated to NetLogo 5.0 Download this version
Uri Wilensky almost 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 14 years ago Model from NetLogo distribution Download this version
Uri Wilensky almost 14 years ago Model from NetLogo distribution Download this version
Uri Wilensky almost 14 years ago GasLab Pressure Box Download this version

Attached files

File Type Description Last updated
GasLab Pressure Box.png preview Preview for 'GasLab Pressure Box' about 11 years ago, by Uri Wilensky Download

This model does not have any ancestors.

This model does not have any descendants.