Class Structure for DNA and DNA Assembly

[WilliamIX]

Currently Component is the superclass of DNA and DNAassembly. DNA is then the superclass for each part-type (promoter, UTR, CDS, etc). These part types are then subclassed to specific kinds, eg "RepressablePromoter" which in turn are subclassed to specific parts eg "PTETPromoter". I suggest simplifying this scheme as follows:

Component is the superclass of DNA which is the superclass of DNAassembly (and other DNA objects).

Component is the superclass for a SubComponent class which is then the superclass for each part of an assembly. Parts should not be DNA pieces because in the event of degradation, the whole assembly should be degraded, not just one piece of it. Additionally, SubComponent will lose some of the functionality of component in order to help keep loops and other issues from occurring during compilation. Basically, as a design rule I think it is preferable not to have nested components or nested mechanisms.

Finally, I think specific kinds of Parts, such as PTETpromoter should not be their own classes. PTET is a repressible promoter with a specific name and specific parameters that can be looked up in a data file. This has a number of advantages including minimizing the total number of classes, not using eval statements to convert strings into class names (a great way to get errors), and recognizing that classes store functionality while parameter values store specifics like rates.

[murrayrm]

If I understand the above description, you are suggesting:

Component()
    DNA(Component)
        DNAassembly(DNA) - this would have a list of DNAparts (prom, utr5, cds, etc)
        DNApart(DNA)

prom_ptet = instance of DNApart

If that is correct, seems fine. I agree that prom_ptet doesn't need to be a class; it can just be an instance of a DNApart with specific properties.

[WilliamIX]

Component >> DNA >> DNAassembly
Component >> SubComponent >> Promoter / UTR / CDS/ etc.

prom_ptet = instance of DNApart.
ptet-bcd2-GFP = instance of DNAassembly which contains DNAparts.

In doing this, the way config files are loaded breaks. This seems to have something to do with different classes having/missing different attributes (or having those attributes with different names, for instance DNAassembly has no name attribute, but it does have an assemblyname attribute).

[murrayrm]

Seems reasonable.

Which of the objects above should have a config file? Seems like an assembly should not need a config file, but should inherit parameters from its subcomponents (so that you don't have a proliferation of config files for different combinations of components).

[WilliamIX]

Any Component or Mechanism could have its own config file if the user so specifies. Otherwise a default config file (passed into mixture) will be used. A config CSV will then have three columns: name, parameter, and value. Name refers to the name of the component or mechanism that this parameter pertains to (eg prom_ptet). Parameter refers to the name of the parameter (eg k_bind, k_unbind), and the value will be a float. I like this strategy because it allows for all parameters to be in one config file if we want, or for separate config files for separate components / systems / modules etc for maximum flexibility.

[murrayrm]

For the config files, I would suggest:

• Add an (optional) comment field that can be used to document the source of the parameter value. You'll see this in the current CSV files and I think it is a good format.

• Allow formulas in the value column. This let's you put in things like formulas for converting from minutes to hours, logs of division rates, etc. Very handy (also available in the current CSV format).

• Think about allowing for component files from the MATLAB version of txtlsim to be used rather than having to convert everything to a new format (we have 30+ CSV files for existing components and it might be useful to be able to reuse them). The current code in parameter.py supports the current file format => the code to handle it is already there.

• Think about how you want to use the "name" column. You don't necessarily want to have to have a user write a unique configuration file for every component modification they make. Eg, if you make a fusion protein tetR-sfGFP, you would like to be able to grab existing tetR and sfGFP parameters, at least as a starting point.

On possibility on the last point would be to allow users to pass a component name to be used for the purposes of matching parameter values in config files. Could even by a regular expression, so that you could say things like tetR|.*GFP for my previous example.