Category Archives: HTML5

Evolution of Reactor Lab

Reactor Lab celebrated its 27th anniversary in March 2020. Starting in 2003, the desktop version was integrated with the Internet, with advanced features for that time.

These advanced features included automatic download and installation of updated files for off-line work, a conference (chat) room for discussions within Reactor Lab, and the ability to run process simulations involving local units and units at other locations in the same system. At that time, one could not assume constant connection to the Internet, as we do now. Once, from San Diego, I had a three-way discussion with a person in Michigan and a person in Turkey in the conference room.

I retired from the University of California at San Diego – UCSD – in 2014. Since then, my interest has shifted from the desktop version, which was constructed with LiveCode, to the HTML5-based Web Labs at this site.

This shift has been for a number of reasons, including omnipresent Internet connection in much of the world, almost everyone has access to the web and a web browser without having to download an application file, and the fast speed of Javascript built into web browsers.

That said, desktop apps have advantages over web pages such as saving data files to disk. In Web Labs, one has to go through an extra step to copy text from a popup window and save to a disk file. There are so many features that were built into the desktop Reactor Lab that duplicating them all in HTML5 might not happen.

I used to post standalone application files for Windows and Macintosh. With the evolution of operating systems and the evolution of LiveCode, I no longer wish to make the revisions necessary to build standalones.

However, one can continue to use the desktop Reactor Lab on Windows, Mac, and Linux. This can be done by opening Reactor Lab in LiveCode, version 8.0 or higher. LiveCode can be obtained at LiveCode.com. Download the free, open-source version of Reactor Lab from my github site at github.com/RichardHerz.

Instructions for how to do this are posted at the Download tab.

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.

Web Lab design progress

We have been working on our web page design project, lcCardLayoutToWeb, which is posted at GitHub. Here is a screenshot of a test page.

This project allows one to layout a web page in the LiveCode IDE, then export it to HTML and CSS files. The new work makes the process reversible. Exported pages can be edited to include links to Javascript files and references to Javascript functions in HTML events. Then the edited page can be imported into our LiveCode project for further editing of the layout: moving, adding and deleting elements. Then the revised page can be exported back to HTML and CSS files with the file and event references preserved.

This new work should allow us to make interactive web apps more easily.

See our newest Web Lab, “Dynamic diffusion and reaction in a porous solid catalyst” at the Web Labs tab above. See the latest version of this web lab in our open-source projects at GitHub, https://github.com/RichardHerz/.

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.

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.

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.

Web app experiment 3 posted – control of reactor T

Web app experiment 3 demonstrates feedback control of temperature during reaction in a continuous stirred tank reactor (CSTR). See the Resources tab, Web app experiments. Below is a static screenshot – click to enlarge.

web_app_3_image_4

At default conditions in manual control mode with constant inputs, the system oscillates. Do you know why the system oscillates? See the Resources tab, CRE Notes, 15 – CSTR thermal effects. Then put the system into Auto Control mode.

Web app development progress

We are making progress in developing web apps using HTML5 technologies – Javascript and CSS. We have one HTML5 web app posted and are continuing to revise it as we develop our approach. See Web app experiments under the Resources tab.

The architecture we are using is that of separate code objects, representing separate process units, which send messages to each other. This architecture allows us to change a simulation easily by adding or subtracting units from a system model.

These dynamic simulations solve a set of coupled, first-order, ordinary differential equations. This type of system is termed an “initial value problem.” The solution method is stepping in time (the independent variable here) using the Euler method. The Euler method has inherent numerical errors, as do other numerical methods, but the solutions can be corrected to approach the exact solution, as we have done in several labs in the desktop Reactor Lab.

LiveCode apps on the web – loading speed may improve dramatically

Experiments by others show that the speed at which LiveCode web apps load can be made much faster through several techniques. In my first experiment, the files loaded to the Western US from the LiveCode server in France. Putting the large files, which are common to all LiveCode web apps, on CDN’s (Content Delivery Networks), which post copies on servers around the world, may speed loading dramatically. Other techniques may include loading only the parts of the modular LiveCode engine that are needed for a specific app.

See work by [-hh] at the LiveCode Forums and click the link “test it here” on that post.