Newcastle University Drylab/10 June 2008

From 2008.igem.org

Bugbuster-logo-red.png
Ncl uni logo.jpg


Newcastle University

GOLD MEDAL WINNER 2008

Home Team Original Aims Software Modelling Proof of Concept Brick Wet Lab Conclusions


Home >> Dry Lab >> Dry Lab Journal

May
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
June
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
July
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
August
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

10 June 2008

Mark

Spent some time with Matthew in the morning going through static architectures and communications with Morgan's workbench. This led to completion of an inputs and a steering diagram that can be used to help code up interfaces.

Then spent some time researching the lac operon so that it can be used for model parts to code up an evolutionary algorithm. I then planned how I would implement this in an EA. Basically there are four states that the lac operon funtions under;

1. High expression - Low glucose, and lactose available

2. No expression - High glucose, and lactose unavailable

3. No expression - Low glucose, and lactose unavailable

4. Low expression - Low glucose, and lactose available

I then designed a cellML model for the lac operon system which can fit into my EA. The hidden layer will be a single promoter that can be affected by a number of proteins leading to the various levels of transcription present on the lac operon. The cellML model incorporates various for substance amount and time along with a number of variables for the different proteins around the promoter start site. I then started to do some maths to code up different scenarios (represented as components) that would enable the model to function with four different outcomes. Ultimately these will be mutated in the EA.


Megan

Went through collections and basic java with Matt. Now have some information set out in collections(Arrays.asLists) instead of Arrays. Wrote out the user stories in terms of what the work bench would request, as set out by Morgan, and what the EA would require input and output, and what the the constraints repository would need. Comitted this to svn.


Morgan

Moved my Todos from above to WB Todo, and clarified my immediate objectives to myself. Didn't bring my laptop today, so will finish doing other things.

Finished writing user stories.

Tackling my todos from the top now. Moved everything over to deal with ids rather than the placeholder strings I've been using.

Parts Repository

  • The program must display a list of all available parts. The program requests a hierarchical list of all part names, part types, and their part ids from the Parts Repository (PR). Upon receiving the list, the program sorts the parts into different categories based on the part type, chooses a display icon for each type, and presents the list of part names with their part type icons to the user.
  • The user wishes to change the type of chassis. The program retrieves a list of all chassis names and chassis ids from the PR and presents it to the user.
  • The program must display a list of all types of parts. It requests a list of all part types and their part type ids from the PR. Then it displays the list of part names to the user.
  • The program must display all of the information about a single part. It gives the part id to the PR and receives a full description of the part in return. It then displays the part information to the user.
  • The program must save a CellML model of a part. It gives the part id to the PR and receives a segment of CellML in return. It then saves the CellML to file.

Constraints Repository

  • The program must show all possible interactions to a particular part. It passes the part id to the Constraints Repository and receives a list of all possible interaction ids in return. It then retrieves the details of each interaction with the interaction id. It then shows the possible interactions to the user.

Evolutionary Algorithm

  • The user finally wants to evolve her model //in silico//. The program collects the starting model, composed of a series of part ids, and the proposed behaviour in the form of a truth table, and gives it to the Evolutionary Algorithm (EA) for evolution. The program shows a “busy working” screen while the Evolutionary Algorithm computes the best model. When the EA finishes, the program receives the proposed best model(s) and displays them, along with their behaviour, to the user.


Nina

Strains that we will be using:

Streptocoocus pneumoniae - R6

Staphylococcus aureus- 8325

Listeria monocytogene - 10403S

Bacillus aureus - ATCC 14579

Had a little play with the hibernate tutorial...bit stuck. Group decides Megan and Nina are better off extracting information out of their databases into Java using JDBC instead.

http://www.hibernate.org/hib_docs/reference/en/html/index.html