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