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.
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.
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.
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.
I’ve been watching some of the streamed talks at the annual LiveCode conference. It’s being held this year, August 2-4, 2016 in LiveCode’s home town of Edinburgh, Scotland. Wish I could be there live! Check out the free, community edition of LiveCode. There are also paid versions to protect your IP in commercial products.
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.
HTML5 web apps have the advantage of cross-platform deployment – of a single set of files – on all platforms (operating systems) via web browsers. Web apps don’t have all the functionality of desktop apps and smart phone apps but they do have the main functionality we are looking for. LiveCode has cross-platform deployment on the desktop and as smart phone apps but you have to build and deploy a separate distribution for each platform. Web deployment is under development in LiveCode version 8 but our initial experiments show that loading the first app is slow: about 40 s currently in my browser in California fetching the page from the server in France, where load times increase with distance from the server. But this is a development version of LC 8 and speeds may improve in the future. In contrast, HTML5 web apps are small and load fast.
Layout of LiveCode screens (“cards”) is easy and fast. Just drag and drop both active (e.g., buttons and widgets) and graphical elements. You can easily change the appearance and locations of elements with script when the app is running – so far it seems more easily than in HTML5. For HTML5 apps, we are using the desktop tool MACAW. In that tool, you can also drag and drop elements onto a page, then generate HTML and CSS files but not nearly as easily as LiveCode.
Bottom line of initial impressions? LiveCode wins in ease of development and power. HTML5 wins in deployment – one set of files across all platforms – and speed of loading. We are leaning to devoting our efforts for future development to HTML5, although we are going to keep an eye on LiveCode to see if the speed of loading web apps improves significantly.
The advantage of this approach is that we can develop new apps quickly using LiveCode, which is a rapid app development tool.
This is very new technology for LiveCode and we expect much improvement in the near future. Get the free, open-source “Community” edition of LiveCode here (link).
Reactor Lab was built using LiveCode. Get the free Community version at LiveCode.org. LiveCode is great because it is cross-platform: write once and deploy on many platforms. Another advantage is that the stack model and scripting language are very stable in the sense of supporting past versions: some of the script dates from 1993 and HyperCard.
In most cases in Reactor Lab, the speed of LiveCode is sufficiently fast. The most demanding lab using math computations in LiveCode script is Division 7 Biological Reactions, Lab 3 Immobilized Enzyme Profiles. In that lab, as the user moves a slider to change an input parameter, LiveCode solves a second-order, ordinary differential equation using the iterative shooting method, and then updates the graphics.
Calculations in the dynamic Catalyst Pellet are too demanding to run in LiveCode script. That lab has a detailed, elementary-step simulation of carbon monoxide oxidation over a porous solid catalyst. A function was written in C++ to do finite-difference integration of a set of partial differential equations. The external is then compiled separately on Mac and Windows to make an “external” (.bundle on Mac, .dll on Windows). The LiveCode stack calls this external to do the calculations. The advantage of an external is that it is fast. The disadvantage is that you must compile a separate executable for each platform.
When the Catalyst Pellet external was written in 2008, we used Revolution 4, where Revolution was the earlier name for LiveCode. The Catalyst Pellet and its external ran great when we finished it but it is not compatible with later versions of LiveCode. Therefore we pulled the dynamic Catalyst Pellet out into its own standalone app. The problem presumably is that the interface specification between externals and LiveCode changed. The stack and its external initially appear to run in LiveCode 7, but there appears to be a memory leak and a crash ensues. We haven’t had the time to keep the external up to date. The original version posted in the Download section works well.
The speed at which LiveCode 7 updates the card graphics appears to have slowed from previous versions. This may be related to the addition of resolution independence and higher resolution target displays. To speed things up, we lock the screen before changing many separate elements in the display, then unlock the screen when everything on the card has been updated.
We are in the process of designing a new web site. The links above are active, and you can download the Lab. We are using a WordPress template. The site is hosted at On-Rev.com, which allows scripting with the LiveCode language.