# IGEM:IMPERIAL/2007/Dry Lab/Log

### From OpenWetWare

--Anthony Lazzaro 15:23, 3 September 2007 (EDT) Welcome to the Dry Lab Log ! Here you can see what work we've been doing in Modeling & Data Analysis in a Day to Day format.

## Contents |

## Week 9

### Monday 3rd September

We have recieved some data from the Testing team and need to do the following work on it for tomorrow

$$$$ Major Problems with Excel Sheets & staggering need to have a chat to lab team in morning not much work done tonight ! $$$$$

Data to be analysed:

1.Deg GFP @ 37 Degrees

- need to normalise with respect to control
- need to extract decay coeficient

2.Deg GFP @ 20

- needs more data
- need to nomalise
- need to extract decay coeficient

3.Plux 25 Degrees

- Normalise Data wrt control
- Lag time
- Rate of GFP synthesis
- Steady State value given initial concentration

4.Ptet 20 degrees

- Turning on of Promoter
- Normalise wrt to control to get rid of increase in day 2

5.PTET @ 37 Degrees

- Get Steady State Value / Maximum Value
- Use Deg from 1. to determine K

6.Calibration cuve

- Need more data not very useful at the moment

### Tuesday 4th September

- Spoke with testing team and have decided have come up with a template for importing data from notepad to excel

- Spoke with testing team about wierd results and they are currently looking into it

- Wiki design needs some work: needs to have a graphic language and make it more visual

- Started Data Analysis today :
**Degradation**: We focused mostly on this today and have done some simple log based calculations do determine delta- Deg 37: Deg doesn't need overlap we will treat each part, day 1 staggered & day 2, as seperate. Major concern is that 1st part of the data actually goes up, we have cut this from our data when analysing (testing team will find out why this happens)
- Deg 20

- PTET 37 : Wierd Results - staggered data is lower than 1st - many theories
- PTET 20 : Same as above
- Plux 25: The initial data for this is very good but it is difficult to analyse
- We have noted that 50nM should be closer to 100nM than 10nM. A possible explanation for this is cooperativity, the threshold for this could be between 50-100nM: looking at the F2620 characterisation we can see that the threshold occours at 10-100nM.
- We think we should proceed by looking at the 1-10nM region more closely.
- In terms of analysis we will leave this data for a while as it will be the most difficult to analyse

### Wednesday 5th September

We have improved on log method in excel by trying out curve fitting methods using Least Squares approach implemented in matlab.

We have 3 curve fitting methods 2 using functions in matlab libraries and one built from scratch.

First Builds of all 3 show promise 2 return values in line with our log based calclations for Deg GFP @ 27 Degrees

### Thursday 6th September

**1.Wiki**

- We will work on our portal page today
- We will look into creating a data analysis page to store all of our work
- Start uploading code onto
*software shack*page, including brief descriptions of each specimen of code. Think of ways to make the page more interactive and, again, user-friendly

**2.Curve Fitting**

M suggested improvements on our Curve Fitting Codes and we are trying to Implement them

- J
- Try to implement weighting on the proximity of points to the fitted line: i.e. weight given to each data point depends on how far the point is from the fitted line

Our algorithm currently employs the *linear least squares* fitting method, which is quite sensitive to the quality of data gathered. The model currently assumes that the data conforms to constant variance. If this, unfortunately, is not the case, then our curve-fitting may be subject to a great extent by the lack of integrity in the data. To improve the fit, the *weighted* least squares method should be employed where an additional scale factor (the weight) is included in the fitting process.

Weighted least squares regression minimizes the error estimate,
where *w*_{i} represents the weighting. The weighting is a measure of how each data point affects the final (best_coeffs) parameter estimates. Naturally, a high-quality data point influences the fit more than one of low-quality.

- Make the curve-fitting programs more robust by possibly improving on the error-minimization code
- The curve-fitting program created today employed
*fminsearch*. A browse through the mathworks database suggested that*lsqnonlin*is a more robust solution - Robust, also in the manner in which to select the best possible start coefficents for the least squares routine (in order to cycle through to the most-appropriately fitting coefficents)
- Try to make the code more user-friendly by allowing the user to interact/input
- Think of the "envelope" which displays the range of input conditions for the curve-fitting program
- Make the display more graphical/visual

- B
- A
- Curve fitting for promoter activation
- Implement curve-fitting on the promoter data - determine which curve best fits model - what is the transfer function?
- Investigate interpolation methods for determining the nature of promoter activity

**3.Modeling Research**

- V has advised that the results generated for PTET @ 20/37 degrees may in fact be accurate and mabye our models are wrong ! We are looking into this today

**4.Normalisation**

- M has given us a better normalisation method and we are tyring to implement it into our models / Analyses

### Friday 7th September

**1.Wiki**

- Software Shack Design

**2.Improve Curve Fitting Program**

- Implement the changes M suggested - J tried to implement Weighting but had some issues with dimension errors/input arguments !?

**3. GUI**

Get a GUI on desktop : use C++

- I'll look into this over WKnd

Get a GUI on the web use IX and PHP

## Week 10

### Monday 10th September

1. Meet dude from Paris over wkend, cool guys - got some useful ideas to improve our iGEM

2. Purified luxR is coming in B and I worked out how much LuxR to add for construct 2 tests

**Matthieu Writes:**
Do not get too excited over the GUI guys
Let's get something that works and that is user-friendly and modular (so other teams can use/improve what you have done)
This is not a commercial software package that we try to develop!!
It is still a research project

### Tuesday 11th September

Not Much happened today:

1.Worked on Graphic Design of whole wiki

2.M said not to worry about GUI but rather get code in a reuseable format in modules

### Wednesday 12th September

Getting sick of not having Dry Lab Wiki done today I'm going to finish a complete first version