Virtual teaching laboratories – hands-on at a distance

The COVID-19 pandemic disrupted chemistry teaching practices globally as many courses were forced online necessitating adaptation to the digital platform. The biggest impact was to the practical component of the chemistry curriculum – the so-called wet lab. Naively, it would be thought that computer-based teaching labs would have little problem in making the move. However, this is not the case as there are many unrecognised differences between delivering computer-based teaching in-person and virtually: software issues, technology and classroom management. Consequently, relatively few “hands-on” computational chemistry teaching laboratories are delivered online. In this paper we describe these issues in more detail and how they can be addressed, drawing on our experience in delivering a third-year computational chemistry course as well as remote hands-on workshops for the Virtual Winter School on Computational Chemistry and the European BIG-MAP project.


Introduction
The COVID-19 pandemic forced sudden changes in teaching practice, often with very little lead time, thus mobilising the education community to connect and share ideas [1,2,3]. For chemistry, see especially "Special Issue on Insights Gained While Teaching Chemistry in the Time of COVID-19" [2,3]. Remote chemistry teaching has most difficulty in addressing laboratory work -both what is colloquially known as wet and dry chemistry. Notwithstanding the debate in the literature on the relevance of the chemical laboratory in the modern curriculum, due to financial, logistical and safety concerns (see e.g. Bretz [4], Reid and Shah [5], and references therein), there have been longstanding initiatives for providing experimental chemistry laboratory content online. For wet labs, COVID-19 provided the biggest shakeup and was a catalyst for trying alternative approaches. The pandemic forced a legitimacy onto the surrogate use of computer simulations for lab work, initially started with the intention to save on costs of equipment and safety in mind and accelerated the development of such tools. Often in the form of virtual laboratories [6][7][8][9][10][11][12][13], these leverage digital tools from simple videos to simulations (including virtual and augmented reality [8][9][10]). A good overview of virtual laboratories is given by Crabb [11], through her involvement with the Open University Open Science Laboratory [12], North American Network of Science Labs online [13] being its American equivalent. It is doubtful that we will be saying goodbye to the chemistry wet lab just yet, but we are likely to see focus on wet lab skills for only the advanced students. It is early days to see how permanent these substitutes will turn out to be. Naively, it would be expected that dry computational chemistry laboratories would have no issues in remote education. However, this turns out not to be the case as was discovered several years ago when cost-cutting measures found departmental computer teaching laboratories being phased out in favour of centralised facilities [14]. This was countered by cloud computing platforms, particularly suited for computer scientists, giving rise to e.g. AWS Educate [15], CoCalc [16] etc. However, for chemistry this was not so straightforward due to a range of issues: software licensing, lack of technical expertise of instructors to set up virtual laboratories, technical limitations and classroom management. In this article, we will go through these various issues and how they can be addressed, using insight gained while acting on an AWS expert panel for remote learning [1], and demonstrated through our successes in delivering a third year computational chemistry course at the Australian National University (ANU) and remote hands-on workshops for the Virtual Winter School on Computational Chemistry (hereafter referred to as the Winter School) [17].

Virtual computer teaching laboratories
Software environment Many traditional computational chemistry teaching laboratories are based on students accessing specialised software, through departmental computing clusters. Commercial cloud platforms will often not have this specialised licensed software installed and many licence agreements have limitations on where the software can be installed, requiring legal assurances from the platform provider. The issue of licensing can be circumvented by using institutional rather than commercial cloud services but as with free software this then raises the issue of software installation. Commercial cloud providers will provide hardware but it is left to the client to install the software and act as system administrators which many educators lack the confidence to do. In this paper the software packages used were Gaussian 16 [18], the Amsterdam Modeling Suite (AMS) [19], Quantum ESPRESSO [20,21] and AiiDA [22,23]. Of these Gaussian 16 and the AMS suite are commercial software with licensing conditions such that teaching is generally carried out in local teaching labs through Graphical User Interfaces (GUI): GaussView [24] for Gaussian, and the AMS suite comes with its own in-built GUI. Quantum ESPRESSO and AiiDA are open-source software, released under the GNU General Public License (GPL) and the MIT license, respectively, and teaching is facilitated through the Quantum Mobile [25,26] virtual machine, with the flexibility of running on local computers and the cloud.

Network connectivity
Remote computer laboratories tend to have relatively high requirements on internet bandwidth and latency, which may not be available to students who live in geographical regions that are far away from the organisers' servers or who suffer from poor connectivity in general. While these concerns apply to live video transmissions in general, many computational chemistry packages, especially when used for teaching, come with a "native" graphical user interface (GUI) that puts a lot of stress on the communication network when streamed, resulting in very slow unwieldy responses. This frustrating experience likely explains why hands-on fully remote workshops in computational chemistry, which typically involve some sort of molecule or periodic systems builder, are not very common. One way of addressing this issue is for the student to use their personal computer where the aforementioned issues of licensing and software installation come into play (see Case Studies 2 and 3, and section "Software deployment" below). However, this brings with it its own challenges -for example, the student's personal device may not have compute power, memory, or disk space required. Another way is to use GUIs that are designed to run in the web browser (see "browser-based teaching"). An alternative, as chosen for Case Study 1, is to install the specialized software on a compute cloud and have students use the GUI through a Virtual Network Computing (VNC) client. This communication networking solution allows real-time responses while connected to a remote computer, and in recent years has been extended to Virtual Desktop Infrastructure (VDI), in which a cluster of computers can be emulated by virtual machines providing and managing virtual desktops. In this way, the desktop of physical computers at a regular teaching lab can be reproduced in cyberspace and this was used successfully to run computational chemistry Gaussview-based hands-on practicals with both real and virtual students present [27]. However, we do not yet have extensive experience on how well this solution scales, due to bandwidth limitations, with number of participants beyond about thirty.

Software deployment
In a virtual setting, students use their personal computers, i.e. a wide range of different hardware and operating systems. This makes installation of software a nontrivial task, and a wide range of distribution channels are available (some of which are compared in Table 1). Many package managers, such as apt, yum, macports [28] or homebrew [29] are integrated with a specific operating system, which makes for a great user experience but puts a large burden on the instructor to provide dedicated installation routes for every operating system and test the software on the different architectures (commercial software vendors can make this work as shown in Case Study 2). Multi-platform package managers, such as Spack [30] (Linux, MacOS) and conda [31] (Linux, MacOS, Windows) improve upon this aspect but first need to be installed by the students which often requires a certain familiarity with the command line and can lead to interference with existing software on their machine. Container technologies such as docker [32] are available on all platforms, address the problem of isolation from the host operating system and can be a great solution for providing a uniform software environment to a tech-savvy audience. In our experience, however, the lack of a graphical "desktop" with a familiar user interface can be a barrier for students who do not feel at home on the command line. This is where full-blown virtual machines enter the picture: a computer emulation which mimics a computer and operating system (OS) irrespective of the underlying hardware. This technology underpins many cloud providers as the same compute cluster can be used to provide on demand any flavour of OS -Mac/Windows/Linux for as long as it is needed. Using software like VirtualBox [33], virtual machine images can be run on all operating systems and provide both an isolated software environment as well as a familiar graphical user interface.  26], a virtual machine image based on Ubuntu Linux that comes pre-installed with a wide range of simulation codes, tools for structure analysis and plotting, as well as for the compilation of custom software. The Quantum Mobile setup is modular, allowing instructors to create their own flavor of the image with just the software they need, by picking and running the corresponding ansible roles [34].

Browser-based teaching
Since any computer comes with a web browser preinstalled, why can students not simply use the browser to access a cloud platform that runs the specialized software on dedicated servers? Major advantages of this approach include a homogenous hardware environment that can be adjusted to fit the needs of the course, a homogenous software environment and no time spent on software installation. We believe that this approach will gain increasing traction going forward, starting with short courses where any time saved on software installation directly translates to being able to teach more science. Today, however, there are still a couple of barriers to overcome: 1. Many graphical user interfaces for computational chemistry software (e.g. GaussView) do not yet have implementations designed to run in the web browser, and streaming the native applications e.g. through a VNC client can be slow (see above).
Besides tried-and-true browser-based structure viewers like JSmol [35], the 2011 WebGL standard has given rise to a flurry of 3d structure viewers and editors such as GLmol [36], ChemDoodle [37], NGL [38], and more that start rivalling some of the features of native implementations. We expect this trend to continue. 2. End user license agreements for commercial software may put restrictions on where the software can be installed, e.g. preventing installation on commercial clouds. In some cases, this can be circumvented by using institutional rather than commercial cloud services. We expect that license agreements will adapt to this new reality going forward. We also point out that this issue does not exist for open-source software. 3. Setting up a cloud platform for a course requires technical skills that many instructors lack. Less tech-savvy instructors may decide to turn to commercial pre-built platforms such as WebMO [39]. However, we also see large reductions in the barriers to creating your own scalable and fully customizable platform through recipes like the "Zero to JupyterHub" [40], e.g. in combination with Terraform [41]. This approach was adopted in Case Study 4.
Besides these barriers, which we believe to be of temporary nature, there are some more fundamental aspects of the platform-based approach. First, the platform model puts the burden on the organizers of the course to provide sufficient compute power for each participant.
For reference, servers with 2 cores and 4GB of memory are available for roughly a dollar a day, which may be negligible for a one-day workshop with 100 participants or a tutorial week with 20, but can become expensive for long-running courses or courses that attract a very large audience. Substantial cost savings are possible with autoscaling setups like the one mentioned above which boot up extra servers only on demand (i.e. when students are actually logged in and using the hardware). And second, one great strength of the platform approachthe high level of technological abstraction it enables -can also be a weakness: when the course finishes and students lose access to the platform, they also lose access to the software without having learned how to set it up on their own hardware. Upon closer inspection, however, this is a matter of priorities: the browser-based approach simply makes the installation of software on the students' machines optional. If learning how to install the code is deemed important, it can be included as a dedicated session at a convenient stage in the course.

Classroom management
A traditional teaching laboratory is generally made up of an instructor with a team of demonstrators roaming the room, one for every 10-20 students or so depending on the demands of the coursework. Awareness of the ANU COVID-19 protocol for in-person teaching highlighted the extent to which the demonstrators relied on "hands-on" aspects, through the need to see the student's screen and occasionally taking over the mouse and keyboard in frustration. Remote learning obviously circumvents this problem but highlights the difficulty of working with a student with little "contact". This is also a frequently raised objection by students to remote instruction that solely relies on video. Some form of interaction is needed. For one-on-one tuition meeting calls such as with Zoom, WebEx, Skype, Teams with screensharing capability may be sufficient but when one-to-many are involved then there needs to be strategies for classroom management. Typical chat facility of meeting software is cumbersome as questions and answers get mixed and confused. Q&A or comment functionality is better and becoming more frequently used for keeping the communication ordered. However, both approaches are necessarily limited by the individuals' typing speed. As verbal discussion is still more effective than through text chat the use of "breakout rooms" -meeting offshoots where a subset of participants can go off to a separate session -are gaining popularity, but not all platforms have this capability and management tools for such sessions are not yet mature -it is still not straightforward to move participants in and out of these rooms and there is no good communication with them.

Case Study 1 -CHEM3208
Chem 3208 -Molecular Modeling and Computational Chemistry -is a one-semester course for 3 rd year students offered through the Research School of Chemistry at the Australian National University. The quantum chemistry component discussed here was run over 4 weeks for 38 students with lectures being delivered in flipped format. The lectures were prerecorded in compact form, typically 10-15 minute videos, and the three lecture hours per week were spent in a Zoom call, in which the first half hour was silent giving students time to watch the lecture video and communicate questions synchronously through chat. Microphones were enabled for the second half of the session which took tutorial form for questions arising from the lecture, often with an exercise or discussion point to initiate conversation. The practical component was held in hybrid format in a university computer teaching lab seating 30 and allowing students remote access through the ANU VDI, which had been newly deployed [42]. The in-person version of the course in previous years had been held weekly but the ANU COVID-19 requirements regarding deep cleaning meant that only fortnightly 3 hr sessions were possible and so the course had to be rewritten to account for the reduced time for familiarisation with the software. In order to save valuable lab time, "hands-on demonstrations" that would previously have been held in-session were absorbed into the lecture material. The availability of remote access also meant that the students could access the labs asynchronously, though in-person attendance was mandatory and the practical part of the course was decreed to be such that it could be completed within the designated lab hours. This course was an affirmation of VDI as a solution. The four remote students connecting through Zoom on a laptop placed at the front of the laboratory could see and were part of the room as the in-person attendees but more importantly could use the same computer desktops. Minor inconveniences involved reduced visibility of the whiteboard and the ability to attract the attention of the demonstrators (hand raising being replaced by calling out loudly). However, this was more than compensated by the chance to discuss their problems amongst their virtual selves and those in the room through the Zoom meeting and screen sharing. Thus, we were able to treat the remote students equally to those in person, though one concern is whether the technology will scale to more students at further distances. Similarly, in 2020, Ferdinand Grozema, Professor at Delft University of Technology, set up an alternative lab using computational chemistry for first-year bachelor students in Molecular Science and Technology [43]. With just basic quantum chemistry knowledge and a graphical user interface which they could use on their home computers, the students quickly learned how to calculate properties of molecules relevant for opto-electronic materials. Contact during the project was handled via Zoom video sessions and a Slack discussion channel.

Case Study 2 -SCM Workshop
For the 2020 Virtual Winter School on Computational Chemistry we added, as an experiment, a hands-on computer lab to recreate typical "real" winter/summer schools in computational chemistry. For that we showcased the ADF, BAND, DFTB, and ReaxFF modules of the Amsterdam Modeling Suite from SCM (Software for Chemistry & Materials) [44], with whom we had organised their first ever hands-on virtual workshop in 2011 [45]. The issue of software licensing and connectivity was handled by SCM through providing a limited-time licence that could be installed on the student's machine. This approach can be problematic when faced with students with an assortment of machines but SCM have put a lot of work into robust installation packages for Windows, MacOS, and Linux operating systems and it was not an issue. The workshop program consisted of a morning session (10.30-13.00 CET) focusing on molecular systems and an afternoon session (15.30-18.00 CET) on periodic systems, presented by instructors from SCM. Winter School participants were required to register to download the software package and licence, which gave an indication of expected audience numbers.
The webpage for the workshop (Ref. 44, Fig. 1) provided presentation slides, hands-on exercises and inputs. Delivery was by live Zoom lecture with the instructors working through the presentation and exercises with the attendees able to follow and run the exercises from home. Questions were handled through Zoom chat by the SCM staff who were not currently presenting and for the 60 or so participants this proved to be manageable. There was a slight issue in that such a format did not handle different learning speeds well. However, the workshop had a high level of engagement from the participants and received very positive feedback, as measured through comments in the chat, and such workshops will now be an established part of the Winter School program.   26] platform and capability of breakout rooms. Quantum Mobile offers a virtual machine using VirtualBox [33] and this was used rather than the cloud solution. This meant that like with the SCM workshop, connectivity problems were avoided by the program being run on the local machine of each participant. The workshop was held in the morning (9:00-12:00 CET) session and instruction was led by a team of Quantum ESPRESSO developers and required pre-watching an introductory lecture from their existing Webinar series. Asynchronous learning is gaining popularity especially when multiple timezones are involved as time is not taken up for an activity that does not need to be in-person. The live session could then make the most of important in-person interactions: the instructor started with a quick recap of the lecture for those participants who inevitably had not watched the pre-recorded lecture, followed by live hands-on demonstrations and exercises (handouts and input files being available on the workshop webpage: Ref. 46 and Fig. 2) with one-on-one help enabled through breakout rooms.
Registration was limited to 100 participants with four tutors. The timeframe of 3 hours may not have been long enough to effectively use this format. Indeed, one attendee commented "I'm kind of sad that time flew away so quickly!". There was no negative feedback, but the hands-on tutors were not kept particularly busy for such an audience size. Nevertheless, the participants valued the opportunity to engage with the experts and the personal attention they received, and the workshop was judged a success based on the feedback collected from attendees.

Fig 2. Screenshot of the webpage for the 2021 Winter School Quantum ESPRESSO hands-on workshop Case Study 4 -AiiDA tutorial
This hands-on was part of a workshop (http://multiscalemodelling.eu/BigMapWorkshop2020) that introduced the members of the European BIG-MAP project [47] to a range of software tools for computational materials science, including SimStack [48], ASE [49] and AiiDA [22,23]. The schedule is shown in Fig. 3 and started in the morning with 20-minute introductory presentations of each tool in the plenum. In the following, the ~80 participants were split up into three parallel Zoom sessions for the handson (2h on each tool). To minimize setup time, the AiiDA session relied on browser-based teaching: participants connected to a JupyterHub server, where they could log in with their email address and a password of their choice. After logging in, each participant was redirected to a Jupyter notebook server running inside a private docker container where all the necessary software for the tutorial had already been installed (based on the AiiDA lab [50]). After a brief introduction, the participants used the Jupyter notebook interface to work through the detailed hands-on materials (https://aiidatutorials.readthedocs.io/en/latest/pages/2020_BIGMAP/index.html), which included instructions on how to run a Quantum ESPRESSO calculation through AiiDA and introduced them to the concept of how AiiDA stores calculation provenance. Besides the presenter, two tutors were available for addressing specific questions in breakout Zoom rooms. The built-in polling feature of Zoom was used to track the progress of participants at defined points during the 2h period, followed by brief recaps of sections of the tutorial material. Despite this being our first trial of the fully browser-based approach, we received highly positive feedback -100% of participants felt that the browser-based approach worked well, 95% of participants found the hands-on sessions easy to follow, and several comments specifically mentioned their preference for the browser-based approach over downloading a virtual machine image to run locally. From the tutors' perspective, the browser-based approach allowed to basically eliminate setup-related issues entirely, which so far we've not been able to achieve by other means (VirtualBox helps reduce issues substantially but some tend to remain, such as BIOS settings to adjust or participants running out of disk space). Running the JupyterHub on an autoscaling Kubernetes cluster on Amazon web services allowed to keep the size (and thus the cost) of the cluster small during the testing period before the workshop, let it grow dynamically during the workshop, and shrink again to a minimal configuration after the workshop had finished (terraform-based setup instructions are available at https://github.com/aiidalab/aiidalab-k8s). The JupyterHub was shut down two days after the event, giving all participants ample time to take their data home.

Conclusions and Outlook
At the time of writing, it is not yet clear how much the universities we return to will look like the ones we left. However, the COVID-19 pandemic shake-up has forced a rethink of educational practice, and it is generally accepted there will be change [51]. Indeed, we are already seeing the rise of fully online universities, such as the Open University (http://www.openuniversity.edu) or Woolf University (https://woolf.university). It is fairly certain that teaching will move away from lecture theatres, with instructors distributing video lectures early and focusing more on in-person interactions with the students (see e.g. Dane [52] and references therein). The activation barrier to flipped teaching has been lowered with the lockdown providing the momentum to overcome it. Sanjay Sarma, the vice president for learning at MIT, which has been making courses available online for free since 2002, has been quoted as saying, "we don't want to waste our proximity on one-way stuff. It has to be two-way learning". This is particularly difficult to deliver especially for remote laboratory teaching, not having been handled particularly well or avoided completely in lockdown, certainly for chemistry "wet" labs but even chemistry "dry" labs come with their own problems. Delivery is very technology-dependent and video-based tuition can lose interaction and engagement. Including interactivity through email, chat, discussion forums and video calls only go part of the way. More sophisticated strategies based on spatial social platforms, such as Gather [53], SpatialChat [54], and Virtual Reality [7][8][9] show promise of effective engagement as found in our recent experiments in hosting virtual workshops [55]. These workshops were a follow-on activity from our Future of Meetings Symposium [56,57] held last year to explore best practices in remote interactions and focused specifically on delivering engaging workshops to a small, selected audience through the Gather [53] and Glue [58] platforms. The 3D and pseudo-3D interaction format of these platforms, especially when integrated with digital whiteboards, was generally agreed to provide a more engaging learning environment. While the technology is still maturing, we are encouraged and hope the momentum of innovation and development that the pandemic imparted onto the chemical education community continues to push developments in virtual space and will give rise to effective hands-on laboratories even at a distance.