Tag Archives: HTML5

Tablet-friendly STEM Resources

Is your New Year’s resolution to find more interactive STEM resources that are tablet-ready? (We understand — we make similar technology-related resolutions, too!) We’ve optimized many of our browser-based interactive resources to run on popular tablets. By tuning our code, we’re able to make the power of our models available for your students!

For example, this Phase Change interactive runs 60% faster than it did before our recent code improvements:

And Metal Forces runs 33% faster:

Here’s a few to try now:





For even more, check out a complete list of our tablet-friendly STEM resources.

Dart projects of Energy2D and Quantum Workbench announced

Last month, Google announced Dart 1.0, a new programming language for the Web that aims to greatly accelerate Web development. Dart uses HTML5 as the UI. It can either run on the Dart Virtual Machine being built in Chrome or be compiled into JavaScript to run in other browsers. Dart can also be used to create standalone apps (I guess it is meant to be the main programming language for Google's own Chrome OS) or server-side software. An ECMA Technical Committee (TC 52) has been formed to make Dart into an international standard.

This is the moment I have been waiting for. As a developer with C/Java background, I am not convinced that JavaScript is made for large, complex projects (as Web programming seems to be moving towards) -- even after reading many articles and books about JavaScript. The facts that after ten years Google Docs still has only a tiny fraction of functionality of Word and basic functions such as positioning an image have not improved much suggest that its JavaScript front end has probably reached its limit.

Don't get me wrong. JavaScript is an excellent choice for creating interactive Web experiences. I use JavaScript extensively to create Web interfaces for interacting with the Energy2D applet. But I think it is in general healthy for the developer community if we are given more options. Recognizing the weaknesses of JavaScript, the community has already created CoffeeScript and TypeScript (supersets of JavaScript that strips off unproductive features of JavaScript) that also require compilation into native JavaScript. Dart is Google's solution to these problems that should be welcomed. To a Java developer like me, Dart provides a much better option because it returns the power of class-based object-oriented programming to developers who must create Web-based front ends. What is even sweeter is that its SDK provides a familiar Eclipse-based programming platform that makes many developers feel at home.

Excited about the potential of this new language (plus it is from Google and will be highly performant on Chrome), I am announcing the development of the Dart versions of our Energy2D and Quantum Workbench software. These software are based on complex mathematical solutions of extremely complex partial differential equations and will hopefully provide some showcases to anyone interested in Dart. This is not to say the development of the Java versions will cease. We are committed to develop and maintain both Dart and Java versions.

Hopefully 2014 will be an exciting year for us!

Modeling Physical Behavior with an Atomic Engine

Our Next-Generation Molecular Workbench (MW) software usually models molecular dynamics—from states of matter and phase changes to diffusion and gas laws. Recently, we adapted the Molecular Dynamics 2D engine to model macroscale physics mechanics as well, including pendulums and springs.

In order to scale up the models from microscopic to macroscopic, we employ specific unit-scaling conventions. The Next-Generation Molecular Workbench (MW) engine simulates molecular behavior by treating atoms as particles that obey Newton’s laws. For example, the bond between two atoms is treated as a spring that obeys Hooke’s law, and electrostatic interactions between charged ions follow Coulomb’s Law.

Dipole-dipole interactions simulated using Coulomb’s Law.

At the microscale, the Next-Generation MW engine calculates the forces between molecules or atoms using atomic mass units (amu), nanometers (10−9 meters) and femtoseconds (10-15 seconds), and depicts their motion. To simulate macroscopic particles that follow the same laws, we can imagine them as microscopic particles with masses in amu, distance in nanometers, and timescales measured in femtoseconds. Once the Next-Generation MW engine calculates the movement of these atomic-scale particles, we simply multiply the length, mass and time units by the correct scaling factors. This motion satisfies the same physical laws as the atomic motion but is now measured in meters, kilograms and seconds.

In the pendulum simulation below, the Next-Generation MW engine models the behavior of a pendulum by treating it as two atoms connected by a very stiff bond with a very long equilibrium length. The topmost atom is restrained to become a “pivot” while the bottom atom “swings” because of the stiff bond. Once the engine has calculated the force using the atomic-scale units, it converts the mass, velocity and acceleration to the appropriate units for large, physical objects like the pendulum.

Large-scale physical behavior simulated with a molecular dynamics engine.

In order to appropriately model the physical behavior of a pendulum or a spring, we use specific scaling constants. Independent scaling constants for mass, distance and time enable us to convert nanometers to meters, atomic mass units to kilograms and femtoseconds to model seconds. Using the same scaling constants, we can derive other physical conversions, such as elementary charge unit to Coulomb. In order to make one model second pass for every real second, we adjusted the amount of model time between each page refresh. We also chose to simulate a gravitation field—a feature usually absent in molecular dynamics simulators—because it is relevant to macroscopic phenomena.

From microscale to macroscale, the Next-Generation Molecular Workbench engine is a powerful modeling tool that we can use to simulate a wide variety of biological, chemical, and physical phenomena.  Find more simulations at mw.concord.org/nextgen/interactives.

Hitting the Wall

Gas laws are generally taught in high school chemistry. Students learn that Boyle’s law, for instance, can be expressed as P1V1=P2V2, where P is pressure and V is volume.

From the equation, it’s clear that there is an inverse relationship between the gas pressure and volume, but do students understand the molecular mechanism behind this relationship?

Since students are programmed to plug and chug, if you give them, say, P1, V1, and P2, they can find the numeric value of V2. Although students can get the correct answer, teachers have told us that their students don’t really understand the gas laws because they don’t have a mental model of what’s happening. Gases are, after all, invisible! Nor can students see volume or pressure.

Molecular Workbench makes the gases, volume, and pressure visible. With a new set of Next-Generation Molecular Workbench interactives, students can experiment with increasing the pressure on a gas to see why the gas volume decreases.

The “What is Pressure?” interactive (above) shows the inside (yellow atoms) and outside (pink atoms) of a balloon. (Even the velocities of the individual atoms are visible with vectors!) The green barrier represents the wall of the balloon.

Students learn that pressure is nothing more than molecular collisions with a barrier. In the beginning, atoms hitting the balloon wall on either side move it just a tiny bit—transferring some of their kinetic energy to the barrier. At equilibrium, the balloon wall remains (relatively) stationary. (Go ahead and run it to see!)

But if you add atoms to the balloon, the balloon wall moves out; more atoms means that there is increased pressure pushing outwards on the barrier. Since the number of atoms on the outside of the balloon hasn’t changed, the pressure pushing inwards is the same as it was before. With unbalanced forces, you get net movement.

With barriers, we can also measure the pressure caused by those molecular collisions.

In the “Volume-Pressure Relationship” interactive (above), students see a visual representation of Boyle’s law.

Other models allow students to investigate all the relationships of Charles’s law (V1T2=V2T1), Gay-Lussac’s law (P1/T1=P2/T2), and Avogadro’s law (V1/n1=V2/n2).

And, of course, all of these relationships together make up the Ideal Gas Law (PV=nRT). Explore gas laws today with some HTML5 molecular models!

Video: Under the Hood of Molecular Workbench

It takes a lot of computation to model the atomic and molecular world! Fortunately, modern Web browsers have 10 times the computational capacity and speed compared with just 18 months ago. (That’s even faster than Moore’s Law!) We’re now taking advantage of HTML5 plus JavaScript to rebuild Molecular Workbench models to run on anything with a modern Web browser, including tablets and smartphones.

Director of Technology Stephen Bannasch describes the complex algorithms that he’s been programming behind the scenes to get virtual atoms to behave like real atoms, forming gases, liquids and solids while you manipulate temperature and the attractive forces between atoms. See salt crystallize and explore how the intermolecular attractions affect melting and boiling points. Imagine what chemistry class would have been like (or could be like today) if the foundation of your chemical knowledge started here.

Technology and Curriculum Developer Dan Damelin goes on to describe how open source programming opens up possibilities. For instance, Jmol is a Java-based 3D viewer for chemical structures that we were able to incorporate into Molecular Workbench to allow people to easily build activities around manipulation of large and small molecules, and to make connections between static 3D representations and the dynamic models of how molecules interact. We’re planning to build a chemical structure viewer that won’t require Java and will extend another open source project based on JavaScript and WebGL to visualize molecules in a browser.

Interested in this innovative programming? Great! We’re looking for software developers.

A Datasheet for NextGen MW

The opposite of Thomas Dolby

I was terrible at the first four weeks of organic chemistry. I just couldn’t get the right pictures into my head.

The depictions of the chemical reaction mechanisms I was supposed to memorize seemed like just so many Cs (and Hs and Os and, alarmingly, Fs) laid out randomly as if I were playing Scrabble. And I swear the letters rearranged themselves every time I looked away, like a scene out of a movie about an art student’s science-class nightmares (minus the extended fantasy sequence in which the letters grow fangs and leap off the page to menace the poor protagonist – unless I’ve blocked that part out).

Fortunately, I knew exactly what to do: I had to start picturing molecules in 3D, and in motion, as soon as possible. That ability seemed to take its own sweet time to develop. But once things “clicked” and I could visualize molecules in motion, the reactions finally made sense, as did all the associated talk of electronegativity, nucleophilic attack, and inside-out umbrellas. I aced the final.

Now, our Molecular Workbench software isn’t specifically designed to help undergraduates get through organic chemistry. It is designed to help students at many levels by letting them interact with simulations of the molecular world so they get the right pictures into their heads, sooner. It’s here to help that future art student and movie director beginning to nurse a complex about the 10th grade science class he’s stuck in right now.

The weight of history

But the “Classic” Molecular Workbench we have now was built for a different world. It runs in desktop Java, for one thing, meaning (among other things) that it’ll never run on iPads. More fundamentally, it was built to be “Microsoft Word for molecules” in a time when Microsoft Word was the dominant model for thinking about how to use a computer:

“Hello, blank page! Let’s see, today I’ll make a diffusion simulation. I should write something about it … Let’s make that 12-point Comic Sans. No, my graphic designer brother-in-law keeps telling me not use that so much, so Verdana it is, then. Now how do I add that model again? Oh yeah, Tools -> Insert -> Molecular Model…”

This model is constraining even though it’s always been possible to download and open Molecular Workbench via the Web, and even though MW saves simulation-containing activities to special URLs.

We have somewhat different expectations these days because of the Web, social media, mobile apps, and casual games. If I build a great in-class “activity” based on a series of molecular models, then I should be able to share that activity with the world with minimum difficulty. And if you find one of the simulations I created particularly illustrative, you should be able to put that model in a blog you control, or include the model as part of your answer to a question on http://physicsforums.com/.

Moreover you ought to be able to perturb the running simulation by reaching out and touching it with your fingers, or simply by shaking your tablet to see what effect that has on the simulation “inside” it. You shouldn’t be required to operate the simulation at one remove, via a mouse and keyboard, when it’s not necessary.

That’s why we’re excited about the Google-funded, next-generation Molecular Workbench we have started to build. The HTML5 + JavaScript technology we’re using to build the next generation of our MW software (hereafter called NextGen MW for short) will make it much more practical to enable these kinds of uses.

Boldly doing that thing you should never do

But designing NextGen MW to be a native of the real-time Web of 2012 rather than a visitor from the land of 1990s desktop computing means that we’re committed to rebuilding the capabilities of “Classic” Molecular Workbench from scratch. That is, we’re doing the very thing Joel Spolsky says you must never do! But ignoring platforms which run Java badly or not at all isn’t an option, and neither is trying to run Classic MW in a Google Web Toolkit-style compatibility layer that compiles Java to JavaScript. (With the latter option, we would almost surely be unable to optimize either the computational speed or the overall user experience well enough to make it practical to use NextGen MW on phones, inexpensive tablets, or even expensive tablets. But even that misses the point. We’re not a consumer products company trying to optimize the return on our past investment. We’re an R&D lab. We try new things.)

But writing things from scratch poses a challenge. We want the molecular dynamics simulations run by NextGen MW to run “the same” as the equivalent simulations run in Classic MW. But “the same” is a slippery concept. In traditional software development, asking two different implementations of a function or method to produce the “same” result often means simply that they return identical data given identical input, modulo a few unimportant differences.

It would be nice to extend this idea to the two-dimensional molecular dynamics simulations we are now implementing in NextGen MW. Classic MW doesn’t have a test suite that we can simply adapt and reuse. But, still, we might think to set up identical initial conditions in NextGen MW and Classic MW, let the simulations run for the same length of simulated time, and then check back to make sure that the atoms and molecules end up in approximately the same places, and the measurements (temperature, pressure, etc.) are sufficiently close. And, voilà, proof that at least this NextGen MW model works “the same” as the Classic MW model. (Or that it doesn’t, and NextGen MW needs to be fixed.)

Never the same thing twice?

Unfortunately, this won’t work. Not even a little bit, and the reason is kind of deep. The trajectories of the particles in a molecular dynamics simulation (and in reality) exhibit a phenomenon known as sensitive dependence on initial conditions. Think of two identical simulations with exactly the same initial conditions except a tiny difference. Now, pick a favorite particle and watch “the same” particle in each simulation as you let the simulations run. (And assume the simulations run in lockstep.) For a very short time, the particle will appear to follow the same trajectory in simulation 1 as in simulation 2. But as you let the simulation run a little longer, the trajectories of the two particles will grow farther and farther apart, until, very quickly, looking at simulation 1 tells you nothing about where to find the particle in simulation 2.

Very well, you say: maybe simulation 1 and simulation 2 started a little too far apart. So let’s make the difference in the initial conditions a little smaller. Sure enough, the trajectories stay correlated a little bit longer. But a very little bit. Here’s the rub: if you want to simulation 2 to match simulation 1 for twice as long, you need the initial conditions to be some number, let’s say 10, times closer. But if you need the simulations to match for 1 more “time” as long, that is, 3 times as long, you need the initial conditions to be 10 times closer still, or 100 times closer. And if you want simulation 1 to make a meaningful prediction about simulation 2 for ten times as long? Now you need the initial conditions to be a billion(109) times closer. In practice, this means that if there’s any difference at all between the two initial conditions, no matter how seemingly insignificant, then outside of a short window of time the two simulations will predict very different particle locations and velocities.

Perhaps you think this is a contrived situation having nothing to do with comparing Classic MW and NextGen MW. Can’t we start them with, not just similar, but identical initial conditions? Unfortunately, this escape hatch is barred, too. The tiniest and most seemingly insignificant difference between the algorithms NextGen MW runs and the algorithms Classic MW runs right away result in a small difference in the trajectories, and after that point, sensitive dependence on initial conditions takes over: the subsequent trajectories soon become totally different. Trying to run precisely the same algorithms in NextGen MW as in Classic, down to the exact order of operations, would not only intolerably constrain our ability to develop new capabilities in NextGen MW, but would be futile: the differing numerical approximations made by Java and JavaScript would result in yet another small difference which would in short order become a big difference.


So, wait a minute: You can’t test NextGen MW against Classic MW because even the tiniest difference between them makes them behave … totally differently? How do we trust either program, then? And how is this science again?

Well, notice that I didn’t say quite say the two programs behave totally differently. Yes, the exact trajectories of the molecules will quickly diverge, but the properties we can actually measure in the real world — temperature, pressure, and the like — unfold according to laws we understand, and should be the same in each (not counting minor, and predictable, statistical fluctuations.) After all, we can do beautifully repeatable experiments on “molecules in a box” in the real world without knowing the location of the molecules exactly. Indeed, when van der Waals improved on the ideal gas law by introducing his equation of state, which includes corrections for molecular volume and intermolecular attraction, the notion that molecules actually existed was not yet universally accepted.

So what we need are molecular models whose temperature, pressure, diffusion coefficient, heat capacity, or the like depend in some way on the correctness of the underlying physics. Ideally, we would like to be able to run a Classic MW model and have it reliably produce a single number which (whatever property it actually measures) is demonstrably different when the physics have been calculated incorrectly. Then we could really compare NextGen MW and Classic MW — and perhaps even find a few lingering errors in Classic MW!

Unfortunately for this dream, our library of models created for Classic MW tend to be complex interactives which require user input and aim to get across the “gestalt” of molecular phenomena (e.g., one model encourages students to recognize that water molecules diffusing across a membrane aren’t actively “aiming for” the partition with a higher solute concentrations but move randomly). The models are not intended to be part of numerical experiments designed carefully to produce estimates otherwise-difficult-to-measure properties of the real world. They require substantial rework if they are to generate single numbers that are known to reliably test the physics calculations. For that matter, there aren’t many Classic models at all that conveniently limit themselves to just the features we have working right now in NextGen MW, and we can’t just wait until we develop all the features before we begin testing.

Charts and graphs that should finally make it clear

Therefore, we have turned to making new Classic MW models that demonstrate the physics we want NextGen MW to calculate, and comparing the numbers generated in Classic MW to the numbers generated when the equivalent model is run in NextGen MW. I’ve begun to think of this process as creating the “datasheet” for Classic and NextGen MW, after the datasheets which contain charts and graphs detailing the performance characteristics of an electronics part, and which an engineer using the part can expect it to obey.

So far, we’ve just gotten started creating the MW datasheet. I’ve written a few ugly scripts in half-remembered Python to create models and plot the results and so far, sure enough, it looks like an issue with the NextGen MW physics engine that I knew needed fixing, needs fixing! (The issue is an overly clever, ad hoc correction I introduced to smooth out some of the peculiar behavior of our pre-existing “Simple Atoms Model.” But that’s good fodder for a future blog post.)

But we have ambitions for these characterization tests. Using the applet form of Classic MW, we hope to make it possible to run each of these “characterization tests” by visiting a page with equivalent Classic and NextGen MW models side by side, with output going to an interactive graph. But with or without this interactive form of the test, once characterization tests have been done they will help us to find appropriate parameters for automated tests that will run whenever we update NextGen MW, so that we can be sure that the physics remain reliable.

I’ll update you as we make progress.

Video: Molecular Workbench Brings Science to Life in the Browser

As we make our award-winning Molecular Workbench software more accessible and widely available, we’re documenting our story at the same time. Google’s grant to the Concord Consortium funds the conversion of MW from Java to HTML5 so it will run in modern Web browsers. This will reduce barriers for using the next generation MW in schools. Students will be able to access the software from a Web page on a school computer, iPad, or smartphone, giving them anywhere, anytime access to powerful science learning opportunities.

We’re creating videos to share our conversion story. We’ll describe Molecular Workbench, our technical development process, and the benefits of HTML5. We’ve teamed up with the excellent staff of Good Life Productions to produce these videos.

In the first video, Concord Consortium’s Director of Technology Stephen Bannasch describes the power of the modern Web browser to bring science to life. Enjoy.


iPad2 HTML5 stats look good

Sencha has the latest on the new iPad’s HTML5 performance, and the verdict looks quite good:

The iPad 2’s Mobile Safari browser is the best implementation of WebKit on a mobile device. In our testing we tried to throw everything we could at the browser and it had no issues keeping up with the most advanced HTML5 and CSS3 sites. For any developer building for the mobile web, the iPad 2 provides an outstanding platform from which you can use modern browser features.

It will be exciting to see how some of our newest Web-based software performs on this device, especially given these advances.