Decide how to best handle parameter files and implement

[murrayrm]

In the current version of the code, parameter files are specified for each component. @zoltuz is concerned with "the way we handle parameters: all components have separate csv files. I think this is something we should discuss because in the MATLAB version things got quickly out of hands with many different csv files" (from biocircuits/txtlsim Slack channel).

Using this issue to track discussion (so that it is visible to others and searchable later).

[murrayrm]

William suggested (in Slack) that we just have a single parameter file for everything. That will work in the current implementation just by passing the same file name to all components when they are created.

One reason we may not want to do that is that you could have different parameter values available for the same component, as a way of keeping track of variants without creating whole new components. For example, rather than have a deGFP protein and a sfGFP protein, we could just have a GFP protein and then use different parameter files to keep track of the different maturation rates or other parameter differences.

Another issue is that right now there are lots of repeated parameter names. For example, all dimers will use a parameter Dimerization_Forward for the dimerization rate (which is what the dimerization mechanism looks for) and those can be different for different proteins.

I do agree, though, that requiring each component to have a separate component parameter file can become a mess. So maybe we allow you to send a list of parameter files when you create a component and some intelligent way of using those to overwrite default parameter values with more specialized ones?

Also: we should keep in mind that eventually we will want to do system ID and create parameter files. My thought was that we would do this at the component level, so that a component would have a write_parameter_file() function that could create a .csv file with the (identified) parameters specific to that component.

[WilliamIX]

I suggest we treat parameters the same way we treat mechanisms. A mixture has a default parameter file which will be used by all components and mechanisms unless the user says otherwise. Parameter files can be overwritten at the component level, in which case that components mechanisms will use the new parameter file as well (but default to the mixture's file if a parameter is missing). Similarly an individual mechanism can have a specific parameter file set. In short, parameters priority will be:

Custom Mechanism Parameters > Custom Component Parameters > Mixture Parameter (default)

[murrayrm]

Seems like parameter values need to go with components, not with mechanisms. What is an example of a mechanism that would have a parameter value that is not associate with a component within that mechanism?

Also, perhaps include some sample (user) code for what you want this to look like (along the lines of tests/parameter_test.py?

[WilliamIX]

Different mechanisms need different parameters. For instance, consider 2 transcriptional mechanisms:

1. basic mechanism:
   DNA+RNAP<-->DNA:RNAP --> DNA+RNAP+mRNA

2. sigma70 mechanism
   DNA+Sigma70 <--> DNA:Sigma70; DNA:Sigma70:RNAP <--> DNA:Sigma70:RNAP --> DNA+Sigma70+RNAP+mRNA

The binding constants of the promoter to RNAP be a Component Specific parameter. The binding constants of the sigma factor might be most easily abstracted as a a mechanism specific parameter. They could also be a Component parameter, but only if we made Sigma70 a component instead of an auxiliary species created by the mechanism. I think allowing for the flexibility to do implement this in both ways makes sense.

[murrayrm]

Should the sigma70 parameters be associated with the mechanism (transcription_sigma70) or the component (sigma70)? Seems to me that you would want them to go with the component?

Also, this brings up another point (not sure if it belongs in this issue): I suggest that you keep everything case insensitive so that Sigma70 and sigma70 are treated equally (since there are a lot of capitalization variables for things like tetR: 'tetR', 'TetR', 'tetr', etc.