Ed's Big Plans

I met with Andre today — we spent most of the time discussing idly about programming languages.

Before that, he disclosed that many in the modeling team were building their own independent components of the Recombinatron project that were perfectly isolated from one another.

Most of the effort however was used to model the problem so that each of us has a good working idea of what we need to consider, what could be tough and what could be easy.

I recommeded to everyone that we all share our little bubble projects so we can critique what techniques and approaches we like the best. Apparently there was a meeting after I left between Andre and everyone else wherein a poll was taken with respect to what programming language to use and what versionning system to use.

I’m looking forward to seeing everyone else’s code snippets, the language and cvs chosen– as well as what API we’ll bang out and delegate to each person on the team.

My prototype of the project (incomplete).

I might put notes up in my wiki for this item, time depending.

In a meeting with iGemmers @ Waterloo today– specifically the Modeling team headed by Andre and supplemented by core members Sheena and John– a discussion was held on this year’s modeling project. We’re currently interested in creating a solver that will yield an arrangement of attX sites on a chasis bacterial host chromosome that can accomodate several rounds of deterministic recombination.

Plainly, we need to write software that will create a solution that is a sequence of DNA– this DNA is arranged such that specific sites that can be operated on by the enzyme integrase is sequenced so that it can accept several loops of artificial DNA to recombine with. In this design, we’re interested in a sequence for the host chasis, a sequence for the artificial loops and another loop for integrase to be produced at some arbitrary tonic level inside the cell.

The first step is to mathmatically formalize the problem– and along with it, some working particles of software that successfully model the problem space. The solver is a yet more abstract piece of software that will use these particles in its solution. This is similar to designing the notion of integers and arithmetic operators prior to using those components to solve algebra.

This description is very coarse– I’ll refine it in a later post after I’ve had some time to analyze the problem constraints and what software particles are important to set down on paper.