Under the Hood: Inputs and Outputs to Next-Generation MW Interactives


Our Next-Generation Molecular Workbench (MW) allows you to build Web-based simulations to explore emergent scientific phenomena. Years of experience tell us that learning happens best when students actively manipulate such models to ask and answer questions—and the Next Generation Science Standards call for students to do just that. Next-Generation MW helps foster inquiry with models by supporting custom properties, which you can define to expose the most relevant features of the model to observation and direct manipulation.

By embedding a snippet of JavaScript code into the definition of a Next-Generation MW interactive, you can create an output property whose value at any time is a function of the current state of the model in the interactive. Similarly, you can define a parameter, which, when changed, runs a script to match the state of the model to its value. Either type of property can be graphed against time or bound to on-screen controls. Moreover, graphs and controls “just work” when a property changes, for example, when a user adds cold atoms to a box, instantaneously changing an output that reports the average speed of atoms in the box, or when a user revisits a past state of the model, which had a different value of some parameter. This encourages systematic exploration because students’ manipulations are representable, recordable and reversible.

Consider a 2D simulation of nonreactive noble gas atoms compressed into the left side of a box at constant temperature by a piston (as shown below). The core Next-Generation MW engine, called MD2D for Molecular Dynamics 2D, understands the simulation as a set of atoms, an obstacle (perfectly hard rectilinear object of fixed shape and density), and so on.

Area versus pressure interactive. Adjusting the slider changes the leftward force on the dark red “piston.” (Explore the underlying code by visiting mw.concord.org/nextgen/area-versus-applied-pressure.)

Suppose we want students to explore the “volume” of the gas (or, rather, the area, since we’re working in two dimensions) versus pressure applied. MD2D does not know that the obstacle is a piston, nor that we care about the force on it divided by its height. Therefore, we add an item named “pressure” to the parameters section of the JSON describing an interactive, having as its onChange property this JavaScript code:

onChange property var pressure = value, length = getObstacleProperties(0).height, force = -1 * pressure * length, mass = getObstacleProperties(0).mass; force *= 6.022e-7; // Converts pN to MW’s force unit, amu*nm/fs^2 setObstacleProperties(0, { externalAx: force / mass }); 

The parameters entry tells MD2D to add pressure to the list of properties it “knows” about, and the onChange code describes how to update the force applied to the piston when requested pressure changes. The pressure parameter can be bound to a UI control (as in the demo) and is recorded, so that when you step back in the model’s “tape recorder” you see the parameter value that prevailed at that time.

Because we save complete state, even conceptually irreversible onChange actions can be reversed: changing the “number” parameter in the interactive below destroys or creates atoms, but you can always rewind the model to any point in its history and restart it from there. Inherent reversibility frees students to investigate without having to worry about messing up the simulation, making them free to explore.

Area versus number interactive. Changing the “number” parameter in the interactive below destroys or creates atoms, but you can always rewind the model to any point in its history and restart it from there. (Explore the underlying code at mw.concord.org/nextgen/area-versus-number.)

Richard Klancer (rklancer@concord.org) is a developer.