murrayrm
commented
7 years ago Commented by murrayrm on 2014-07-03 06:04 UTC Totally agree we need to sort this out. We should continue to allow for the possibility of a promoter configuration file that is tied to a specific protein, though. This will help us when we are dealing with situations where promoter strength depends on the downstream sequence. Perhaps an easy way to do this is to name such configuration files as the baseline promoter followed by an underscore then the specific protein.
With this convention, a DNA strand might look like "DNA pBAD_deGFP--UTR1--deGFP" or even "DNA pBAD_UTR1_deGFP--UTR1--deGFP" if the promoter strength depended on the UTR sequence as well.
Reported by tiberium87 on 2014-07-03 05:54 UTC right now there is a fair bit of confusion in the naming and calling of config files:
the same config file is used for both a protein and promoter in a protein-promoter pair. but this config file is sometimes named by the promoter name and sometimes by the protein's name. Even worse, sometimes there are two config files for the same protein-promoter pair, one named by the protein name and the other named by the promoter, and it is pretty arbitrary which one is called...
Just need to go over the components folder and remove all these inconsistencies and adopt the following simple convention:
Instead of one config file containing both protein and promoter parameters, each protein and promoter has its own config file. The advantage of this is that when we design a combinatorial promoter, its corresponding config file does NOT set the parameters for the proteins as well. Those parameters are set by the protein's own config file. (so for example, tetR dimerization rate should NOT depend on whether tetR is going to repress pBAD_tetO pr ptet.