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.

# Newton's Minions

A blog about physics at The Tatnall School in Wilmington DE - student work, demonstrations, lesson ideas, and reflections on standards-based grading

## Monday, July 14, 2014

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

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.

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.

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

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.

Student work:

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:

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:

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

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.

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)

747(red), box (blue)

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

We'll do that today, but we'll also take a look at this situation:

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.

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

Subscribe to:
Posts (Atom)