Saturday, September 20, 2014

Graphical Solutions _and_ Symbolic Algebra in Physics

Graphical solutions are terrific tools to build understanding in motion, momentum, energy, and nearly every area of physics. Even better than that, they allow a large number of students to successfully solve problems that really struggle with a strictly algebraic approach. Kelly O'shea and others have some great resources for you to peruse; the approach can be eye-opening for those of use brought up in the traditional system.

One thing that I struggled with a few years ago when first exposed to graphical problem-solving was all of the numbers. With my honors physics classes, I put a lot of emphasis on building their skills in exclusively symbolic solutions to problems - students are expected to do every solution with "no numbers until the end." That is, they have to first derive an expression giving the desired quantity in terms of nothing but given quantities - only then can they use any numbers. This approach has several big advantages:

  • It's a pain to carry around units in the algebra (and necessary, because it's unthinkable to have "naked numbers"); symbolic algebra means that we don't have to
  • We can re-evaluate for different values of the parameters easily
  • We can check how our solution depends on the variables - should the Atwood's acceleration increase or decrease when this mass increases?
  • We can learn how our solution depends on the variables - maybe we didn't know that the mass would cancel out of that expression!
  • We can check how our solution behaves in special cases - should the acceleration go to g if that mass goes to zero?
  • We can learn how the solution behaves in special cases - hey, the position function of a falling ball with drag becomes linear in the large-t limit!
  • We can still check the units of the answer, without having to carry them through the algebra - if the units don't work, then it's not even worth plugging in the numbers
  • This is a skill that ultimately is a part of how "big kids" do science - it's an great skill to have going into college science and math courses (the course that I took this summer had, out of about sixty HW and exam exercises, exactly three problems that involved numbers!)
  • It helps to refine and develop student algebra skills (the more abstract end of the concrete-to-abstract progression of their skill development)
These advantages don't have to be lost in graphical problem-solving - students can still label the graph (naming every labeled quantity, whether it's known or not) and can still build slope and area relationships from the graph (involving those variables that they labeled). Solving these symbolically gets them the best of both worlds: graphical analysis and its lower barrier to entry and improved understanding, and symbolic algebra, with the skills listed above.

What does it look like? Here's a bit of student work, from a recent assessment on CVPM (constant velocity particle model) and the a whiteboard with the first (!) CAPM (constant acceleration particle model) problem that three students did this year.





Tuesday, September 16, 2014

VPython, Energy, and Stability

The content in AP Physics C about stability and its relationship to energy is a pretty thin introduction to a fairly deep idea. Classifying equilibria by looking at the derivative of potential energy can be a quick add-on, or we can make it a little deeper with the help of VPython.

When it first comes up, we go through the stable/unstable/neutral equilibrium discussion and the corresponding shapes of potential energy graphs, but I really wanted a way for students to apply that. I've thought of a few, only three of which I have tried out so far:

  • Have VPython plot a potential energy vs. tip angle curve for a box that's standing on its end - compare for different heights/widths of box
  • Have VPython graph total potential energy vs. stretch amount for a mass on a vertical spring
  • Have VPython graph potential energy for a mass of a spring that doesn't necessarily stay vertical (on y vs. x axes, with U value signified by color)
  • Investigate the Lenard-Jones (interatomic) potential, both for meaning and location of equilibrium points and to fit an approximate quadratic to it near the equilibrium point, justifying the use of the ball-and-spring model of matter.
  • Later in the year, during rotation, have them create a physical pendulum program with a box on a pivot not through its center - modify this to show the graph of potential energy as a function of angle
For the first and fifth, I have some results using VPython to show. (The fourth is great, too, especially if you're using Matter and Interactions!) For the box tipping, the graph is neat, not least of which because of the discontinuity in the derivative at 0. Calculus wouldn't find this minimum on without intervention from the student, and it's easy to forget to check those endpoints! This gives a nice graphical reminder. My one concern is that the geometry is fairly harrowing - determining the height of the CM as a function of angle isn't super-easy, and requires a high-quality diagram. 

Here's a screen shot:


When you vary the parameters, that central well can become deeper (more stable) or shallower (less stable), and vanishes as the box gets narrower (and becomes a pencil).

For the final one, I think that the program, being a modification of a previous one, isn't too difficult to do, though it does bring in the complication of having a "meta loop," where the whole simulation runs several times, with different placements of the axis. 

Here's a screen shot that links to a video of the program running:

The graph here is incredibly rich. Not only do we see two different kinds of equilibrium (three, if you let the pivot be at the middle for the first run through), but we see how the system is forced away from or towards those equilibrium more or less violently as the pivot moves. This helps to bring together their common-sense understandings of stability and the physical principle that we're trying to investigate.

Saturday, August 30, 2014

Drag Graph Checking

I previously posted about a class exercise where my AP C students pair up, pick two random objects, and try to draw qualitatively correct position, velocity, and acceleration graphs for them falling through the air. The idea is to get a qualitative feel for drag graphs and to check qualitative results for terminal velocities.

I had written a VPython script to do this, but it required my intervention to change the values each time, and everyone had to watch all of the graphs. I don't have enough students for that to be super-terrible, but I wanted a way for them to do it themselves.

Enter Glowscript; I've ported the VPython script to there (and made some improvements), and students can now check these graphs for themselves!

There's a screenshot below which links to the simulation - feel free to use it and drop me a line if you do! Definitely let me know if you find any bugs!




Monday, July 14, 2014

Standing Waves/Resonance Applet

The second applet that I wanted to rewrite to save it from Java purgatory was a great transverse standing wave applet by C.K. Ng. I used this principally for a data source for students to explore resonance - it's a lot easier to get reliable data with sufficient amplitude variation using an applet for this than a real experiment. In addition to the standing wave amplitude never being overwhelmingly large with a string vibrator, there are hysteresis effects that will drive the kids crazy. I have them collect this data at home, BTW, so the Java issues have meant that, for the last two years, only a handful of kids have successfully been able to use the applet at home and, without anyone for troubleshooting, they quickly give up.

I'll also say that the approach of summing over the normal modes to find the solution for a given f, L, etc. gives a much neater animation than using a finite element/balls and springs model of the string and waiting for the old waves to damp out. It's idealized, but we're really just looking for the steady-state here anyway - this just gets us there faster. It will make the computer work, though!

The most significant difference here is that I haven't created the draggable ruler, opting instead for more prominent gridlines. I always wanted to measure the amplitude anyway, so the horizontal ruler in the applet didn't help much, but using the grid and some arbitrary 'block' unit should be able to serve both purposes.

Let me know if that is an important feature for you, or if there's anything else that you can think of to add or modify to increase the usefulness of this applet! Click through the photo for the applet itself.


Sunday, July 13, 2014

Longitudinal Wave Simulation

In the wake of the big Java security crisis, Java applets have become increasingly inaccessible and/or onerous to use, due to security settings. Add to this issues like Java 7 needing a 64 bit browser in OSX and Linux, and it's rather difficult to get a classroom set of computers, much less a BYOD environment, to effectively run Java applets in class.

I've found that I can just forget asking students to use them at home, given their computer setups and ability to navigate these complications. Because some of my favorite applets seem to be going extinct, I'm going to try to duplicate as many as I can in Glowscript, which is a kind of mashup between JavaScript and VPython. It has much of the readability and ease of VPython, and can run in WebGL-enabled broswers, which covers most situations (maybe just 'many' in the mobile world, at this point). More importantly, that coverage is on the way up, while Java is on the way down.

My first applet is an attempt to replace Walter Fendt's longitudinal standing waves animation. I love this for my students - it's difficult for them to picture particle motion in longitudinal pulses, but nearly impossible for them to visualize what the particles are doing in a longitudinal standing wave. This depiction is obviously idealized, but it can help them get over that hump.

The second thing that I like about this setup is that it shows SW diagrams/graphs of not only particle displacement, but also the change in pressure. At this point in class, we've been merrily drawing standing wave diagrams for waves in tube as if they were waves on strings (or some kind of string that can have an unconstrained end or two). What have we actually been drawing? This helps to clarify that we had been illustrating the change in position of the particles and shows that we can also describe the change in pressure that they undergo. Looking back up at the animation gives students a sense of why the two trends are related the way that they are.

I've decided to leave out (at least for now) the numerical data on the side, as I hadn't generally found much use for it. Perhaps I'll add it - let me know if you see a good reason for including that.

Click through the screenshot for the applet itself - enjoy!


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