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.


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


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

“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

Women in engineering, a pioneer

“The unbelievable life of the forgotten genius [Katherine Johnson] who turned Americans’ space dreams into reality” http://www.businessinsider.com/katherine-johnson-hidden-figures-nasa-human-computers-2016-8

“Throughout her education, she says she succeeded in part because she was always asking questions — even when people tried to ignore her, her hand stayed up.”

Trailer for upcoming movie about Katherine Johnson, Hidden Figures: http://www.foxmovies.com/movies/hidden-figures

My advice to students for succeeding at the university

1) Study with at least one other student in each class. Get study buddies.

Don’t do it all alone. You will learn from other students, even when you show them how you figured things out. They will keep you honest when studying for a test: no peeking at notes when they ask a potential test question.

2) Schedule plenty of time to study and do homework. Do not overcommit.

Do not get too involved with work, student organizations, athletics, gaming, or partying. There are lots of interesting things to do at the university other than study.

Note: Not following (1) and (2) are almost always the reasons I have seen students struggle at UCSD. Everyone who gets admitted is smart enough. Don’t worry about that.

3) Talk to your professors and TAs.

A couple times during the term, ask them about topics in class or their research.

Do not always ask them about points on homework and tests. That will leave a negative impression of you. It is fine to ask about points, just not as the first question nor the only question.

At their office door, always remind them of your name, and ask them if they have a minute to talk about (fill in something interesting, not points). Do not ask, “are you busy?” Stupid question. Prof’s are always busy! Best not to approach them right before class.

Don’t wait until you are struggling in a class. Always talk to them if you do start to struggle for any reason, even if you haven’t talked to them before. Get help early!

If they know you, then you are more likely to get “the benefit of the doubt” during grading, e.g., drawing the grade line just below you instead of just above you.

4) Aim for A grades. Try to get at least B grades.

To keep open the option of going to grad school or professional school, you need to graduate with at least a 3.0 GPA overall. Also, you need at least 3.0 (B) average in your major if you want to continue in that major in grad school.

Most schools won’t admit a student to grad school with less than a 3.0 GPA, except in unusual, extenuating circumstances and with a sponsoring professor. Don’t rely on that. With less than a 3.0, your options are schools with lower standards, lower reputations, and higher costs.

5) The day before your first day of class, walk around campus and locate your classrooms.

Before serving on an advising panel one day, I asked a barista at Muir Woods the most important thing to tell new students. This is her advice. Sounds good to me.

Fun to see Visitor Maps

We recently added the Visitor Maps plugin to our About page. We are getting about 50 visitors per day. By clicking the “View more maps in the Visitor Map Viewer” link under the map, you can get versions where you can mouse over the map pins, wait, and get a tool tip showing where the pin is located. Here is a static screen shot:


static screenshot of Visitor Map on Aug 12, 2016

Flow-based programming

I recently discovered the Now page and work of Henri Bergius on flow-based programming (FBP). He is developer of NoFlo and lead developer of FLowhub. NoFlo (node.js flow…) is a Javascript tool for FBP, and Flowhub is a graphical development environment for FBP. FBP was invented in the late 1960’s at IBM by J. Paul Morrison.

FBP makes a lot of sense. As far as application-specific apps, see the chemical process simulators COCO, Aspen Plus, and even Reactor Lab’s Division 1, Lab 6, Reactor Networks. Although lacking a graphical programming interface, our web apps have code structured with a similar metaphor of independent objects sending messages to each other, as do the dynamic simulations in Reactor Lab. This metaphor makes writing, expanding, and maintaining dynamic simulations easy.

A screenshot of Reactor Lab’s Reactor Networks is shown here, with a screenshot from the Flowhub clock example below it. Click on an image to see full-sized version.



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.


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.