Team:UNOTT/Software

Software

Along with modeling all the possible combinations, another issue the team faced was they wouldn't be able to compare the read fluorescence spectra and compare it back to the mother colony's spectra in the time and resources available, as that would mean they would need to create a brand new construction, test and implement.

 

One solution to this problem was to conduct the verification process through software; this meant reading the spectra into a fluorescence reader to generate a range of data points which could be graphed and then visually compared pixel by pixel or directly compared. Both options were implemented.

 

Another issue the team faced is identifying whether Key.Coli was a user friendly product. In order to test how user's would respond to having to use Key.Coli in practice, a virtual every day environment was developed within Unity which showed a person's everyday life. Actions were monitored and fed back to the team to see how easy it was to operate Key.Coli. as well as identifying any practical problems we would face.

 

Lastly, to put Key.Coli into practice, was to write a security layer on top of Linux on a Raspberry Pi which means it can only be accessed through the Key.Coli password. This protects the computer from intruders, hence completing the objective of Key.Coli

 



  • Image Comparison Software
  • Data Differentiating Software
  • Fluorescent Spectra Predicting Software
  • VKCEnvironment
  • Linux Key.Coli Security Layer








































































































  • Image Comparison Software

    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 1 :

    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



    Download the software here

    1 Image taken from Wikipedia: https://en.wikipedia.org/wiki/Damerau%E2%80%93Levenshtein_distance









































































  • Raw Data Differentiating Software

    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 Python and working with the Spreadsheet's API, 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.

     

    SOFTWARE NOT DONE YET

     





    1











































































  • Fluorescence Spectra Simulation

    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.

     






    • VKCEnvironment

      One problem the team faced was the application problems that would come with using a Key.Coli system. As the project hadn't developed it yet, we weren't able to gain real world data. In order to answer this problem, a virtual environment was created. This would go on to become one of our outreach programs: NOTT Portal. The levels were designed around real world issues for example, using it to open doors, finding out your key is expired and needing a new one and as an application for random number generation.

      Figure 7



      However, we found that we needed to be there personally to watch player's actions, which would make collaborations with other universities rather difficult. To answer this problem, the environment was modified by running a background script to record the user's actions and replay it on our own copy of the program. This let us see everything the user was doing, looking at, and by seeing this, we could determine what they found difficult to get a grasp of.

      This was very useful as it allowed us top identify the problems a user might come across when they first use the Key.Coli mechanism and allow us to make adjustments to answer those problems. For example, one play tester wasn't aware they had to put the Key.Coli on the reader so, the team decided to make the process as simple for the user as possible

      Two limitations of this method were that it was highly inefficient: many low end devices can't run the game as a result and as this is in a simulation rather than real life, results are not likely to be representative of real life behavior



      Download our game here!




    • Are our constructions random

      When constructing our proteins with our current method, there were 3 vectors we could order from etc. we could have a combination of 1,2,3 or 1,1,1 etc.

      However, in this proof of concept, order is irrelevant as each is either constitutively expressed or inhibited thus the system only has 2 3 combinations

      Randomness comes from the fact the system relies on Brownian Motion, a random process to create these combinations.

      However, in order for a movement to fall under Brownian Motion, it must fulfill a condition where the process must have continuous paths. This is not true as once the structures begin to form, the paths stop (they do not collide off each other elastically, but rather, combine.) Furthermore, the bacterium might become biased towards options that put less metabolic stress on the bacterium, which results in selection.