When people talk about simulations of labs, they are, these days, often referring to computationally expensive, 3D virtual or augmented reality, graphically rich software. As an engineer of a certain age who started their career in simulating physical systems, for me, simulations can be significantly more numerical than graphical and this has led me to consider if simulated practicals could be altogether more straightforward.
Engineering simulations are nothing more than theoretical descriptions of how the world behaves. If you are asking a student to determine the force required to accelerate a 1,500 kg car at 3.5 m/s2, the solution to the problem is essentially a simulation of the real world. While simulations are generally more complex, they are, in essence, just crunching numbers.
My interest in simulated teaching practicals started at the beginning of the coronavirus lock-down. One of the easiest methods to translate an existing activity from an in-lab to a remote format is to supply students with some stock data. Because I always have a fairly detailed pre-experimental activity for the students to perform, understanding how equipment works and the procedure to adopt during that activity is normally flipped and delivered before the student arrives at the lab class. So the provision of stock data allows students to imagine they have captured it themselves and can process the results for analysis. I’ve gone as far as to ask students to manually copy the supplied data into their lab books and continue from there. But when considering tactics for meeting learning outcomes, there is an experimental competence that the supply of stock data fails to deliver: Establishing the design of a data capture strategy.
If an experiment is to discover a relationship by setting an independent variable and measuring a dependent variable, students should make decisions about the settings of the independent variable. With the supply of stock data, this decision is taken away. So I wanted to find a quick and cheap method to provide students with data in a way that forced them to question what data they wanted and, hopefully, why they wanted it.
In order to build a system that would produce an output from a given input, you need two things. Firstly, you need to know the expected relationship between input and output. Secondly, you need a tool that can perform calculations. I decided to use Google sheets for the task, although any calculator tool with a limited amount of programming capability (Matlab, Excel...etc) will do.
The reason I chose Google sheets was that a) it’s the corporate solution for the University of Sheffield and b) the scripting you can implement below the surface is java, which is so much nicer than the utter tosh of Visual Basic that is used in Excel. The downside of Google sheets is that, because it has the concurrent user feature (which is lovely for so many collaboration tasks) it does require students to make their own copy of your file to work on, which is an administrative step that needs to be factored into the instructions you provide.
My original plan was to simply set up a spreadsheet that had an obvious place for students to enter an input variable and another place where an output would be generated. There are a number of tactics to avoid seeing “under the hood”, which I’ve no particular reason to hide from them other than maintaining the concept of experimentation and thus a discovery of the unknown through trial and error. And possibly to hide a little bit of my inelegant code. These include locking certain cells with a password, hiding sheets and making text the same colour as the background cell colour.
There is also the chance to add in a bit of error into the output from the calculations. This can be achieved with a random function. No two students get the same answer and it can represent the error that may be created through experimental measurements. If students take many readings statistical analysis can be taught and if more than one parameter is used in calculating the output, then simulating the propagation of error is also possible.
But there is a downside with students collecting lots of data. When you are in the lab there is an inherent limitation on the amount of data you can collect, which is that it takes time. If it is possible to obtain data very quickly, a trivial data capture strategy, such as taking 100,000 data points across the range and resolving the relationship between input and output in a highly refined way. This isn’t teaching much about carefully considering which measurements to take.
So I decided that I wanted to mandate a certain degree of effort required to obtain measurements. In the real world version of the systems I’m simulating, students measure flow rate by timing how long it takes to fill a tank of water. So when I’ve designed my simulations, I’ve introduced a pause between requesting the measurement and it being displayed. It also, as a pleasing side effect, makes it appear as if the computer is processing a complex calculation, whereas, in fact, the numerical values are calculated almost instantaneously.
Then I got a bit carried away with the possibilities. I decided to animate a “waiting for results” sequence by alternately changing cell background colours. I set up a little message box that provides students with feedback when they interact with the system. I created a schematic of the equipment by creating cell borders. Overall, the simulations took a considerable amount of time to construct - tens of hours. More straightforward simulations could be developed, but I found the process engrossing and I could see the potential value in developing such a tool. For remote learning it is a valuable asset. But for the return of routine in-lab practicals, this will form a useful preparatory/training tool for blended learning, an opportunity to open the learning to students that couldn’t attend the timetabled sessions for whatever reason and to open the learning up to the world.
In the process of constructing my simulations I’ve learned a few things. Things I will certainly do differently when I make more simulations. These considerations are probably the same for all non-trivial coding projects and not news to software developers. But I’m not a developer - just someone that clumsily hacks about with a computer from time to time to automate jobs.
Start out on paper. My approach was to write some code that performed the basic function of generating an output from a given set of inputs. I then continued to add features piecemeal as I had more time to enhance the functionality. The result is nothing short of a hot mess from a programming perspective, with no consistent methods for achieving similar tasks, multiple instances of the same variables and comments all over the code, firstly trying to explain why it works the way it does and secondly apologising to a future version of me who is reading it and trying to fathom what on earth is going on. If I were starting over, I’d have drawn out my equipment, made a big list of all of the states, values and controls for all of the components of the equipment/instrumentation, then worked out how it all connects together. You don’t need to build it all at once, as a reduced set of functions can be implemented in a broader framework, but building the framework as you go along leads to a precariously thrown together end product.
Be Modular. After making a number of simulated practicals, it turns out that many of the attributes of one experiment are similar to others. If you think about building each component as a generally reusable object, it makes developing new simulations much easier, as you can bolt together previously built tools. It also reduces the need to recreate instructional material for students. If all the simulations function in a similar way, components of teaching material can also be bolted together, where appropriate, from previously developed instructions for how to use the simulations.
Good enough is good enough. One of the simulations I’ve made models flow in pipes, which is essentially the relationship between pressure in the pipe and the amount of water going through it. Anyone that knows anything about fluid mechanics knows that for a given amount of water flowing it is fairly straightforward to work out what the pressure will be, but this isn’t reversible. For a given pressure, the method to determine the flow rate is a disheartening proposition, from a numerical calculation perspective. In my laboratory, the equipment sets the pressure and allows students to measure the flow rate. Nature doesn't have to worry about doing the maths. I started building some robust lines of calculations, with lots of (((s and )))s and some slightly less accomplished numerical methods to iterate to a converged solution. With not much time to finish it off, it wasn’t behaving as it should and I didn’t have the luxury of time to debug what was going wrong. So I cheated. I constrained the input variables to a large, but finite, number of combinations and, with a tortured series of nested if/else functions, I specified the output for every combination. With the inclusions of a bit of randomised errors the students won’t be able to tell the difference and I can come back and proudly do the job properly when there is less pressure from having to mitigate the impact of a global pandemic on delivering high quality teaching.
Get the students to do the work. Building these simulations was a lot of fun. I genuinely got sucked into the task and hours flew by without me noticing. It is a job that delivers a working result quickly, is technically challenging, requires a reasonable amount of organisation and systematic thinking and, of course, is the application of underlying theoretical knowledge. Building simulations is the perfect student project and even more perfect when looking for projects that can largely be delivered remotely. My plan is to engage students with the opportunity to build simulations, write the technical manuals to allow it to be tinkered with in the future and also develop the teaching material to provide to their peers. If it works out, the students will be both teaching and learning - which will certainly be a worthwhile payback for all of those hours that flew by unnoticed.