Units in physics again

Joe Redish has a series of posts on The Unabashed Academic on the use of units in math and physics courses: Units and stoichiometry, Cutting mathematicians some slack,  Teaching units, and A higher power—units again.  I just re-read that series of articles today (having read one or more of them when they first came out).

The Teaching units post had one paragraph that particularly caught my attention:

In addition to suppressing units when we do pure math, we might also note that when writing computer code we often suppress units. (This led to a multi-million dollar failure at NASA.) But any object-oriented programming language can correctly retain (and even check) units. I doubt that classes in computation, either in computer science, engineering, or physics departments, teach objects with units—despite the fact that it would be incredibly useful for scientists.

I used Vpython with my son in learning calculus-based physics, and was irritated by its inability to play nicely with units (see Units in physics and Physics simulations). It would be a fairly simple modification to Vpython to allow a “units” option for each plotting or drawing routine  There could be a global option to change the defaults from None (for legacy Vpython code) to “m” for lengths, “s” for time, and “Hz” for frequencies (like the “rate” function), and to require units using the Unum package for all plotting and drawing.

For teaching physics, having unit checks on all computations would help students debug both their programs and their physics understanding.  I really don’t understand why this was not included from the beginning in Vpython, since the language was intended for use as a language for teaching physics. Carrying the units around like this does slow the code down (perhaps by a factor of two), but the pedagogical value of being able to debug incorrect-unit bugs far exceeds the pedagogical value of faster simulations.

Next year, in the circuits course, I’m going to be a stickler about students always including units in their computations, as a consistency check on their thinking, since many of the bioengineers do not have good number sense or algebraic intuition.  Forcing them to carry units throughout may make them a little less likely to do random algebraic manipulations.

Caballero on teaching physics with computation

Yesterday, Danny Caballero left a comment on my blog with pointers to three preprints of papers he’s been a co-author on:

I couldn’t agree more with the overall sentiment in this post. Computing is important for all students of science and for science teachers. However, as you say, I do think my dissertation work has been misconstrued a bit in this post. So, let me clarify.

The inventory you mention measures a small slice of mechanics taught in introductory physics. It’s been an important slice, but maybe now it’s time to think beyond it. What are students learning above and beyond this assessment? In M&I, they are learning about modeling, computing, and connecting the two. My work shows that the present implementation of M&I doesn’t produce great gains on this assessment, that students make mistakes in their code, and that they are less inclined towards computing after instruction.

So what? We are getting to teach students how science is done and they are using computing to investigate models. Now, this implementation is not the most polished one, which means we have a good way to go. But, that’s OK, because we are not going to fix all these issues overnight. We have been working on them for the last two years in various contexts. But, we need to figure out how to teach science and computing together. And we need to figure out how to do it well.

So, I’ll point you to a few other publications on computing in physics that I’ve written. Two concern high school, and another deals with physics majors. The high school work shows we can implement ideas from my dissertation work at the high school level (as others are doing). Moreover, we find that students who know physics and computing ideas can make good models of systems and are not memorizing lines of code. In my dissertation work, we didn’t do any qualitative work like student interviews, but it’s clear that doing so is necessary. The work with physics majors is one of the first forays into integrating computing in upper-division physics. We show that a new model for implementation can positively affect student attitudes.

High School:
http://arxiv.org/abs/1207.0844
http://arxiv.org/abs/1207.1764

Upper-division:
http://arxiv.org/abs/1303.4355

This morning I read his three papers.  They all describe prototype courses that use computational modeling to teach physics, with some analysis of the outcomes.  They are not controlled experiments, but prototyping proof-of-principle projects (as are most educational research “experiments”).  This is not a criticism of the papers—one generally has to do a lot of prototyping before arriving at a method that is robust and repeatable enough to be worth the difficulty and expense of controlled experiments.  Engineers see the need for prototyping, but too many people in other fields think that things have to work perfectly the first time or be discarded forever.

These papers bracket the previous work Danny did that studied computational modeling for first-year calculus-based physics.  The two high-school papers are about a 9th grade physics class that uses the Modeling Instruction approach to teaching physics, to which was added computational modeling using VPython.  The “upper-division” paper discusses adding computational modeling to a 2nd-year classical mechanics course for physics majors, following a traditional 1st-year calculus-based physics course.

I was a little unclear on the level of the 9th-grade course.  In one place he refers to it as “conceptual physics”, but in other parts of the description it sounds more like an algebra-based high school physics course (covering the mechanics half of AP Physics B), a step-up from conceptual physics.

From his description, it seemed fairly straightforward to add a computational component to the Modeling Instruction approach, and it helped students see that all the different “models” taught in that approach are really special cases of the same underlying general model.  They used Vpython with a couple of additional packages (PhysKit and PhysUtil) to make creating graphs and motion diagrams easier for beginning programmers.  The additional packages allow lines like

    motionMap.update(t)
    timerDisplay.update(t)
    graph.plot(t, cart.pos.x)

in the inner loop, simplifying the usual VPython interface a bit.

It sounds like the students were finishing the course with a mix of students who knew what they were doing and those who still hadn’t quite grasped the physics or hadn’t quite got the programming.  He did try analyzing some of the student work to see whether students were having difficulty with the physics or VPython for making the simulations, but I found the results hard to interpret—raw numbers don’t mean much to me, because I don’t have a good prior expectation of what 9th graders at a private high school should be able to do.  I’m curious whether difficulties with programming correlated with difficulties in understanding the physics, and whether grading the computational homework gave insight into the misconceptions the students had about the physics.

One of the strong points of the computational approach is that it allowed the students to model phenomena usually beyond the scope of 9th-grade physics (like a soccer ball with linear drag forces).  I found this to be the case for calculus-based physics also, where we modeled pendulums without the small-angle approximation (problem 4.P.89 in Matter and Interactions) and the magnetic field lines of a helical solenoid.

Some of his observations are unsurprising: “Students find debugging their programs difficult; that is, they have trouble determining whether they have made a coding error or a physics error and how to deal with that issue. ”  He also noticed that some students found installing the software difficult—I believe that the VPython developers have been working on that problem, though it is not yet at the level where all 9th graders will find it easy.

Personally, I’d like to see the physics simulations for high school students use computations with units throughout—this would help them catch a lot of their physics errors earlier.  I see this lack of units as one of the biggest flaws in VPython as an instructional tool for physics.  I’ve blogged about this before in Physics with Units, and I’ve done some VPython programming using Unum.  Unfortunately, the Vpython plotting and animation code does not play nicely with Unum, and having to strip out the units before plotting or drawing negates most of the advantages of keeping units around. I realize that for professional physics simulations, units are always implicit (in comments and variable names) rather than explicit, because that makes more efficient use of the computer, but for instructional purposes explicit units would be worth the inefficiency.

The 2nd-year classical mechanics course used Mathematica to solve ordinary differential equations (ODEs), and provided only minimal instruction in Mathematica.  The main improvement to the course from my perspective was the addition of a final project that allowed students to study an open-ended physics question of their own choice using computational modeling.  This improvement was discarded in subsequent offerings, because it required too much instructor time. Caballero wrote, “For junior and research-focused faculty, the computational project is a significant investment of their time and energy given the large enrollment in CM 1. Developing authentic, scientific experiences for students that can be sustained with little faculty input is challenging.”

This is a theme that I see repeatedly in course design in all disciplines and at most universities: the really good parts of prototype courses take a lot of instructor time and get discarded.  I think that the goal “sustained with little faculty input” is a wrong goal, but it is one shared by many faculty and administrators, who think that teaching is a burden that should be given as little effort as they can get away with. I’ve decided, rather deliberately, not to design my courses that way, but to design them around high faculty involvement.  I believe that the value of a University education depends on high-contact courses, and I’m willing to resist the MOOCification of the university at least in my own courses.  This does take a lot of my time, and I’ve given up on writing grant proposals to make the time—not a choice that most junior faculty could afford to make, given that promotion these days is based more on how much money is brought in than on the quality of teaching or research.

Physics simulations

Someone recently pointed me to these Physics Simulations using the free gemoetry/algebra tool Geogebra.  It seems that Geogebra is a pretty good tool for creating 2D geometric drawings that can be animated, though I’ve not tried doing so myself. I don’t have a lot of use in the home-school physics teaching I’m doing for demo programs, and most of the Geogebra programs in this set are for optics or electromagnetism, and so part of next year’s course.

I wonder how Geogebra compares to Vpython for student-written physics programs, though.  Vpython is fairly simple to code (though I wish that it was integrated with Unum, so that all computations could be done with units—having to throw away the units for communicating with Vpython makes carrying around the units almost more trouble than they’re worth.

I had thought that we would do a lot of simulations of physical phenomena this year as part of the Physics C: Mechanics class, but it has not worked out that way.  The students (including me) often did not do the assigned computational problems.  Some of programs were useful, like the pendulum without the small-angle approximation, but a lot just simulated phenomena that were rather obvious from the formulæ, and so were not worth the trouble to write.  I had hoped for more examples like the pendulum, where simulation provided insight that was not available from analytic solutions.

Perhaps next year, when we do the Electricity and Magnetism half of the physics course, there will be more simulations worth doing.

More on the slinky and the speed of sound

The Slinky Lab post got an interesting pingback from Engineering Failures » Secrets of the ‘Levitating’ Slinky, which describes the curious phenomenon that happens when you suspend a slinky vertically, then release the top end. The bottom end does not move for about 0.3 seconds, when the compression wave from the top reaches it. It might be worth videotaping that phenomenon in this week’s lab.

I think it might be interesting to try to calculate (either analytically, or as part of the VPython simulation) the movement of Slinky as you drop it. In particular, I’m curious at what point the compression wave becomes a shock wave (that is, when does the top of the slinky start moving faster than the speed of sound in the slinky). Note that the speed of sound in the slinky is best expressed as “coils per second” rather than m/s, in order to get a constant speed of sound in the non-uniformly stretched slinky.

The other lab/demo I was thinking of doing this week, measuring the speed of sound in a metal bar, is not going so well.  I was planning to use a setup similar to that in the Chapter 4 Lecture 3 video at http://courses.ncsu.edu/py581/common/podcasts/.  That is, a long metal bar, with a microphone at one end, tapped with metal striker at the other end.  A clock is started when the tap is made (a simple electrical connection), and the waveform is recorded at the other end.

The first problem was that I did not have a suitable microphone.  I found a quick workaround for that problem, as just last week my wife had given me a fine electromagnet that she had found in the street (we have a lot of “found objects” at our house).  The coil has a 68.3 Ω resistance and a laminated iron core, so waving a magnet around near the pole piece results in a fairly substantial electrical signal across the ends.  So I made my own “microphone” with the coil, a refrigerator magnet, and a folded piece of paper as a spring.  If I rest a piece of aluminum bar stock on it and tap the other end, I get a signal of about 0.3 v, which I can see clearly on my oscilloscope.  If it was a storage scope, I’d be almost done, since I could trigger on one channel and record on the other.  I might still have to do something like that with my analog scope.

What I had hoped to do was to use an Arduino to measure the time it took from the tap to the signal arriving at the other end. Using the micros() subroutine provides timing with a resolution of about 4 microseconds, and starting it on electrical connection from the tap is pretty easy.  I had initially thought to use the analogRead() function, but it is too slow: each analog-to-digital conversion takes about 100 microseconds, and the speed of sound in aluminum is about 6400 m/s, or about 150 μsec to go a meter.  I don’t think I can do speed measurements with that low a time resolution unless I had a bar of aluminum 100s of meters long.  That means that to use the Arduino for timing, I have to convert the analog signal to a digital one by some other means.  The most obvious method is to use a comparator chip, such as an LM339.  I looked through the spare chips I have from 30 years ago, and found one LM311-N14A chip, which has a comparator that takes only a +5v supply.  The data sheet even has a circuit for a “magnetic transducer”.  I tried the circuit, and found that  I needed to add capacitors across the input and the output to reduce noise that otherwise kept the comparator triggered.

Once I got the comparator circuit working, it was fairly trivial to hook everything up to the Arduino and write the following program:

void setup()
{
  //  put a 20k pullup resistor on pin 3
  pinMode(3,INPUT);
  digitalWrite(3, HIGH);
  //  put a 20k pullup resistor on pin 2
  pinMode(2,INPUT);
  digitalWrite(2, HIGH);

  Serial.begin(115200);
}

void loop()
{
  Serial.println("Ready");

  // wait for pin 2 to go low
  while (digitalRead(2)>0) {}
  long start_1=micros();
  while (digitalRead(3)>0){}
  long start_2=micros();
  Serial.print(F(" start_1="));
  Serial.print(start_1);
  Serial.print(F(" start_2="));
  Serial.print(start_2);
  Serial.print(F(" diff="));
  Serial.println(start_2-start_1);
  delay(100);

}

I tried it out with a piece of aluminum about 1.026m long, and got numbers in the range 272μsec to 304μsec, which would be speed of sound of 3380 m/s to 3780 m/s. That is a little slower than I expected. One possibility is that the comparator is not responding to the movement of the magnet toward the coil, but the rebound as it moves away. If I flip the magnet over, I get even longer times (784μsec to 884μsec), so I suspect the first orientation was the correct one, and the speed of sound in this aluminum alloy is a little lower than I expected, or the comparator circuit is adding some delays.

I’ll have to make a bit more robust way of holding the magnet and stuff, before Friday’s lab/demo, since everything is currently rather wobbly (the magnet is held to the coil with a PostIt note to act as the spring).

Units in physics

The post today by An Unabashed Academic,  A higher power — units again, triggered one of the little things that has been bugging me about how I’m teaching Physics using Matter and Interactions and VPython.  The problem is that VPython does not have any way of expressing or keeping track of units.  All the variables are just real (or complex) numbers, with no attached units.  Although that is standard practice in computer programming, it is not standard practice in physics and is pedagogically a bad idea, as debugging a hidden change of units is very difficult for students.  (The article that triggered this musing is about units to higher powers, like length⁶ or length⁴, where they come from, and how to think about them, but that is not the problem I’m interested in right now.)

I’m wondering how difficult it would be in VPython to create a new class of  objects which can be scalars or vectors with units.  It has been done in other languages in the past (see, for example, Incorporation of units into programming languages by Michael Karr and David B. Loveman, II, Communications of the ACM, Volume 21 Issue 5, May 1978 doi:10.1145/359488.359501), and is still being done in other languages.

The popular SciPy scientific Python package does not implement units—there is unit name associated with the constants in its table of constants, but it is just a string, with no attached semantics, and it is not carried with the numbers.  But there are implementations of units of measurement in Python.  There is a discussion  on bytes.com of this very question, pointing to several implementations. A couple of the implementations pointed to have dead links (http://RussP.us/scalar.htm and http://home.tiscali.be/be052320/Unum.html). The RussP code does not seem to be findable on the web (I’ve not bothered checking the Wayback Machine, since unmaintained code is not a good idea to incorporate into a project), but the Unum code seems to now be at https://bitbucket.org/kiv/unum/, where it is still actively maintained. The description at bitbucket seems promising:

Unum stands for ‘unit-numbers’. It is a Python module that allows you to define and manipulate quantities with units attached such as 60 seconds, 500 watts, 42 miles-per-hour, 100 kg per square meter, 14400 bits per second, 30 dollars, and so on. Features include exceptions for incorrect use of units, automatic and manual conversion between compatible units, easy extension to arbitrary units, and integration with other arithmetic types including Numpy arrays and standard library types like complex and fractions.Fraction.

The installation instructions for Unum claim that it can be installed with easy_install, but that was deliberately broken on Sept 4, 2011, and the installation instructions not updated to reflect the change.  Installation with the alternative instructions (downloading the tar file, untarring it, and running “python setup.py install”) does work, and Unum seems fairly solid.  It is probably dangerous to use “from unum.units import *”, since there are a lot of short names that get defined, and someone is likely to have used one of them with a different meaning already.  Using “from unum import units” is probably better, since that allows expressions like 2*units.cm, which avoids ambiguity.  One minor feature of Unum is that it keeps units with prefixes (km, cm, mm), which can be an advantage or disadvantage.  It is possible to force particular units:

sp = 10*units.km/ (5*units.h)
>>> sp
2 [km/h]
>>> sp.asNumber(units.m/units.s) *units.m/units.s
0.555555555556 [m/s]
>>> sp.asUnit(units.m/units.s)
0.555555555556 [m/s]

In the comp.lang.python Google group, Will Ware posted mks.py, a fairly minimal implementation of numbers with units.  If I’m reading the code right, there are some weird restrictions (like requiring unit-less scalars to the left of numbers with units when multiplying, so 2.7*liters is legal, but (1*liters)*2.7 is not).  This is a minimal implementation that can be used with care, but is not robust enough for use with novice programmers. Unum looks like a better bet.

Pyre does explicitly include units, but it is intended for experts to create efficient code, and the complexity of the framework is probably too much for first-time programmers.

ScientificPython looks like a competitor for SciPy, and includes an interface to VPython already.  I’ve not checked how well the Scientific.Physics.PhysicalQuantities module (which implements “physical quantities with units, including unit conversion and arithmetic operations with unit checks”) is integrated with VPython, but it looks like Konrad Hinsen has done most of the work here.  Of course, picking up the whole package may be a bit much as there is a lot of stuff here that is not relevant to a first-year physics class, so the documentation may be overwhelming.  It does seem simpler to use just a subset of this than to use Pyre, though.

I now have to decide whether to suggest to my students that they install and use Unum with their Vpython programs.  It would certainly help them keep their units straight.