Given the lack of adequate documentation in the photonics lab, it is difficult for any newcomer to start using the lab without a first-hand understanding of the previous habits and practices. The goal of this paper is to outline the current situation with regards to the IT components of the lab, and to also suggest modifications and changes where appropriate.
Github: Online repository for code, where multiple people can make edits to the same script, with these changes being tracked.
SSH: Secure Shell Tunneling. A protocol for remote execution/running of code on another terminal.
There are 8 PC towers (Lenovo IBM, specific model unknown, but it's quite ancient.) in the Photonics lab, and another 4 of these PC towers in hBar; all PCs have an operating system that runs on Linux ("Ubuntu" / "Fedora"), which are fairly common Linux distributions, with the exception of one running Windows XP, labeled "Table 2 Catalogue PC" in the lab, that hasn't been touched for reasons relating to a faulty CD-drive.
Computers at table 1 (grating spectrometer)
| No. | Function |
|---|---|
| 1 | Oscilloscope, printer, and temperature monitor |
| 2 | Photometer, OceanOptics, rotational stage |
| 3 | Logging and SSH tunneling |
| 4 | Cataloging and file sharing server |
| 5 | APD usbcounter *(Laptop) |
| 6 | Unused |
Computers at table 2 (fourier spectrometer)
| No. | Function |
|---|---|
| 1 | Photometer, linear stage, logging |
| 2 | Unused |
| 3 | Unused (runs on Windows XP) |
| 4 | Unused (laptop) |
All of these computers are tower PCs and run Linux unless otherwise specified.
All of these PCs share a common password (freeasinfreedom) that people in the photonics group know about, and Dropbox account, using the common email hwachong.photonics@gmail.com
The common password is not written down or printed out, since the password is relatively easy to remember, being a string of related words. The common password is used for email, Dropbox, PC passwords, Spotify, even.
Linux is unlikely to be within the immediate experience for outsiders: interface, layout and terminal use is almost always new for outsiders; this makes starting to use the computers, and by extension getting used to the lab, logging, googling within the lab, using the scripts, will take time and effort.
The main benefit is that with Linux systems, the code is almost always home-brewed, and therefore editable and configurable. This is however mostly relevant to the developers of the script.
Rather, code can be executed remotely; the person does not have to be physically present in the lab. This is done so via SSH (Secure shell tunneling). However, instructions / documentation for this SSH system is not documented. Roughly, we piggyback on the Infocomm CCA's server to help tunnel to the school computers. Since the terminal is text-based, the load on their server is usually limited to megabytes, and does not affect their server operations.
At the same time, Linux computers can have Network File Sharing (NFS), where a Network Folder can be hosted by one computer, and mounted by the rest, allowing all computers to share a common data repository that is only limited by the available disk space on the computers. This allows for large-volume data-sharing and archiving. The shared folder is currently used to archive old data, although it does not have a proper method of retrieval and cataloging, and is also not maintained. (many lab computers have not mounted this folder)
It is also possible to distribute computing tasks with a method called MPICH. This makes large-scale data crunching (e.g. image processing, computational simulation) that would not be otherwise possible on a single PC, possible. However, its practical use-case has been limited to computing the value of pi with two RaspberryPis. So far, there has been no requirement for computing tasks that require this scale of distributed computing.
Briefly speaking, laptops are movable while PC towers are not. Laptops can be used together with mobile setups and demonstrations (for demolab) in order to control equipment if needed. Otherwise, a PC will probably be used.
One way to perhaps ease the transition to using Linux is to make explicit the function of each computer, so there is a limited set of commands that have to be run on each computer. We could have say, a documentation and usage manual at each computer, that is specific to its function and provides an explanation of how to use the terminal.
There are several functions that have to be fulfilled.
- Network printer, serve as the SSH tunnel, server for NFS
- Temperature and humidity monitor (Thorlabs TSP01)
- Oscilloscope (Lecroy 9384TM)
- linear translation stage (Thorlabs MTS8)
- rotational stage (Thorlabs CR1-Z7)
- OceanOptics spectrometer (USB4000)
- EdmundOptics Digital Laser Photometer
- APD counterscript and display (Perkin Elmer Silicon Avalanche Photodiode from CQT)
- Webcam (from like, 2004/5)
Items from 1-8 on the above list are supported (by the code). I haven't really touched the webcam yet, although it does work (i.e. can take pictures and video recording) It's also from 2005 so the image quality is horrendous at best. The resolution is on the order of 300x200 pixels.
Also, functions for human-use include:
- Logging PC for each table
- Catalogue PC for each table
- Emailing PC
- Googling
Given that there are two tables, this totals up to 17 computing devices. We currently have 10 in the lab, implying that we could have to get 7 more.
It is possible to use devices-other-than-PCs like a RaspberryPI, or a Windows PC. It would make sense for the logging / catalogue / emailing / googling PCs to run on Windows, since that is much more familiar.
At the same time, someone (that is zhengyang) will have to write documentation for important scripts for printing manuals, as well as some degree of in-line documentation for future reference and maintenance.
Scripts are hosted on the Github repo, where a copy of the scripts can be 'pulled' (downloaded) onto new computers and used as they are.
There are some README.md files in some of the folders (fruitScope, helpers) that document how they are supposed to be used, and what exactly do people use. This is however, incomplete. Documentation has also not been written for all folders.
Ownership of the repository belongs to Yudong, although it is to be noted that only people who want to contribute to the repository are relevant here. It is probable that someone in the future will have to know how to manage this repository.
Limited to inexistent in-line documentation (within the script). In-line documentation is important for people trying to edit / modify the scripts, since personal conventions / naming systems are not shared across people.
Some regular documentation is available on the Github repository in the scripts' respective folders. However, there are no hardcopies of the documentation in the lab, and the documentation is not complete; documentation should include examples of use cases that will be immediately relevant to the user (i.e. what to type) as well as an explanation of its full range of options and settings.
Troubleshooting documentation is also limited, and suffers similar problems (no hardcopies, incomplete, little reference to it in the lab)
The options and flags available for each script, and the workflow is inconsistent. (Workflow referring to the process of acquiring the data, meta-data, then processing it for plotting, and then plotting and fitting the data) What is standard, is that scripts that are used, do output a tab-separated ASCII file, which is platform-agnostic. Datafiles are typically saved with the timestamp as the filename (YYYYMMDD_HHMM) within the same folder as the script file. Some scripts include an option which allows the user to name the file, so as to provide relevant information on the details and conditions of the measurement. This is however, inconsistent.
Without updating any libraries, the code should work for a long time. However, computers are likely to be updated or upgraded at some point in the future. Also, the code implementation as it is, is generally functional (can save data from equipment, and change relevant settings) and it's not likely that new features have to be implemented, although it is possible.
The Python code runs on Python 2, which is syntactically different (but not largely so) from Python 3. Any person with experience in writing Python is sufficient to change the code to Python 3.
Links to the documentation are provided (Lecroy Oscilloscope, Thorlabs APT controller) in the GitHub repository; implementing new features can be done with some skill, although the troubleshooting and specific processes are not documented anywhere.
Network printing is limited to computers inside the photonics lab. Yudong has demonstrated remote printing over SSH, but on the whole, people end up using the computer that is connected to the printer, to print,somewhat defeating the purpose of having a network printer.
Unsure about the status of the network function of the printer.
hwachong.photonics@gmail.com has a Dropbox account with a common password. This account has 1.5/2.0 gigabytes of free storage used, most of the storage being taken up by the hbar folder. Some data is stored in personal folders inside this Dropbox account.