Who’s gone overboard modeling in Physics? This guy, part I.
I’ve been sticking to my plan this year to follow the Modeling Instruction curriculum for my regular physics class. In addition to making use of the fantastic resources made available through the AMTA, I’ve found lots of ways to use Python to help drive the plow through what is new territory for me. I’ve always taught things in a fairly equation driven manner in Physics, but I have really seen the power so far of investing time instead into getting down and dirty with data in tables, graphs, and equations when doing so is necessary. Leaving equations out completely isn’t really what I’m going for, but I am trying to provide opportunities for students to choose the tools that work best for them.
So far, some have embraced graphs. Some like working with a table of data alone or equations. The general observation though is that most are comfortable using one to inform the other, which is the best possible outcome.
Here’s how I started. I gave them the Python code here and asked them to look at the lines that configure the program. I demonstrated how to run the program and how to paste the results of the output file into Geogebra, which created a nice visualization through this applet. Their goal through the activity was to figure out how to adjust the simulation to generate a set of graphs of position and velocity vs. time like this one:
Some used the graph directly and what they remembered from the constant velocity model (yeah, retention!) to figure out velocity and initial position. Others used the table for a start and did a bit of trial and error to make it fit. While I have always thought that trial and error is not an effective way to solve these types of problems, the intuition the students developed through doing came quite naturally, and was nice to see develop.
After working on this, I had them work on using the Python model to match the position data generated by my Geogebra Particle Dynamics Simulator. I had previously asked them to create sets of data where the object was clearly accelerating, so they had some to use for this task. This gave them the chance to not only see how to determine the initial velocity using just the position data, as well as use a spreadsheet intelligently to create a set of velocity vs. time data. I put together this video to show how to do this:
[wpvideo bQyM2woe].
It was really gratifying to see the students quickly become comfortable managing a table of data and knowing how to use computational tools to do repeated calculations – this was one of my goals.
The final step was setting them free to solve some standard Constant-Acceleration kinematics problems using the Python model. These are problems that I’ve used for a few years now as practice after introducing the full set of constant acceleration equations, and I’ve admittedly grown a bit bored of them.Seeing how the students were attacking them using the model as a guide was a way for me to see them in a whole new light – amazingly focused questions and questions about the relationship between the linear equation for velocity (the only equation we directly discussed after Day 1), the table of velocity data, and what was happening in position vs. time.
One student kept saying she had an answer for problem c based on equations, but that she couldn’t match the Python model to the problem. In previous classes where I had given that problem, getting the answer was the end of the story, but to see her struggling to match her answer to what was happening in her model was beautiful. I initially couldn’t do it myself either until I really thought about what was happening, and she almost scooped me on figuring it out. This was awesome.
They worked on these problems for homework and during the beginning of the next class. Again, some really great comments and questions came from students that were previously quiet during class discussions. Today we had a learning standard quiz on constant acceleration model questions, and then decided last night during planning was to go on to just extending the constant acceleration model to objects in free fall.
Then I realized I was falling back into old patterns just telling them that all objects in free fall near Earth’s surface accelerate downward at roughly 9.81 m/s^2. Why not give them another model to play with and figure this out? Here’s what I put together in Python.
The big plus to doing it this way was that students could decide whether air resistance was a factor or not. The first graph I showed them was the one at right – I asked whether they thought it could represent the position versus time graph for an object with constant acceleration. There was some inconsistency in their thinking, but they quickly decided as a group after discussing the graph that it wasn’t. I gave them marble launchers, one with a ping-pong ball, and another with a marble, and asked them to model the launch of their projectiles with the simulation. They decided what they wanted to measure and got right to it. I’m also having them solve some free fall problems using the gravity simulation first without directly telling them that acceleration is constant and equal to g. They already decided that they would probably turn off air resistance for these problems – this instead of telling them that we always do, even though air resistance is such a real phenomenon to manage in the real world.
A bit of justification here – why am I being so reliant on the computer and simulation rather than hands on lab work? Why not have them get out with stopwatches, rulers, Tracker, ultrasonic detectors, air tracks, etc?
The main reason is that I have yet to figure out how to get data that is reliable enough that the students can see what they have learned to look for in position and velocity data. I spent an hour working to get a cart on an inclined air track to generate reasonable data for students to use in the incline lab in the modeling materials from AMTA on constant acceleration, and gave up after realizing that the students would lose track of the overall goal while struggling to get the mere 1 – 2 seconds of data that my 1.5 meter long air track can provide. The lab in which one student runs and other students stand in a line stopping their stopwatches when the runner passes doesn’t work when you have a small class as I do. The discussions that ensue in these situations can be good, but I have always wished that we had more data to have a richer investigation into what the numbers really represent. The best part of lab work is not taking data. It’s not making repetitive calculations. Instead, it’s focusing on learning what the data tells you about the situation being measured or modeled. This is the point of spending so much time staring and playing with sets of data in physics.
I also find that continuing to show students that I can create a virtual laboratory using several simple lines of code demonstrates the power of models. I could very easily (and plan to) also introduce some random error so the data isn’t quite so smooth, but that’s something to do when we’ve already understood some of the fundamental issues. We dealt with this during the constant velocity model unit, but when things are a bit messier (and with straight lines not telling the whole picture) when acceleration comes into play, I’m perfectly comfortable with smooth data to start. Until I can generate data as masterfully as Kelly does here using my own equipment, I’m comfortable with the computer creating it, especially since they can do so at home when they think nobody is looking.
Most of all, I find I am excited myself to put together these models and play with the data to model what I see. Having answered the same kinematics questions many times myself, being able to look at them in a new way is awesome. Finding opportunities for students to figure out instead of parrot responses after learning lists of correct answers is the best part of teaching, and if simulations are the way to do this, I’m all for it. In the future, my hope is to have them do the programming, but for now I’m happy with how this experiment has unfolded thus far.
Evan,
I really like this. Have you seen some of the stuff Matt Greenwolfe is doing with scribblar2 robots? I think you’ll find this interesting and a lot of overlap with what you’re trying to do with your simulations.
I love his use of the robots – I’m convinced it is the absolute best way to teach the kinematic models. I’ve thought about doing this with LEGO robots, but I haven’t spent the time to address the limited resolution of the rotation sensors in the servo motors. His work deserves to be highlighted by everyone that sees it.
I’m happy with what the simulations have done (and will share more in a future post) about my next steps with the idea. That doesn’t change the fact that I’m really impressed with the robots and the videos he posted on his blog.
If the computer is programmed with the model, and then you’re using the program to observe a pattern and build a model, you’ll obviously end up with the model that you’ve programmed. Does this seem a bit hand-wave-y to them?
I had that problem in a big way with my central force lab before. I did a better lab last year (not a simulation), and it was awesome (haven’t written it up yet). If it doesn’t seem a bit hand-wave-y to them, does that bother you? Shouldn’t it bother them?
Also, do you find that adding many layers of technology obscures the physics (sort of in a parallel way to your note about getting caught up in taking data might obscure it, though I’d have to disagree with the taking data part—taking data, even when it takes a while, can be awesome—when they really understand what they are doing and are invested in it, they start to see patterns as they go, and they get more and more eager to see what the graph will look like—that’s increasingly true as they become more skilled and experienced through the year)? I find that even using a calculator can make most of my students stop thinking. At least, they stop thinking about physics and defer to the mightier and more knowledgeable being—the calculator. If they were using the computer to do most of their physics work, it seems like that would be amplified quite a bit.
I don’t mean to sound really negative. Just some of the things I’ve been thinking about (in my own work) lately, and your post prompted some sharing of that musing.
Hi Kelly,
I agree with you on the danger of hand waving-as-instructional-model, and it is lurking there in the back of my mind as a foil to the devil that tells me that Python makes it so I never need to do an actual lab again. (Eeek!) Here are the reasons I have come to terms with using this method for collecting data for an experiment:
We shouldn’t need to tell our students to ignore large portions of data because they don’t seem to fit a model that they haven’t come up with themselves or don’t understand. Accepting that I was not able to generate the position vs. time data using this method, I knew the table of data generated through Python would at least give position and velocity data that students could analyze as they did for developing the constant velocity model and realize that this model was not appropriate in this situation. It was a short term solution that ended up working really well, hand waving/black box issues aside.
I understand and have seen the problem that comes with calculator use. This is different though. The calculator is usually where we (and students) turn to get a single number as an answer. The computer instead generates a whole bunch of calculations based on an organizing premise, and students then have to analyze the results and really understand them to answer the questions we give them. I think the big piece I like is that for some students, a graph is a bit more of an abstraction than they really understand. A student might hear ‘graph’ and connect that to math, and that they don’t like math, and that the graph reminds them of all of the things they don’t like about math, and then that student has suddenly shut down answering the question. That’s a step in the wrong direction.
It’s inefficient, and ideally we want to push them to see why the graph is a better representation than a table of data. Still, I had one of my weaker students look at the position vs. time data and estimate when velocity was zero with seemingly little effort, while being unable to do so from a graph. That’s hard for me to ignore. If a table of results is concrete enough for my students to be able to answer these types of questions, that’s a good enough starting point for me.
It sounds like you just need help diagnosing what’s wrong with your equipment. So far, it sounds like the sensor isn’t seeing the object. Why are you using an air track? I’ve never seen anyone do that for the acceleration lab. Can you post a screenshot of what the data looks like and a photo of the setup?
Also, I’m not sure how your third point is satisfying. It still sounds to me like you’re programming a model, then using the program to find a pattern and build a model. Maybe I just don’t understand your point?
Hi Kelly,
I guess my main point is this: I can use Newton’s 2nd law to create a single computational model that is good enough for modeling objects moving at constant velocity/balanced force, constant acceleration, and non-constant acceleration. Students can use this one computational tool to explore all of these ideas, and use it to model the movement of real objects moving around in front of them.
As you said, there is great value in the experience of taking data, but if the set-up does not work (for reasons unrelated to student assumptions or misuse of the equipment), it diverts resources away from the experience of digging in to the measurements students want to make and figuring out what these measurements mean. If the results match observations, this can be a good entry point for learning why. It’s also interesting because if a student asks if they could see acceleration vs. time data for an object in the model, I can simply make that an output. This is a lot easier than trying to locate/attach/troubleshoot an accelerometer just to be able to see what that data looks like.
As for the experimental set-up, I started on the air track because I was using fans that I attached to the air-track carts that weren’t strong enough to propel carts on a horizontal surface with friction. The problem with the data is definitely related to the ultrasonic sensors I am using (Vernier) – even for walking/generating graphs in the constant velocity model, the students needed a 2 ft. square piece of cardboard to avoid getting sudden spikes in the position vs. time data. The system was sensitive to ANY changes in the angle of the surface facing the sensor. I’ll see about posting pictures of the set-up and data if you are up for chatting about it.