feature/refactor: fermentationData indication of uptake / secretion

[edkerk]

trafficstars

Description of the new feature:

In fermentationData.txt (as in chemostatData.tsv) the fluxes are all positive, while the column names indicate whether something is uptake or secretion. In essence this is fine, it will probably suit most experiments, but it does make the code a bit inflexible. In particular related to the by-products, as they are always treated as secreted, but there are examples where it would be useful to allow by-products to be taken up:

Examples:

1. When making proteome-constrained models for different timepoints, one of the by-products from the early model might be taken up at a later time as minor carbon source (in addition to the same major carbon source).
2. When making proteome-constrained models with different nitrogen sources, it would be nice to be able to handle this as "by-product" with a negative flux.

Another way to deal with those examples would be to run generate_protModels multiple times, and inbetween runs swap different versions of changeMedia_batch.m, abs_proteomics.txt and fermentationData.txt files, unique for each of the special cases, but that seems like a suboptimal solution.

With some minor refactoring of DataConstrains in generate_protModels this behavior can quite easily be arranged. In addition, it would then make sense to always block the opposite exchange reaction (if uptake is allowed, block secretion, and vice-versa).

So please let me know your thoughts :). If this behavior is not preferred, then I can also keep a custom version of DataConstrains just for these special cases.

Important:

• This change would break backwards compatibility, as the fermentationData.txt file would have to be modified. Is there sufficient benefit to allow for that? There could be a sanity check on oxygen flux, if this value is not negative the user can be prompted whether they mean to constrain oxygen flux to consumption.
• For consistency, should chemostatData.tsv then also follow this reasoning? This would require a little additional refactoring.

I hereby confirm that I have:

• [x] Done this analysis in the master branch of the repository
• [x] Checked that a similar issue does not exist already