[Phys-L] simple models of QM wavefunctions, using interactive animated computer graphics and otherwise

[John Denker <jsd@av8n.com>]

On 03/10/2013 10:02 AM, Daniel V. Schroeder wrote:

> Can anyone out there help me understand why there aren't more
> educational physics "applets" written in HTML5/JavaScript?

I recently increased the number of such things by a little bit.

For example, with help from Bruce Sherwood and others, I cobbled up 
some javascript to model and visualize a certain category of waves 
on a string ... including running waves as well as standing waves 
... with emphasis on the kind of wave that exhibit a /whirling/ 
motion and thereby provide an excellent model for the complex 
wavefunctions that we see in quantum mechanics.

You can see this here:
  http://www.av8n.com/physics/wavefunctions.htm#sec-anim-standing-running

The models are interactive in the sense that you can rotate them using
the mouse.  By looking at them from different angles, you get a clearer
picture of the three-dimensional situation ... the abscissa of the 
wavefunction is one dimensional (real space) and the ordinate is two 
dimensional (an abstract complex number).  The models are also animated,
so including the time dimension you're really getting a four-dimensional 
picture.

The computer models have some pedagogical value by themselves, but they
also serve as hints about experiments you can do with a real, physical
rope.

This connects to our recent discussion of the Bohr atom and its pedagogical
value or lack thereof.  As the saying goes, 
     Learning proceeds from the known to the unknown.
The goal is to use waves to explain the nature of atoms.  The first step
is to make sure the students understand plain old classical waves.  This
is not something they were born knowing.  Quantum mechanical waves are
verrrry similar to classical waves, so similar that sometimes I forget
there is a difference.  The main difference is that the ordinate of the 
QM wave is a complex number ... but even that can be well modeled by the
whirling motion of the rope, and by at least two different kinds of
computer-aided visualizations.

You can't rely on any *single* classical model system to faithfully capture 
all of QM, but there are various models that capture various pieces, and
if you collect enough models and leverage them against each other you can
do quite well.

Seriously:  Students can learn a lot about QM in a couple of hours playing 
with waves on a rope and waves in a tub of water ... lots more than they
could learn in a week of fussing with the Bohr model.  However, this needs 
to be /guided/ inquiry, with an emphasis on the *GUIDED* because otherwise
they would have no idea what to look for, and no idea which parts are apt
models of the QM behavior and which are not.

================

Turning now from the physics to the pedagogical technology:

This code uses the "glowscript" library, which has a number of charming 
features, but also some less-charming features such as a tendency to crash 
people's browsers.

The word "glowscript" is used with at least three different meanings:
 a) There is a glowscript /programming language/ and the corresponding
  complier.  This allows you to talk about vectors and three-dimensional 
  graphical objects and other things that physicists like.
 b) There is a glowscript /IDE/ (interactive development environment)
  i.e. a web site where people can write and run simple programs,  This
  has the advantage of a relatively low barrier to entry, insofar as the 
  user doesn't need much more than a modern browser and a sufficiently
  powerful graphics card and CPU.
 c) There is also a glowscript /library/ which is a collection of 
  javascript routines that are used by the aforementioned compiler.

For present purposes, I have almost no need of (a) or (b).  The code for
the QM models is essentially written by hand in javascript ... but it 
calls a few powerful routines from the glowscript runtime library.  The 
only use I have for the compiler is as a source of implicit documentation,
i.e. as a source of hints as to how the runtime routines should be called.

=====

One of the highly touted features of the glowscript language is that it 
allows you to write serialized code, without having to deal with all
the asynchronous "callbacks" and event-driven "handlers" that feature 
so prominently in the basic javascript architecture.

This sort of serialization is helpful for people who have decades of
experience writing single-threaded code.  However, in my experience,
young kids who have never used a computer before don't worry about
such things.  They are perfectly happy letting the computer do N 
things at once.  Kids understand about parallelism.  Consider a 
football team or even a tug-of-war team.  You could adopt a strategy 
where people take turns pulling one at a time, but that would be a 
losing strategy.  It works better if everybody pulls at once.

You do not need to explain this to the kids;  the question never
even comes up.

There was a time many years ago when computers were restricted to
doing things one at a time, but that's not true anymore.  Even my
beat-up old laptop has a quad processor in it ... and even if it
didn't, the hardware is so good at context-switching that from the
students' point of view it /looks/ like it is doing 100 things at
once, and _there is no reason to tell them otherwise_ ... there's
no reason even to bring up the subject!

Consider the real-world physics of molecules bouncing around ... the
molecules move all at the same time.  They take care of themselves
autonomously and asynchronously.  There is no advantage in writing
a serialized program to run on multi-threaded hardware to solve a
multi-threaded problem.

As a non-physics example that illustrates the same phenomenon:  My
QM model software needs to load six different runtime libraries.
There is not the slightest reason why this needs to be done serially,
one by one.  The winning strategy is to load them all in parallel.
It requires only a few lines of code to keep count, so you know
when they're all finished.  You don't know which one will finish
last ... and you don't care.

As another example that leads to the same conclusion:  I know lots 
of ultra-smart people who like programming in C++ and other imperative
languages and despise things like spreadsheets and labview and other
declarative languages.  However, for the other 99.9% of the population, 
the preferences are reversed.  
 -- The mouse-based drag-and-drop interface is easier for beginners
  to use.  There is less barrier to entry.
 -- C++ is for control freaks ... but beginners aren't control freaks.
  They have no idea in which order the cells in their spreadsheet
  will get updated, and they don't care!  Parallelism and asynchrony
  are non-issues.  It never occurred to them to worry about this
  ... and I see no reason to make them worry.

My advice:  Your students are probably way ahead of you on this.
If you prefer writing single-threaded code, keep it to yourself.

=========

One more thing:  Javascript barely counts as a modern programming
language.  It has no type system.  It has objects but not classes.

As such, it is not particularly suitable as a first language for
students.

For experts, writing in javascript is no big deal, because you know
the modern way of doing things, and with a little bit of discipline
and effort you can coerce javascript to do things properly.  There 
are lots of libraries and a few standard idioms that can be used to 
impose some order on the chaos.

This however is a disaster for students, because they don't know
what modern well-structured code is supposed to look like, they
aren't disciplined programmers, and they don't know the clever 
idioms.

In particular, I have a tiny, tiny piece of code that simulates a
class structure, by allowing a callback to bind to a given method
in a /particular instance/ of some object.  C++ or even gamemaker
does this so naturally that you would never even think about it
until you stumble across a language (javascript) that doesn't
naturally support it.  The solution is tiny but tricky; I had to 
think about it for a week before I figured it out.  Now that I 
have a solution I don't think about it anymore.

This reinforces the point that students would be in big trouble
if they didn't have an expert helping them, because they wouldn't
even know this was a fixable problem, let alone how to fix it.

Bottom line:  If you have a lame callback system, my recommendation
is to fix the callback system.  The glowscript compiler takes the
opposite approach, namely to get rid of the callback system (to
the extent possible).  I think this is a mistake.  The javascript
callback system is fixable (proof by construction) ... and this is
the right way to go.  Students like it better and experts like it
better, and everybody else should please get with the program, the 
sooner the better.

=================

I can't stop people from looking at the code that produces these
diagrams ... but I warn you that it's not very nice code.  I took
code written by other people, including some code written by a
compiler (!), and made some quick and dirty modifications.  Some
of the code has been cleaned up, and a few bits here and there are
almost clever ... but the rest of it is dirty and ugly.  As they
say, it wasn't designed;  it was hatched ... as in hatching a plot
or hatching a booby.  I have a pretty clear idea what a good graphics 
package should look like, and this ain't it.

If you have something very similar that you want to do, and don't 
easily get queasy, you can try modifying this code.  It might save 
some time, or it might waste some time ... no guarantees.

A possible alternative would be to forget about glowscript and instead 
use some widely-used package such as three.js, and then write a layer 
of plot-related and physics-related stuff on top of that.