Category Archives: Software Development

Web Lab development update

We now have six web labs posted. The newest is the dynamic heat exchanger simulation, and we recently updated the code structure of the reaction-diffusion lab and first temperature control lab to match the newest version.

In addition to the jquery and flot (plotting) libraries, each web lab is driven by six javascript files: (1) _main which runs the simulation loop, (2) _interface which handles the run-pause and reset buttons and gets and verifies inputs from the input fields, (3) _units which has simulation parameters and the process unit code, (4) _plot_info which contains definitions of the plots, (5) _plotter which makes the profile (static x,y) and strip chart (scrolling x,y) plots, and (6) _spacetime which makes the space-time, color-canvas plots.

Four of the six files are the same for all web labs. The two files specific to an individual web lab are the (3) _units and (4) _plot_info files.

We are amazed with the fast computational speed of javascript! Somewhere recently I read that the speed of javascript in browsers has increased by a factor of ten in the last year and a half. Years ago, computation in LiveCode (as MetaCard) was many times faster than javascript. Now, computation in javascript for our labs is much faster than native LiveCode script, although LiveCode 9 makes coupling to other languages for computation possible.

A feature unique to the heat exchanger lab is a check for attainment of steady state. When no significant changes to the system state are detected, the main simulation loop continues to run but unit computations and display updates cease until a change in input parameters is detected. When steady state is reached, the CPU load of the simulation decreases significantly. We don’t plan to implement this for the reaction-diffusion and temperature control labs because these usually operate under unsteady-state conditions.

The code is developing over time as we follow our usual development practice, which is repeat the following: (1) get something working, (2) notice repetition, (3) reduce repetition by writing functions and common library files.

25th anniversary of Reactor Lab this month!

Reactor Lab is a pioneer in developing interactive simulations for active learning. This is a screenshot of an experiment in the Lab in March 1993 – 25 years ago this month. The Lab was a single HyperCard stack. Click on the image to see a larger version.

RL_March_1993

Here is the same experiment in today’s desktop Reactor Lab.

RL_now

A brief history of the development of Reactor Lab through 2006 is available at LiveCode Journal. The article refers to Revolution, which was LiveCode’s previous name.

Web Lab control examples

At our GitHub pages, we added examples of the individual controls – checkboxes, radio buttons, plots, etc. – that we use in our Web Lab simulations. These examples are easier to read and understand than controls embedded in a complete simulation.

See these examples at our GitHub site

In addition, all of our Web Lab source code can be viewed in your web browser by viewing the page source.

Space-time plot added to web lab

Space-time plots are a beautiful way to view dynamic reaction-diffusion systems. We added one to the Web Lab, “Dynamic diffusion and reaction in a porous solid catalyst.” Here is a static screen shot from the lab.

Adding this dynamic plot required learning how to program the HTML5 canvas element with Javascript – an exciting combination!

We prepared static plots of space-time data for our previous research work, e.g., at http://escholarship.org/uc/item/9bc7v3kv. We were inspired to make them dynamically by the fluid dynamics simulations of Oliver Hunt at https://nerget.com/fluidSim/ and Daniel Schroeder at http://physics.weber.edu/schroeder/fluids/. Those pages showed us that this was possible to do in a web page.

Open-source Reactor Lab

We recently released the desktop Reactor Lab software as an open-source project on GitHub. View our open-source projects at https://github.com/RichardHerz. Contact us if you are interested in using this version or learning more about the structure and the code. The Lab is constructed with the open-source, Community Edition of LiveCode, which can be obtained at https://livecode.org.

Web app code structure

The first two web labs listed at the Web Labs tab have the latest Javascript code structure. Our approach is to have a collection of Javascript code objects, each of which represent individual process units, or “unit operations” in chemical engineering terminology. Each process unit object contains definitions of variables that define the current unit state, and methods that update the unit state at each time step. One objective is to make the unit code objects as independent as possible so that they can be copied and used in other simulations.

In an earlier post, we mentioned the web apps being developed by Tony Butterfield. His web apps have a different structure than ours, and it is interesting to compare these two approaches. You can view the source code of the web apps by choosing View Source in your web browser.

Butterfield’s web apps have a parent code object that defines a child object for each variable in the simulation. This is in contrast to our collection of process unit objects. You might say his app structure is variable-centered, whereas ours is process-unit centered. His variable object definition appears to have been entered in a spreadsheet and then translated to Javascript, since it is minified.

Butterfield’s web apps have a single method that updates the state of the simulation at each time step, vs. our process unit objects, each of which contain a method to update themselves at each time step. For plotting, his web apps record variables values at each time step in each variable object, vs. our 3D numeric array that records the history of all variable values, with individual process objects storing only their current values.

Both approaches work, and it is valuable to have a choice for web app development.

Margaret Hamilton and another approach to software development

I was interested to learn about the work of Margaret Hamilton, who was awarded the Presidential Medal of Freedom yesterday. As a young woman, she led a team that designed the flight control software for the Apollo moon landers. This period was during the early days of computer programming when software design practices were just starting to be invented. Hamilton developed a theory and methodology for “design before the fact” of fault-free and fault-tolerant, real-time software control systems. The class of systems considered are asynchronous, discrete-event systems. This includes chemical batch process scheduling and control. Our web apps simulate continuous processes. Design Before the Fact contrasts with the development strategy we use, as outlined in my last post, but we will learn from Hamilton’s work.

Also at the ceremony at the White House yesterday, Grace Hopper was posthumously awarded the Presidential Medal of Freedom. She was an early pioneer in computing, invented the first software compiler, and popularized the idea of machine-independent programming languages.

Web Labs – our development practice

The goal of our Web Labs is a toolbox that enables development of interactive web simulations or “labs,” and a set of labs built with this toolbox. Our development practice is as follows.

First, Get something up on the screen. Often this involves finding an example on the web and modifying it. Don’t spend a lot of time designing and thinking before something simple gets running. We believe that it is better to get something useful running than it is to have a beautiful plan and theory in development but nothing working to show for your time.

Second, repeat the following:

  • Add functionality.
  • As we observe repetition of code and see patterns developing, generalize the code. Have the objective of maximizing code in libraries and minimizing code needed to build new labs.
  • As we observe patterns developing in the user interfaces, refine the design of a user interface guideline that is simple and consistent between labs in order to speed development of new labs and speed user comprehension when entering new labs.
  • As we have time or run into problems 😛   read and learn about Javascript and CSS and design principles and try to incorporate better practices.

The most recent versions of the Javascript code are the first two labs listed at the Web Labs tab. The other experiments work but have code that was developed at an earlier stage of this software development process.

23 years of Reactor Lab and interactive simulations for active learning

Reactor Lab is a pioneer in developing interactive simulations for active learning. This is a screenshot of an experiment in the Lab in March 1993, when the Lab was a single HyperCard stack. The screenshot was taken after it was converted to a LiveCode stack to keep it alive and operable on today’s computers. Click on the image to see a larger version.

RL_March_1993

Here is the same experiment in today’s Reactor Lab.

RL_now

A brief history of the development of Reactor Lab through 2006 is available at LiveCode Journal. The article refers to Revolution, which was LiveCode’s previous name.

 

Fabrik – early visual flow based programming tool

In an earlier post, I wrote about flow based programming (FBP). Recently, I ran across Fabrik, which was one of the first visual tools for FBP. One inspiration for Fabrik was Show and Tell.

In chemical engineering we wire, or rather pipe, visual components together in application-specific software tools to design chemical processes (see Resources, COCO Simulator here) and process control systems (Matlab Simulink).

“Fabrik – A Visual Programming Environment”
Dan Ingalls, Scott Wallace, Yu-Ying Chow, Frank Ludolph, Ken Doyle of Apple Computer.
presented at ACM, OOPSLA 1988 Conference Proceedings
http://web.archive.org/web/20080511202219/http://users.ipa.net/~dwighth/smalltalk/Fabrik/Fabrik.html

“Fabrik is a visual programming environment – a kit of computational and user-interface components that can be “wired” together to build new components and useful applications. … A kit is a set of primitive components, together with a framework for connecting the components to do new and interesting things…. The kit approach has been around for a long time, manifest in the subroutine libraries of the last three decades. However, the ability to browse through, and experiment with the available components was extremely primitive, owing to the textual orientation of underlying computing environments during those early years. … With the advent of iconic user interfaces, nontechnical users — those not trained to appreciate invisible objects and connections — are able to work concretely (by pointing at an image) with data and functional components.”

Fabrik flow based programming