Giter Club home page Giter Club logo

evolver's Introduction

Experiment setup instructions

  1. Autoclave vials with lids on.
    1. For “open” vials, it is not necessary to autoclave the needles.
  2. Clean lines with sterile water (20s), and 70% ethanol (20s).
  3. Weigh empty vials, note OD of (optional: washed) dense cultures.
  4. Fill each vial with 25mL of media. Connect and run efflux lines with cleaned efflux needles. Weigh final culture volumes.
  5. Once vials are connected to the fluid lines set up the experiment.

Setting up the experiment:

  1. Open up an iterm2 terminal (Command+space iterm2).
  2. We use bash instead of the default terminal. Type in bash and hit return.
    1. If this was done right, the prompt should change, and should be preceded by something like (py37) which indicates that the virtual environment has been loaded.
  3. In the file browser (“finder”), navigate to Documents/dpu/experiments/.
  4. Duplicate the evolver/ folder, and name the duplicate with a descriptive name. Typically YYYY_MM_DD_keywords_separted_by_underscore.
  5. Switch back to the terminal window and type in cd ~/Documents/dpu/experiment/NAME_OF_YOUR_NEW_DIRECTORY
  6. Start the visual interface to populate the configuration file by typing in streamlit run visualize.py. This will return a localhost IP address with a port. Copy and paste this in a browser window.
  7. Populate all the fields, and press ‘Write to configuration file’. NOTE: If you are running a calibration, or if you are not planning on using a calibration file, LEAVE THE “Calibration name” field BLANK!!!
  8. Alternative approach: The folder has an example_experiment_parameters.yaml file. Edit the contents of this file and save it to a file called experiment_parameters.yaml in the same directory.
  9. If you are running a calibration:
    1. Include the word “-calibration” in the experiment name.
    2. Currently, if the per vial parameter calib_end_od is left at its default values (0), it is assigned a value calib_start_od/10. Please explicitly specify this parameter taking into consideration the sensor readings saturate around 0.075.
    3. Open a new terminal window, load bash, navigate to the experiment folder, and start the calibration by typing in python eVOLVER.py. This will display the calibration settings. When prompted about blanking vials, type n.
    4. The calibration will stop at the last step. Collect the efflux from each tube. Select all the vials from the Rpi touch interface on the eVOLVER and run the efflux for 10s. Measure the ODs. Multiply the ODs with a factor of 1.2 if measuring efflux culture.
    5. Go back to the web interface, update the calib_end_od with the new ODs, write this to file again. NB: The old file will be automatically renamed and time stamped.
    6. Open a new terminal, load bash, navigate to the experiment directory as in STEP 5.
    7. Type in python write_calibration_to_file.py. This will create a CSV file with the name of the calibration experiment, the same as the experiment name.
    8. Next, switch back to the browser and type in the name of this calibration. The real experiment will need to have a different name.
  10. When the experiment config file is filled, switch to the terminal and in a new tab (load bash and navigate to the experiment direcotory), type in python eVOLVER.py
  11. Sanity check the experiment settings, press n when prompted for blanking the vials, and the experiment should start.
  12. When the experiment is running, a new drop down option should be added corresponding to the experiment name, displaying all the plots.

Current design

  1. The major caveat in passing message to the Rpi with the current design is that the strings are all expected to be 16 values separated by commas. This is currently handled by looping over vials which has a list of 16 integers, and populating lists like volumes, rates, and periods by looking up indices from other data sources like user defined variables. This is pretty low level right now, and there is no real API to arbitrarily control sleeve behavior without resorting to hacks like creating custom log files for history dependent control of sleeves
  2. There are low level (arduino-level) event logging requirements which are going to be important to debug. This will impact things like:
    1. Frequency of data logging
    2. Types of data that are logged systematically (pump events in chemostat mode etc)

Issues

I am not a fan of this design, where the custom script is loaded in order to first load parameters, but control is then handed back to eVOLVER.py. Custom imports

  • Ideally, the config file is read once, and parameters are passed around in some data class or similar. See Issue http:github.com/amoghpj/evolver/issues/1.
  • No consistent API in adding custom experiment handling. Need to move away from using per-vial logic in a loop like it is currently setup.
  • Define defaults for stirring control that are passed explicitly to each function definition

Calibration strategy

We can perform an in-vial calibration by diluting out a dense culture by dispensing media of fixed volumes repeatedly. Interestingly, performing a 100X dilution in steps uses far less media than doing it in a single step. The total volume of media consumed as the bolus size → 0 is - volume_vial * log(endOD/startOD).

Below is a visual depiction of the relationship between bolus size, number of steps needed to hit endOD, and the total volume dispensed.

img/example-fractional-dilution-cumulative-volume-dependence.png

evolver's People

Contributors

amoghpj avatar

Watchers

 avatar

evolver's Issues

Special handling of growthcurve

Currently, since there is no explicit logic in growthcurve the to_run parameter is ignored. This leads to errors downstream, if the user specifies running online growth rate estimation which requires the calibration data for vials which are missing.

Exploit logging to store more events

Not sure what the purpose of logging is right now. It only seems to note the times that the computer reconnects to the eVOLVER. Can we use this to log more state changes?

Start using a data class instead of global variables

I am trying to separate out experiment specific data from general evolver logic in custom_script.py
One issue is that there are many "global" variables that need to be updated in multiple locations. The new experiment_params.yaml should store all relevant settings.

Action items for frontend

  1. Document usage in readme.
  2. Update default config file handling. In theory, we should be able to prepopulate the fields not just with hard coded defaults but continue from a previous configuration file. This will be important if something crashes halfway through.
  3. Combine forms to avoid having multiple submit buttons. Use a horizontal rule to separate out the parts instead
  4. Add feature to store calibration file in the frontend.
  5. Consider abstracting away the front end so a single instance is run on the machine. This needs implementing file browser support which will allow the user to specify which experiment to display.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.