search

KarrLab / wc_lang

Language for describing whole-cell models as reaction networks
MIT License
9 stars 3 forks source link

Reduce redundancy in representation of dFBA Reactions #129

Closed artgoldberg closed 4 years ago

artgoldberg commented 4 years ago

Including reverse links, these models and attributes define dFBA objectives now, where '(s)' indicates multiplicity:

Submodel.dfba_obj - DfbaObjective
Submodel.dfba_obj_reactions - DfbaObjReaction(s)

DfbaObjectiveExpression.reactions - Reaction(s)
DfbaObjectiveExpression.dfba_obj_reactions - DfbaObjReaction(s)
DfbaObjectiveExpression.dfba_obj - DfbaObjective

DfbaObjective.submodel - Submodel
DfbaObjective.expression - DfbaObjectiveExpression

DfbaObjSpecies.dfba_obj_reaction - DfbaObjReaction
DfbaObjSpecies.species - Species(s)

FluxBounds.reactions - Reaction(s)

Reaction.flux_bounds - FluxBounds
Reaction.dfba_obj_expression - DfbaObjectiveExpression

DfbaObjReaction.submodel - Submodel
DfbaObjReaction.dfba_obj_expression - DfbaObjectiveExpression
DfbaObjReaction.dfba_obj_species - DfbaObjSpecies(s)

Species.dfba_obj_species - DfbaObjSpecies(s)

I think it could be simplified by requiring that all reactions used in dFBA be written as DfbaObjReactions. This would require that reactions which both transform species and serve as the basis for objective(s) be duplicated. But it would substantially simplify the data model, and would be a net win. In addition, a Submodel can access its DfbaObjReaction(s) through its DfbaObjective (Submodel.dfba_obj.expression.dfba_obj_reactions) which eliminates a redundant attribute in Submodel. This would reduce the number of attribute definitions needed for the dFBA objectives from 8 to 6.

Submodel.dfba_obj - DfbaObjective

DfbaObjectiveExpression.dfba_obj_reactions - DfbaObjReaction(s)
DfbaObjectiveExpression.dfba_obj - DfbaObjective

DfbaObjective.submodel - Submodel
DfbaObjective.expression - DfbaObjectiveExpression

DfbaObjSpecies.dfba_obj_reaction - DfbaObjReaction
DfbaObjSpecies.species - Species(s)

FluxBounds.reactions - DfbaObjReaction(s)

DfbaObjReaction.dfba_obj_expression - DfbaObjectiveExpression
DfbaObjReaction.dfba_obj_species - DfbaObjSpecies(s)
DfbaObjReaction.flux_bounds - FluxBounds

Species.dfba_obj_species - DfbaObjSpecies(s)
jonrkarr commented 4 years ago

  1. Although DfbaObjReaction is largely semantically equivalent to Reaction, I want like to keep them as separate classes because I have structured the Excel presentation of these classes for different purposes

    • Reaction is intended for elementary reactions with integer stoichiometries and a small number of participants
    • DfbaObjReaction is intended for pseudo reactions with floating point stoichiometries and a large number of participants. For that reason, DfbaObjReaction can capture additional metadata and is displayed differently in Excel. This Excel layout is too cumbersome and too verbose for elementary reactions such as the exchange, transport, and chemical transformation reactions that constitute the great majority of reactions in FBA models (typically all but 1 reaction).

  2. I agree that it is awkward to have a fluxBounds property for non-FBA reactions. We could alleviate this by splitting Reaction into KineticReaction and DfbaReaction. Only the latter would have the flux bounds attribute. This would increase the number of classes by 1.

jonrkarr commented 4 years ago

Closing this issue because there has been no further discussion.