Difference between revisions of "Team:UNOTT/Software"

Download the software here

A major issue the team faced was the comparison between the fluorescence with the mother colony and the Key.Coli mechanism. One option considered was to use image comparison to check how similar the spectra were

Using data from wet lab, a graph can be produced. This graph could be compared using an image similarity algorithm to check the difference between a data set from a certain time point to another data set from another time point.This was very important to the project as it allowed us to compare the fluorescence spectra of one random construction at different time periods.

The image (a bitmap) is scanned pixel by pixel and written into a temporary file where it is checked for similarity with another image using the Damerau - Levenshtein Distance algorithm which was coded in C#. This can be represented as such ¹ :

Figure 1

If the distance is below a threshold, this means the user is given access, as denoted by as "ACCESS GRANTED" message. Otherwise, they are shown an error message. A threshold value was proportional to the time after the first reading of specta; the longer the the sample has been away from the mother colony, the higher the threshold you'd need.

Figure 2 - Software when first opened

Figure 3 - When files are selected and "Compare" is clicked

Figure 4 - The files are too dissimilar! Access isn't allowed.

Figure 5 - Changing the threshold might accommodate this difference

¹ Image taken from Wikipedia

Another method of comparing fluorescence spectra is by taking raw data and comparing them cell by cell. This was a far more user friendly method than using Image Comparison we found the data held the same format in terms of spacing when outputted by the fluorescence reader.

 

One major issue with using Image Comparison is that the images were required to be exactly the same size for it to work and be bitmaps, which is an uncommon image type. Another issue is that if the images were very large, the time would take longer. This would be an improvement over that method as there wouldn't be any images involved

By using Java and working with the libraries which support the spreadsheet format, the team was able to directly compare sets of data by calling for values from each cell and calculating the difference. This was then checked with a threshold value; if it is above the threshold value, it fails the check and the user is locked out.

 

^{Figure 6}

In order to create a formula for calculating threshold values at any given point using data from the mother colony, the team decided it would be appropriate to use Polynomial Fitting as it was found to follow the points the closest when graphed. Using the function from Figure 6 and translating it into Java, this was achieved. Furthermore, threshold could be adjusted by adding or subtracting from the equation produced

Download our source code

 

The software was written as an answer to the team wanting to be see how the spectra would look like after a certain amount of time as well as what the fluorescence would be at a certain time point. This is very useful as it allows the team to know what to expect during the constructions as well as be able to test multiple conditions in a short time

 

To find out more about how we developed this software using models, click here

 

The simulation was written in C and compiled to Linux binaries so it will only work on Linux systems. However, the source code is available so users can recompile it to their OS of choice (compiling code is inside.) In order to use it, navigate to the folder where you are keeping the program files on Terminal and type: ./loader which will activate the program. You then have to type in how much of each protein you are expecting for example, 0.1 micro-grams of sfGFP and then the wavelength of the laser you are using.

 

 

The simulation supports command line interface for these inputs. When parameters are set, the program will calculate the expected fluorescence over time. This will be outputted as shown on below.

 

 

The spectra shown should represent the spectra that would be expected to be produced at those concentrations and wavelengths.

 

When speaking to our industry contacts about Key.Coli, they were very interested in seeing Key.Coli's capabilities as a Random Number Generation tool. After gaining results from the random constructions, the team set to finding out if the values could be used to generate a string of random numbers. The results are as shown.

For comparison, the other values are taken from other pseudo-random and random number generators ¹

However, when checking for a normal distribution, it was found the set of numbers were biased to the the top and bottom of the set ranges, which suggests that a single colony can not be used to generate a set of numbers but rather, one colony can be used for one number (in our case, it was 18, 128 and 125.) This is because the colonies were constructed in a random fashion using Brownian Motion ²

This is still very useful: it means it can be used as a random seed value for a random number generator. Furthermore, one way to get a set of numbers from one colony is to break it up. The team did this and found each colony, despite being genetically similar, had varying levels of fluorescence from each other.

However, this hasn't been tested yet as an enormous number of colonies (200,000) would be needed to evaluate the Normal Distribution. However, future projects can feel free to use Key.Coli to generate true random numbers.

¹ RAND was generated using =INT(NORM.INV(RAND(),XX,XX)) on Excel, Atmospheric Noise was taken from Random.org and Fortuna is used in some Unix based OS to generate security keys

² See Modelling's Are Our Constructions Random

As a final wrap up for the project, all the software and modelling was put together to create an additional security layer on top of Linux for the Raspberry Pi.

This was done to show people how Key.Coli could be used to secure your computer from strangers who don't have the Key.Coli but might know your password as well as giving us a physical demonstration of Key.Coli to show at the Jamboree.

The system was designed as a program that would load when Linux booted up. The system works by locking out the user from files where they can only access the a temporary file where the spectra from the colonies would go. This is compared ¹ and if it matches the threshold, the computer unfreezes.

Using the Raw Data Comparison software developed and modifying it to support the file system on the Pi, this successfully happened. In order to "unlock" your computer, the user would need to connect the Raspberry Pi to two different fluorescent readers: one for the mother colony, and one for the Key.Coli mechanism. Both readings would be stored in a temporary file space and compared for similarity.

However, due to health and safety regulations, for the Jamboree, we read data from conditions in lab and stored them on USB sticks, acting as the Key.Coli and mother colony. This is similar to how the actual system would work, except it has USB drives instead of fluorescence readers