GasLab Gas in a Box

GasLab Gas in a 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 147 times • Downloaded 11 times • Run 1 time
Download the 'GasLab Gas in a 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 in a closed box, or a container with a fixed volume. The path of single particle is visualized by a gray colored trace of the particle's most recent positions.

This model is part of the Connected Mathematics "Making Sense of Complex Phenomena" Modeling 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 (speed less than 5), green for medium (above 5 and below 15), and red for high speeds (above 15).

The basic principle of all GasLab models, including this one, is the following algorithm:

  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.
  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 particle is assigned its new velocity, energy, and heading.
  6. If a particle finds itself on or very close to a wall of the container, it "bounces" --- that is, reflects its direction and keeps its same speed.

HOW TO USE IT

Initial settings:

  • NUMBER-OF-PARTICLES: number of gas particles
  • INIT-PARTICLE-SPEED: initial speed of the particles
  • PARTICLE-MASS: mass of the particles
  • BOX-SIZE: size of the box. (percentage of the world-width)

The SETUP button will set the initial conditions.
The GO button will run the simulation.

Other settings:

  • TRACE?: Traces the path of one of the particles.
  • COLLIDE?: Turns collisions between particles on and off.

Monitors:

  • FAST, MEDIUM, SLOW: numbers of particles with different speeds: fast (red), medium (green), and slow (blue).
  • AVERAGE SPEED: average speed of the particles.
  • AVERAGE ENERGY: average kinetic energy of the particles.

Plots:

  • SPEED COUNTS: plots the number of particles in each range of speed.
  • SPEED HISTOGRAM: speed distribution of all the particles. The gray line is the average value, and the black line is the initial average.
  • ENERGY HISTOGRAM: distribution of energies of all the particles, calculated as m*(v^2)/2. The gray line is the average value, and the black line is the initial average.

Initially, all the particles have the same speed but random directions. Therefore the first histogram plots of speed and energy should show only one column each. 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. The histogram distribution changes accordingly.

THINGS TO NOTICE

What is happening to the numbers of particles of different colors? Does this match what's happening in the histograms? Why are there more blue particles than red ones?

Can you observe collisions and color changes as they happen? For instance, when a red particle hits a green particle, what color do they each become?

Why does the average speed (avg-speed) drop? Does this violate conservation of energy?

The particle histograms quickly converge on the classic Maxwell-Boltzmann distribution. What's special about these curves? Why is the shape of the energy curve not the same as the speed curve?

Watch the particle whose path is traced in gray. Does the trace resemble Brownian motion? Can you recognize when a collision happens? What factors affect the frequency of collisions? What about the how much the angles in the path vary? Can you get a particle to remain in a relatively small area as it moves, instead of traveling across the entire box?

THINGS TO TRY

Set all the particles in a region of the box to have the the same heading -- what happens? Does this correspond to a physical possibility?

Try different settings, especially the extremes. Are the histograms different? Does the trace pattern change?

Are there other interesting quantities to keep track of?

Look up or calculate the real number, size, mass and speed of particles in a typical gas. When you compare those numbers to the ones in the model, are you surprised this model works as well as it does? Try adjusting these variables in the model to better match the numbers you look up. Does this affect the outcome of the model? What physical phenomena might be observed if there really were a small number of big particles in the space around us?

EXTENDING THE MODEL

Could you find a way to measure or express the "temperature" of this imaginary gas? Try to construct a thermometer.

What happens if there are particles of different masses? (See GasLab Two Gas model.)

What happens if the collisions are non-elastic?

How does this 2-D model differ from a 3-D model?

Set up only two particles to collide head-on. This may help to show how the collision rule works. Remember that the axis of collision is being randomly chosen each time.

What if some of the particles had a "drift" tendency -- a force pulling them in one direction? Could you develop a model of a centrifuge, or charged particles in an electric field?

Find a way to monitor how often particles collide, and how far they go between collisions, on the average. The latter is called the "mean free path". What factors affect its value?

In what ways is this idealization different from the idealization that is used to derive the Maxwell-Boltzmann distribution? Specifically, what other code could be used to represent the two-body collisions of particles?

If more than two particles arrive on the same patch, the current code says they don't collide. Is this a mistake? How does it affect the results?

Is this model valid for fluids in any aspect? How could it be made to be fluid-like?

NETLOGO FEATURES

Notice the use of the histogram primitive.

Notice how collisions are detected by the particles and how the code guarantees that the same two particles do not collide twice. What happens if we let the patches detect them?

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/)

Wilensky, U. (2003). Statistical mechanics for secondary school: The GasLab modeling toolkit. International Journal of Computers for Mathematical Learning, 8(1), 1-41 (special issue on agent-based modeling).

Wilensky, U., Hazzard, E & Froemke, R. (1999). GasLab: An Extensible Modeling Toolkit for Exploring Statistical Mechanics. Paper presented at the Seventh European Logo Conference - EUROLOGO '99, Sofia, Bulgaria

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:

  • Wilensky, U. (1997). NetLogo GasLab Gas in a Box model. http://ccl.northwestern.edu/netlogo/models/GasLabGasinaBox. Center for Connected Learning and Computer-Based Modeling, Northwestern Institute on Complex Systems, Northwestern University, Evanston, IL.
  • Wilensky, U. (1999). NetLogo. http://ccl.northwestern.edu/netlogo/. Center for Connected Learning and Computer-Based Modeling, Northwestern Institute on Complex Systems, Northwestern University, Evanston, IL.

COPYRIGHT AND LICENSE

Copyright 1997 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 was created as part of the project: CONNECTED MATHEMATICS: MAKING SENSE OF COMPLEX PHENOMENA THROUGH BUILDING OBJECT-BASED PARALLEL MODELS (OBPML). The project gratefully acknowledges the support of the National Science Foundation (Applications of Advanced Technologies Program) -- grant numbers RED #9552950 and REC #9632612.

This model was developed at the MIT Media Lab using CM StarLogo. See Wilensky, U. (1993). Thesis - Connected Mathematics: Building Concrete Relationships with Mathematical Knowledge. Adapted to StarLogoT, 1997, as part of the Connected Mathematics Project. Adapted to NetLogo, 2002, as part of the Participatory Simulations Project.

This model was converted to NetLogo as part of the projects: PARTICIPATORY SIMULATIONS: NETWORK-BASED DESIGN FOR SYSTEMS LEARNING IN CLASSROOMS and/or INTEGRATED SIMULATION AND MODELING ENVIRONMENT. The project gratefully acknowledges the support of the National Science Foundation (REPP & ROLE programs) -- grant numbers REC #9814682 and REC-0126227. Converted from StarLogoT to NetLogo, 2002.

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
  box-edge                                   ;; distance of box edge from axes
  init-avg-speed init-avg-energy             ;; initial averages
  avg-speed avg-energy                       ;; current averages
  fast medium slow                           ;; current counts
  percent-slow percent-medium percent-fast   ;; percentage of current counts
]

breed [ particles particle ]
breed [ flashes flash ]
flashes-own [birthday]

particles-own
[
  speed mass energy          ;; particle info
  last-collision
]

to setup
  clear-all
  set-default-shape particles "circle"
  set-default-shape flashes "plane"
  set max-tick-delta 0.1073
  ;; the box size is determined by the slider
  set box-edge (round (max-pxcor * box-size / 100))
  make-box
  make-particles
  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 percent-medium (medium / ( count particles )) * 100
  set percent-slow (slow / (count particles)) * 100
  set percent-fast (fast / (count particles)) * 100
  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] ]
  ifelse (trace?)
    [ ask particle 0 [ pen-down ] ]
    [ ask particle 0 [ pen-up ] ]
  tick-advance tick-delta
  if floor ticks > floor (ticks - tick-delta)
  [
    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 when we advance the
  ;; tick counter. As particles jump (speed * tick-delta) each time, making
  ;; tick-delta 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 

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 a wall, we don't need to do any further checks
  if not shade-of? yellow [pcolor] of new-patch
    [ stop ]
  ;; if hitting left or right wall, reflect heading around x axis
  if (abs new-px = box-edge)
    [ set heading (- heading) ]
  ;; if hitting top or bottom wall, reflect heading around y axis
  if (abs new-py = box-edge)
    [ set heading (180 - heading)]

  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 ]
end 

;; creates initial particles

to make-particles
  create-particles number-of-particles
  [
    setup-particle
    random-position
    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 * speed)
  set last-collision nobody
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))
end 

;; histogram procedure

to draw-vert-line [ xval ]
  plotxy xval plot-y-min
  plot-pen-down
  plotxy xval plot-y-max
  plot-pen-up
end 

to-report last-n [n the-list]
  ifelse n >= length the-list
    [ report the-list ]
    [ report last-n n butfirst the-list ]
end 


; Copyright 1997 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 6 years ago Updated to NetLogo 5.0.4 Download this version
Uri Wilensky over 6 years ago Updated version tag Download this version
Uri Wilensky over 6 years ago Updated to version from NetLogo 5.0.3 distribution Download this version
Uri Wilensky over 7 years ago Updated to NetLogo 5.0 Download this version
Uri Wilensky almost 9 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 9 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 9 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 9 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 9 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 9 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 9 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 9 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky almost 9 years ago Model from NetLogo distribution Download this version
Uri Wilensky almost 9 years ago Model from NetLogo distribution Download this version
Uri Wilensky almost 9 years ago GasLab Gas in a Box Download this version

Attached files

File Type Description Last updated
GasLab Gas in a Box.png preview Preview for 'GasLab Gas in a Box' about 6 years ago, by Uri Wilensky Download

This model does not have any ancestors.

This model does not have any descendants.