GasLab Maxwells Demon

GasLab Maxwells Demon preview image

1 collaborator

Uri_dolphin3 Uri Wilensky (Author)


(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 369 times • Downloaded 50 times • Run 0 times
Download the 'GasLab Maxwells Demon' modelDownload this modelEmbed this model

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


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 illustrates a famous thought experiment, which raised important issues about the nature of entropy. In 1871, James Clerk Maxwell imagined a situation where a very small and nimble being could, by opening and closing a valve between two gas-filled chambers, allow only faster particles to go through one way and only slower particles to go through the other. By doing this, the being (later called a demon) could raise the temperature of one chamber (faster particles) and lower the temperature of the other (slower particles), without the expenditure of work. This was a violation of the Second Law of Thermodynamics, and he asserted that this could not actually occur. The implications of this puzzle have continued to be central to thermodynamics, entropy, and information theory up to the present time.


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 (NetLogo's View 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.

The setup is the same as that for the "Two-Gas" model. What is added is a "valve". It transports fast particles from the left to the right chamber when they arrive at the turquoise strip, and slow particles from the right to the left chamber when they arrive at the violet strip. When a particle passes through, it becomes larger for a short time and displays its speed.


NUMBER-OF-PARTICLES: total number of particles in the two chambers
INIT-PARTICLE-SPEED: initial speed of all the particles
PARTICLE-MASS: particles' mass

Other settings:
COLLIDE? If this is On, the particles collide. If it is Off, they do not collide.
THRESHOLD: The threshold is how much faster or slower than the average speed a particle must be going to be transferred to the other chamber by the "valve".
DEMON?: If this is On, the valve is operating. If it is Off, the valve does nothing.
TIME-DISPLAY-PARTICLES: determines for how long the particles are visually enlarged and their speeds are labeled, before the go back to their original size.

Initialize the model by pressing SETUP, and press GO to run it.

AVERAGE SPEED: average speed of all the particles.
AVERAGE SPEED LEFT: average particle speed in the left chamber.
AVERAGE SPEED RIGHT: average particle speed in the right chamber.

PARTICLES COUNT: the number of particles in the left (turquoise) and right (violet) chambers.
AVERAGE ENERGIES: the average energy of the particles in the left and right chambers. This is calculated as the average of 1/2 mv^2 for the particles.
AVERAGE SPEEDS: the average speeds of the particles in both the left and the right chambers.


Watch the "valve" carefully. Can you see fast (red) particles jump right and slow (blue) particles jump left when they run into the valve? They are enlarged and their speeds are labeled for a short time.

What happens to the average energies and speeds in the left and right chambers? Do the values settle down after a long time?

Notice the particles count in the two chambers. While the model starts out with more particles going into the right chamber than the left, this changes after a while. Why does that happen? Given the Maxwell-Boltzmann distribution, which chamber should have more particles?


Change the valve threshold. Does it change the rate of evolution of the model? Does it change its eventual result?


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

How would you calculate the pressure in each box? (See Piston models.) Do they remain equal?

If such a valve were possible, could "free energy" be gotten from the two chambers at different temperatures?

Another way of increasing order and later extracting energy might be to allow the valve to let through particles in only one direction, so that eventually one chamber is filled with gas, while the other one ends up empty. Can you create such a system?


Look at the other GasLab models.


This model was developed as part of the GasLab curriculum ( and has also been incorporated into the Connected Chemistry curriculum (


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 1997 Uri Wilensky.


This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. To view a copy of this license, visit 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

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

  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
  left-particles right-particles   ;; particles in the left and right chambers
  avg-speed-left avg-energy-left   ;; left chamber averages
  avg-speed-right avg-energy-right ;; right chamber averages
  avg-speed                        ;; average speed of all particles
  fast medium slow                 ;; current counts

breed [ particles particle ]
breed [ flashes flash ]

flashes-own [birthday]

  speed mass energy          ;; particle info

to setup
  set-default-shape particles "circle"
  set-default-shape flashes "plane"
  set max-tick-delta 0.1073
  ;; box has constant size...
  set box-edge (max-pxcor - 1)

to update-variables
  set left-particles particles with [xcor <= 0]
  set right-particles particles with [xcor > 0]
  if (not any? left-particles) or (not any? right-particles) [ stop ]
  set avg-speed-left     sum [speed] of left-particles   / count left-particles
  set avg-speed-right    sum [speed] of right-particles  / count right-particles
  set avg-energy-left    sum [energy] of left-particles  / count left-particles
  set avg-energy-right   sum [energy] of right-particles / count right-particles

  set avg-speed mean [speed] of particles

  set medium count particles with [color = green]
  set slow   count particles with [color = blue]
  set fast   count particles with [color = red]

to go
  ask particles [ bounce ]
  ask particles [ move ]
  if demon?
    [ ask particles [ maxwells-demon
                      ifelse (changed-size-ticks > 0)
                      [ set changed-size-ticks changed-size-ticks - 1 ]
                      [ set size 1 set label "" ]
  ask particles
  [ if collide? [check-for-collision] ]
  tick-advance tick-delta
  if floor ticks > floor (ticks - tick-delta)

  ask flashes with [ticks - birthday > 0.4]
    [ die ]

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 ticks tick. As
  ;; particles jump (speed * tick-delta) at every ticks 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 ]

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 ( [pcolor] of new-patch != yellow )
  ;; if hitting left or right wall, reflect heading around x axis
  if (abs new-px = box-edge or new-px = 0)
    [ 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

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

;;this is the piece that's different from other GasLab models.  It
;;creates a "valve" that moves molecules from one chamber to the other,
;; depending on their speed.  It also makes the particles larger for a time determined by the "time-
;; display-particles" slider

to maxwells-demon ;;particle procedure
  if ((pcolor = turquoise) and ((speed / threshold) > avg-speed))
     set size 3
     set label round speed
     set label-color yellow
     set xcor 2
     set changed-size-ticks time-display-particles

  if ((pcolor = violet) and ((speed * threshold) < avg-speed))

     set size 3
     set label round speed
     set label-color yellow
     set xcor -2
     set changed-size-ticks time-display-particles

to check-for-collision  ;; particle procedure
  ;; Here we impose a rule that collisions only take place when there
  ;; are exactly two particles per patch.

  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 ]

;; implements a collision with another particle.
;; 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 * v1t) + (v1l * v1l))
  set energy (0.5 * mass * speed * speed)
  ;; 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
  ask other-particle
    [ recolor ]

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

;;; 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)) or
                     ((abs pycor <= box-edge) and (pxcor = 0))]
    [ set pcolor yellow ]
  ;; Maxwell's Demon
  ask patches with [((pycor > -5) and (pycor < 5) and (pxcor = 1))]
    [ set pcolor violet ]
  ask patches with [((pycor > -5) and (pycor < 5) and (pxcor = -1))]
    [ set pcolor turquoise ]

;; creates initial particles

to make-particles
  create-particles number-of-particles

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
  set changed-size-ticks 0

;; 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))
  if round pxcor = 0

; 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 about 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 about 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky about 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky about 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky about 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky about 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky about 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky about 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky about 14 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky about 14 years ago Model from NetLogo distribution Download this version
Uri Wilensky about 14 years ago Model from NetLogo distribution Download this version
Uri Wilensky about 14 years ago GasLab Maxwells Demon Download this version

Attached files

File Type Description Last updated
GasLab Maxwells Demon.png preview Preview for 'GasLab Maxwells Demon' over 11 years ago, by Uri Wilensky Download

This model does not have any ancestors.

This model does not have any descendants.