# GasLab Gravity Box

### 1 collaborator

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 238 times • Downloaded 48 times • Run 3 times

## 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 effect of gravity on gas particles. It is very similar to GasLab Atmosphere, but with a "ceiling" over the gas, so particles can never escape.

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

The exact way two particles collide is as follows:

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.

In this model the particles behave exactly as in the basic Gas in a Box model except for now gravity acts on the particles. Every particle is given additional velocity downward during each tick, as it would get in a gravitational field. The particles bounce off the "ground" as well as the ceiling.

## HOW TO USE IT

Initial settings:

• GRAVITY: strength of the gravitational acceleration
• NUMBER-OF-PARTICLES: number of gas particles
• INIT-PARTICLE-SPEED: initial speed of each particle
• PARTICLE-MASS: mass of each particle

Other settings:

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

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

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 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.
• HEIGHT VS. TEMPERATURE: shows the temperature of the particles at each 'layer' of the box.
• DENSITY HISTOGRAM: shows the number of particles at each 'layer' of the box, i.e. its local density.
• AGGREGATE TEMPERATURE: shows the aggregate sum of the HEIGHT VS. TEMPERATURE plot for the entire model run.

## THINGS TO NOTICE

Try to predict what the view will look like after a while, and why.

Watch the gray path of one particle. What can you say about its motion?

Watch the change in density distribution as the model runs.

As the model runs, what happens to the average speed and kinetic energy of the particles? If they gain energy, where does it come from? What happens to the speed and energy distributions?

What is the shape of the path of individual particles?

What happens to the aggregate temperature plot over time? Is the temperature uniform over the box?

## THINGS TO TRY

What happens when gravity is increased or decreased?

Change the initial number, speed and mass. What happens to the density distribution?

Does this model come to some sort of equilibrium? How can you tell when it has been reached?

Try and find out if the distribution of the particles in this model is the same as what is predicted by conventional physical laws.

Try making gravity negative.

Varying model parameters such as NUMBER and GRAVITY, what do you observe about the aggregate temperature graph? Can you explain these results? How would you square these results with a) the fact that "hot air rises" in a room and b) that it is colder as you go higher in elevation?

## EXTENDING THE MODEL

Try this model with particles of different masses. You could color each mass differently to be able to see where they go. Are their distributions different? Do the different masses tend to have different average heights? What does this suggest about the composition of an atmosphere?

This basic model could be used to explore other situations where freely moving particles have forces on them --- e.g. a centrifuge or charged particles (ions) in an electrical field.

## NETLOGO FEATURES

Because of the influence of gravity, the particles follow curved paths. Since NetLogo models time in discrete steps, these curved paths must be approximated with a series of short straight lines. This is the source of a slight inaccuracy where the particles gradually lose energy if the model runs for a long time. (The effect is as though the collisions with the ground were slightly inelastic.) The inaccuracy can be reduced by increasing `vsplit`, but the model will run slower.

## RELATED MODELS

This model is part of the GasLab suite and curriculum. See, in particular, Gas in a Box and GasLab Atmosphere.

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

This model was created 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.

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
aggregate-list                              ;; list of the sums of the temperature at each height
]

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
;; box has constant size...
set box-edge (max-pxcor)
;; make floor
ask patches with [ pycor = min-pycor ]
[ set pcolor yellow ]
make-particles
make-box
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
[ if collide? [check-for-collision] ]
ifelse (trace?)
[ ask particle 0 [ pen-down ] ]
[ ask particle 0 [ pen-up ] ]
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 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

to bounce  ;; particle procedure  ;; get the coordinates of the patch we will be on if we go forward 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
[ stop ]

;; if hitting the top or bottom, reflect heading around y axis
if (new-py = max-pycor or new-py = min-pycor )

[ sprout-flashes 1 [
set color pcolor - 2
set birthday ticks
]
]
end

to move  ;; particle procedure
;; In other GasLab models, we use "jump speed * tick-delta" to move the
;; turtle the right distance along its current heading.  In this
;; model, though, the particles are affected by gravity as well, so we
;; need to offset the turtle vertically by an additional amount.  The
;; easiest way to do this is to use "setxy" instead of "jump".
;; Trigonometry tells us that "jump speed * tick-delta" is equivalent to:
;;   setxy (xcor + dx * speed * tick-delta)
;;         (ycor + dy * speed * tick-delta)
;; so to take gravity into account we just need to alter ycor
;; by an additional amount given by the classical physics equation:
;;   y(t) = 0.5*a*t^2 + v*t + y(t-1)
;; but taking tick-delta into account, since tick-delta is a multiplier of t.
setxy (xcor + dx * speed * tick-delta)
(ycor + dy * speed * tick-delta - gravity-acceleration * (0.5 * tick-delta * tick-delta))
factor-gravity
end

to factor-gravity  ;; turtle procedure
let vx (dx * speed)
let vy (dy * speed) - (gravity-acceleration * tick-delta)
set speed sqrt ((vy ^ 2) + (vx ^ 2))
recolor
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

;; 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 * 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
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)) ]
]

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

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

;;;
;;; drawing procedures
;;;

;; draws the box

to make-box
ask patches with [ count neighbors != 8 ]
[ 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 random-xcor random-float (world-height - 3) + 1
end

to draw-energy-graph
let n min-pycor
repeat (max-pycor / 2)
[ let x particles with [ (pycor >= n) and (pycor < (n + 4)) ]
ifelse count x = 0
[ plot 0 ]
[ let temperature mean [ energy ] of x
plot temperature
let list-pos (n + max-pycor) / 4
set aggregate-list (replace-item list-pos aggregate-list ((item list-pos aggregate-list) + temperature))
]
set n n + 4
]
end

to draw-aggregate-graph [lst]
foreach lst
[ plot ? ]
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

```

There are 15 versions of this model.

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 13 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky over 13 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky over 13 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky over 13 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky over 13 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky over 13 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky over 13 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky over 13 years ago Updated from NetLogo 4.1 Download this version
Uri Wilensky over 13 years ago Model from NetLogo distribution Download this version
Uri Wilensky over 13 years ago Model from NetLogo distribution Download this version
Uri Wilensky over 13 years ago GasLab Gravity Box Download this version

## Attached files

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

This model does not have any ancestors.

This model does not have any descendants.