## Wednesday, March 5, 2014

### SBG and Exam Scores

There are a variety of ways to deal with big summative assessments (final exams, etc.) in SBG. Because the scores on standards are the result of several assessments on each standard, work, reassessment, etc., I generally don't want my final exams to upturn (for good or ill) a term's worth of work - one day does not a term make. I do like the summative nature in this context, though, and the huge opportunity for including lots of connections between standards. The question is then just how to include these assessments in the students' grades in a way that reflects all of these realities and tries to (as always) make the grade represent student understanding as closely as possible.

For a while now, I've been counting the total grade from the standards as 80% of the term grade and the exam as 20%. You could adjust the ratio in a variety of ways, trying to give the exam 'teeth' or to not over-weight a single snapshot on a single day, but that's not the interesting part.

Before I switched to standards-based grading, my students' exam scores were fairly consistently lower than their grades going into the exams (you could say the same thing about any bigger assessment during the term, too). This led me to have some 'insurance' in the grade - participation, HW, etc. One of the reasons that I switched to SBG was that I felt like these sorts of components in the grade, which do not reflect student understanding, were muddling the meaning of the grade and were inflating student scores in order to arrive at a typical grade distribution.

Since I've switched to SBG, my students' exam scores and their grades going into the exam have become more and more correlated.

This year, almost no students had more than a 6 point discrepancy between their averages and their exam scores, and the differences were evenly distributed between higher and lower. My grade distribution is the same as it was before, but those grades represent a higher level of understanding than they did before, and my grades more accurately represent my students' understanding.

As I handed exams back today, some students were clearly nervous, asking the usual questions: "how were they?", "were the exams good?", etc. I reflexively started with some sort of answer, but then I just said it: "they correlated very closely with your grades going into the exams. ...do you know why?" First student answer: "because that's our level of understanding!"

That's all that I've ever wanted for a grading scheme. Well, that and giving actionable feedback, communicating learning as a priority, and motivating a drive for improvement.

## Monday, December 2, 2013

### Independent Friction Labs and Another Capstone Project

I have my Honors Physics students prepare small electronic posters for their final lab of the first term, the Independent Friction Lab. In this lab, students have to come up with an experiment, make an informal proposal, execute the experiment, and analyze the results.

The experiment really just needs to have something to do with friction, and I get a wide variety of them. I have them create a single PP or similar slide, sized 24"x18"; they're great to print at Staples. I ask them to email me a draft a day or so before the presentations, and they present the revised projects.
Here are a few of this year's experiments:

This group used a Pasco friction cart; they let it slide on a cart track, used the velocity graph to determine the coefficient of kinetic friction, and then determined the hanging mass that would pull the friction cart at constant speed (verifying that with another motion detector graph).

This group found the coefficient of static friction between a block and a ramp in a neat way: they used a half-Atwood setup, changing the mass until the block slipped, but performed that experiment at several angles. They then predicted a function for that maximum mass as a function of the block's known mass, the angle, and the unknown friction coefficient. Graphing their data, Logger Pro found the static friction coefficient by regression, providing both a quality value and confirmation of the model that they used to describe the situation.

These students compared the effective coefficients of friction for a ball rolling (without slipping) and the same ball under backspin (backspin persists until it turns around). They're essentially determining the coefficients of rolling and kinetic friction, showing that the kinetic friction coefficient's much larger.

This one seems to come up every year, and it's always fun. They used video analysis to determine the coefficient of kinetic friction between socks and several surfaces. The tricky unseen part is the big possible variation in normal force from foot to foot and moment to moment

A second AP Physics capstone project is also included here; the student was trying to model the interaction between a hockey stick and a puck. It ended up being a very difficult problem, but he gained some valuable ground and ended up with a functional scaled-back model.

Student work:

For my capstone project, I wanted to model the interaction between the blade of a hockey stick and the puck during a shot or pass in ice hockey. Using the ball and spring model of matter interactions, I created a VPython program where a constant force acts on the blade of the stick, but reverses direction at the center (0,0,0) to simulate the slowing down of the stick after reaching the midpoint where the x component of the force on the stick would be at its maximum. The force on the puck, however, does not follow the same constant pattern. Since materials act like springs with miniscule stretches, the force on the puck oscillates during the entire blade-puck interaction time even though the oscillation and resulting compression of the blade would be impossible to see with the naked eye. While this is not a perfect model since the blade remains at a constant angle, 90°, and the force magnitude remains constant in the direction of velocity and only changes direction by 180°, it does illustrate how matter interacts at the atomic scale. During the collision, both the force on the puck and the compression of the blade oscillate, but so slightly with the large spring constant that, looking at the velocity graph, the puck behaves like it would with a constant force and constant acceleration during contact.

 Screenshot at the moment of collision

 Graphs of the "spring" compression, force exerted on the puck, and velocity of the puck as functions of time

from __future__ import division
from visual.graph import*
from visual import*

#create objects
h=.025
puck=cylinder(pos=(1,0,0),radius=0.038, height=h, axis=(0,h,0), mass=.17, velocity=vector(0,0,0))

l=.76
R=vector(0,((2l)**2-puck.radius**2)**.5,0)
l=.02
beginpos=vector(puck.pos.x+puck.radius+l/2,puck.height,0)

stick=box(pos=beginpos, length=l, height=.076, width=0.3175, material=materials.wood, velocity=vector(0,0,0), mass=.7,)# axis=norm(R-beginpos)*.076, k=500000)

#R=vector(0,((2l)**2-stick.pos.x**2)**.5,)

scene.autoscale = False

#create forces

Fdirection=vector(-1,0,0)#norm(vector(-stick.axis.y, stick.axis.x,0))

Fmag=200

k= 10000#310575#414172.6

r=puck.pos+vector(puck.radius, puck.height/2,0)-stick.pos

s=stick.length/2-(stick.pos.x-puck.pos.x-puck.radius)  #stick.height/2-(r.mag)*cos(arctan(abs(stick.axis.y/stick.axis.x)))

Fp=vector(k*s*Fdirection)

Fs=Fmag*Fdirection

#graph
gd =gdisplay(x=0, y=0, width=600, height=150, title='Fp vs. t', xtitle='t (s)', ytitle='Fp (N)', foreground=color.black, background=color.white, xmax=.25, xmin=0, ymax=100, ymin=-100)

Fpg=gcurve(color=color.red, gddisplay=gd)

gd2 =gdisplay(x=0, y=0, width=700, height=150, title='compression vs. t', xtitle='t (s)', ytitle='Compression (m)', foreground=color.black, background=color.white, xmax=.25, xmin=0, ymax=.01,ymin=-.005)

sg=gcurve(color=color.green, gdisplay=gd2)

vg = gdisplay(x=0, y=0, width=600, height=150, title='v vs. t', xtitle='t (s)', ytitle='Puck Velocity (m/s)',foreground=color.black, background=color.white, xmax=.25, xmin=0, ymax=0,ymin=-30)

vg=gcurve(color=color.blue, display=vg)

print s
#create loop

t=0
dt=.00001

while t<.25:

rate(10000)

if s>0 and stick.pos.x>0:

#stick

stick.velocity.x=stick.velocity.x+Fs.x/stick.mass*dt

stick.pos.x=stick.pos.x+stick.velocity.x*dt

#     R=vector(0,((2*l)**2-stick.pos.x**2)**.5,0)

#        stick.axis=norm(R-stick.pos)*stick.length

#puck

puck.velocity.x=puck.velocity.x+Fp.x/puck.mass*dt

puck.pos.x=puck.pos.x+puck.velocity.x*dt

#s

r=puck.pos+vector(puck.radius, puck.height/2,0)-stick.pos

s=stick.length/2-(stick.pos.x-puck.pos.x-puck.radius)  #stick.height/2-(r.mag)*cos(arctan(abs(stick.axis.y/stick.axis.x)))

Fdirection=vector(-1,0,0)#norm(vector(-stick.axis.y, stick.axis.x,0))

Fp=vector(k*s*Fdirection)

Fs=Fmag*Fdirection-Fp

elif stick.pos.x>0:
#stick

stick.velocity.x=stick.velocity.x+Fs.x/stick.mass*dt

stick.pos.x=stick.pos.x+stick.velocity.x*dt

#        R=vector(0,((2*l)**2-stick.pos.x**2)**.5,0)

#        stick.axis=norm(R-stick.pos)*stick.length

#puck

puck.velocity.x=puck.velocity.x+Fp.x/puck.mass*dt

puck.pos.x=puck.pos.x+puck.velocity.x*dt

#s
r=puck.pos+vector(puck.radius, puck.height/2,0)-stick.pos

s=stick.length/2-(stick.pos.x-puck.pos.x-puck.radius)  #stick.height/2-(r.mag)*cos(arctan(abs(stick.axis.y/stick.axis.x)))

Fdirection=vector(-1,0,0)#norm(vector(-stick.axis.y, stick.axis.x,0))
Fp=vector(k*s*Fdirection)

Fs=Fmag*Fdirection

elif stick.pos.x<0: abs="" arctan="" cos="" fdirection="vector(1,0,0)#norm(vector(-stick.axis.y," fp.x="" fp="vector(k*s*-Fdirection)" fs="Fmag*Fdirection" if="" puck.height="" puck.pos.x="puck.pos.x+puck.velocity.x*dt" puck.velocity.x="puck.velocity.x+Fp.x/puck.mass*dt" puck="" r.mag="" r="puck.pos+vector(puck.radius," s="stick.length/2-(stick.pos.x-puck.pos.x-puck.radius)" stick.axis.x="" stick.axis.y="" stick.axis="norm(R-stick.pos)*stick.length" stick.height="" stick.pos.x="stick.pos.x+stick.velocity.x*dt" stick.pos="" stick.velocity.x="stick.velocity.x+Fs.x/stick.mass*dt">0:
Fp.x=0

if stick.velocity.x>0:
stick.velocity.x=0

if s<0: abs="" arctan="" cos="" else:="" fp.x="" fpg.plot="" pos="(t," pre="" print="" puck.pos.x="puck.pos.x+puck.velocity.x*dt" puck.velocity.x="" puck.velocity="" r.mag="" s="" sg.plot="" stick.axis.x="" stick.axis.y="" stick.height="" stick.velocity.x="" t="t+dt" vg.plot="">

## Wednesday, November 13, 2013

### Capstones! Gravitational Slingshot edition

My AP class does capstone projects at the end of each term. It's a short independent project, having to do with anything from the term, which they execute and present in such a way that we can post them here.

Here's the first of the crop of this fall's capstones: a VPython project simulating a gravity assist.

Student work:
The goal of my Capstone project was to create a program in VPython which simulates the gravitational slingshot used by satellites such as Voyager I or Cassini.  This method, officially called “gravity assist”, is used by space programs such as NASA to send probes to distant targets without draining resources since it uses the natural gravitational forces as ways to propel the probes into space.

In the program, I send a 15,000 kg probe into orbit around the Earth while also having the Moon orbit the Earth.  By adjusting the initial velocity of the probe, the probe would be able to pass by the moon and use the Moon’s gravitational force to “slingshot” it off to a “target” asteroid away from the Earth.  Finally, I graphed the speed of the probe during its journey and compared it to the velocity graph of Cassini.  The small boost in the graphs shows the moment the probe uses the gravitational slingshot, similar to the Cassini graph when it orbits around Venus.

Images:
 Cassini's speed graph (wikipedia)

 The program, after probe has made it to the target

 v graph from the program, showing the boost

Cassini Graph citation:

"Cassini's Speed Related to the Sun." Chart. Wikipedia. Wikimedia, n.d. Web. 12 Nov. 2013. .

Code (syntax highlighting finally works!):
    from __future__ import division
from visual.graph import*
from visual import*

#Richie Lou
#Gravitational Slingshot - CAPSTONE

#OBJECTIVE: to use a gravitational force to send a space shuttle from Earth's orbit
#to a target asteroid by using the moon as a gravitational slingshot

#Create Shuttle
Shuttle=box(pos=(6.4e7,0,0), length=72.8, width=108.5, height=20, color=color.red, make_trail=True)
Shuttle.m=15000 #kg
Shuttle.v=vector(0,-3350,0) #m/s

#Create Earth
Earth=sphere(pos=vector(0,0,0), radius=6.4e6, material=materials.BlueMarble)
Earth.m=6e24 #kg

#Create Moon
Moon=sphere(pos=vector(0,4e8,0), radius=1.75e6, color=color.white, make_trail=True)
Moon.m=7e22 #kg
Moon.v=vector(1050,0,0) #m/s

#Create Target Asteroid
Target=sphere(pos=vector(-1.40837e9, 1.42004e9, 0), radius=7e6, color=color.green)

#Create Initial Conditions
G=6.67e-11 #N*(m/kg)^2 #Gravitational Constant

R=Shuttle.pos-Moon.pos #m
r=Shuttle.pos-Earth.pos #m

M=Moon.pos-Earth.pos #m

F=Shuttle.pos-Target.pos #m

FnetShuttle=-(G*Earth.m*Shuttle.m*r)/(mag(r)**3)-(G*Moon.m*Shuttle.m*R/(mag(R)**3)) #N
FnetMoon=-(G*Earth.m*Moon.m*M)/(mag(M)**3)+(G*Moon.m*Shuttle.m*R/(mag(R)**3)) #N

deltat=50 #s
t=0 #s

#Graph Velocity
gdisplay(x=0, y=0, width=600, height=150, title="velocity vs. time", xtitle="t", ytitle="velocity (m/s)", foreground=color.black, background=color.white)
g=gcurve(color.red)

#Animate Orbit
while mag(R) > 1.75e6 and mag(r) > 6.4e6 and mag(F) > 7e6:
Shuttle.pos=Shuttle.pos+Shuttle.v*deltat #m #position update
Shuttle.v=Shuttle.v+(FnetShuttle/Shuttle.m)*deltat #m/s #velocity update

Moon.pos=Moon.pos+Moon.v*deltat #m #position update
Moon.v=Moon.v+(FnetMoon/Moon.m)*deltat #m/s #velocity update

R=Shuttle.pos-Moon.pos #m
r=Shuttle.pos-Earth.pos #m

M=Moon.pos-Earth.pos #m

F=Shuttle.pos-Target.pos #m

FnetShuttle=-(G*Earth.m*Shuttle.m*r)/(mag(r)**3)-(G*Moon.m*Shuttle.m*R/(mag(R)**3)) #N #Force update
FnetMoon=-(G*Earth.m*Moon.m*M)/(mag(M)**3)+(G*Moon.m*Shuttle.m*R/(mag(R)**3)) #N #Force update

t=t+deltat #s #time update

rate(1e100)

g.plot(pos=(t,mag(Shuttle.v)))

print t/8.64e4, "days"
print mag(Shuttle.v), "m/s"



## Thursday, September 26, 2013

### Drag Graphs and Terminal Velocity

This summer, I posted my progression on drag here. One of the new elements was a pair activity where students each calculate the terminal speed of some random object that they come up with and draw (on the same set of axes) the position, velocity, and acceleration curves for the two objects. I then put the values into a VPython script and we check.

We did that today, for the first time, and it went pretty well. The students picked an iPad vs. a calculator and a big (1m on a side) metal box vs. a 747 (nose first). Here's what they got:
iPad (red), calculator (blue)

Neat that the heavier iPad had a lower terminal speed - it's much bigger!

747 (red), box (blue)

That 747 didn't even come close to getting to its terminal speed from 400 meters: how about from 10,000 meters?
747(red), box (blue)

Not much better there. It took nearly 300 km of fall to get there - very heavy, very low drag coefficient.

It was a bit unwieldy entering the values during class, so I think that I might do a Google form/Googlecl/VPython solution to pull those values in from the cloud next year.

## Monday, September 16, 2013

### A Two-pulley Practicum

In the AP C: Mechanics course, we're working through some extensions to old models - non-constant acceleration as a more general application of CAPM principles, UFPM with non-constant forces, etc.

Even with constant acceleration and constant forces, there are some more subtle, but very powerful, techniques that we can't do the first time around. The first is the "look at the whole system" approach to force analysis. Instead of analyzing the half-Atwood machine, for example, as a hanging mass and a cart, and eliminating the tension algebraically, we decide that the net force accelerating the system is mg and the total mass of the system is m+M, and it's super easy to get the system's acceleration. I know that some folks do this in the first year, but I like having them draw those two FBDs and really puzzle out how the force sizes relate to each other, and I think that this is just a little too black-box (especially with the change in direction of the motion in the middle) for the first year. It's also really good algebra practice.

We'll do that today, but we'll also take a look at this situation:
This can be really tricky to analyze as either a separate or a combined system, but we can make an observation about the rope that's really helpful. When the cart moves a distance d to the right, the rope's downward motion is complicated by the presence of the pulley, but a little careful diagramming can show that half of that d will end up as a longer right-hand vertical rope, and half will end up as a longer left-hand vertical rope, so that the hanging mass m will only drop d/2. Using that, the acceleration of the hanging mass must be half of the acceleration of the cart, which allows us to really easily solve for the unknown acceleration.

This worked out very well as a practicum for me, using Pasco track, carts, and superpulleys (with 100g clamped into the jaws of the hanging one. The time's long enough (with a cart run of about a meter) to be timed pretty well with a stopwatch.
I think that this does a great job of emphasizing the importance of thinking during the problem-solving process and of adding a new twist to what students might think is a "completed" topic.

## Friday, September 13, 2013

### Follow-up to the Buggy Lab

In a post yesterday, I shared a new piece of my (WCYDWT) buggy lab: having students mark explicitly on the graph which interval denotes their "answer," and having the other groups interpret the graph to determine what the situation and question were.

I had really only done this with one of two sections of Physics, and I have now had both of those sections a second time after that lab. The results for one task seemed pretty clear. I used Matt Greenwolfe's suggestion here to wrap that up by asking them to draw a specific position vs. time graph for all six robots. I actually asked for two graphs: first, for the six robots, if each was programmed to run for 20 seconds and stop (that's how they were actually programmed on the first day). Second, for the six robots, if each was programmed to run for one meter and stop.

The first class had some of the same issues that Matt described: confusing the time and distance intervals, ascribing meaning to the length of the line, etc. After some discussion, they figured it out and went on. The second class had a much higher proportion of correct graphs from the beginning on both questions. It was a large departure from previous classes' performance as well, so it seems to have had a positive effect.

One of the graphs from the second question is below. The others have been erased, but several of them drew dotted lines horizontally or vertically first, then drew their graphs, which is a great sign.

## Wednesday, September 11, 2013

### Standards for the Year

We had a great discussion on standards-based grading at the Global Physics Department tonight. Here are my standards for the year for each course, in response to a request from that conversation.

AP Physics:

• Term 1 (Momentum Principle)
• Term 2 (Energy Principle)
• Term 3 (Angular Momentum Principle)
Honors Physics:
• Term 1 (Motion, Forces)
• Term 2 (UCM, Gravitation, momentum)
• Term 3 (Energy, Oscillations, Static Electricity, DC Circuits)
Physics:
• Term 1 (Motion, Forces)
• Term 2 (Oscillations, Waves)
• Term 3 (Sound, Phases/Eclipses/Shadows, Geometric Optics)