name: bio-systems-biology-community-metabolic-modeling description: Builds and simulates multi-species metabolic community models from member genome-scale models, using MICOM for abundance-weighted steady-state community FBA and cooperative tradeoff, SMETANA for cross-feeding and competition scoring, and SteadyCom/COMETS for common-growth-rate and dynamic simulation. Use when modeling a microbiome or co-culture, predicting cross-feeding and competition, abundance-weighting members from metagenomics, choosing steady-state vs dynamic community modeling, avoiding the compartment-pooling artifact, or judging how member-model quality and namespace propagate into community predictions. origin: openai4s category: bioskills/systems-biology metadata: tool_type: python primary_tool: micom third_party: name: GPTomics/bioSkills repository: https://github.com/GPTomics/bioSkills commit: d91ed3d563019e649dc854c56ccd62551359488a license: MIT
Reference examples tested with: MICOM 0.33+, COBRApy 0.29+, Python 3.10+ (SMETANA and COMETS are separate installs)
Before using code patterns, verify installed versions match. If versions differ:
- Python: pip show <package> then help(module.function) to check signatures
If code throws ImportError, AttributeError, or TypeError, introspect the installed package and adapt the example to match the actual API rather than retrying.
Note: community FBA needs a QP solver for MICOM's cooperative tradeoff (HiGHS/CPLEX/Gurobi). Member models must share a namespace (BiGG vs ModelSEED), reconciled via MetaNetX before combining. SMETANA is a separate CLI (github.com/cdanielmachado/smetana); COMETS uses the cometspy toolbox.
"Model the metabolism of my microbial community" -> Combine member genome-scale models into a community, then predict community growth, individual growth rates, and metabolite exchange (cross-feeding and competition) under a shared medium.
- Python: micom.Community(taxonomy).cooperative_tradeoff() (steady-state, abundance-weighted); SMETANA (cross-feeding scores); COMETS (dynamic)
Two things dominate whether a community prediction means anything:
A further modeling fork: steady-state community FBA (SteadyCom, MICOM) assumes a stable coexistence with a common community growth rate, while dynamic simulation (COMETS, BacArena) resolves the time course and spatial structure but is expensive and parameter-hungry. Neither predicts the other's regime.
| Goal | Tool | Approach / trade-off |
|---|---|---|
| Metagenome-scale gut community, abundance-weighted, steady state | MICOM (Python) | community FBA with cooperative tradeoff (community vs individual growth); scales to many taxa from abundances |
| Cross-feeding / competition SCORES between members | SMETANA (CLI) | MRO (resource overlap = competition), MIP (interaction potential = cooperation), per-metabolite scores; pairs with CarveMe |
| Coexistence at a common community growth rate | SteadyCom | enforces one shared growth rate; elegant steady-state coexistence model |
| Time course / spatial dynamics, diffusion | COMETS / BacArena | dynamic (COMETS) or individual-based spatial (BacArena) FBA; realistic but expensive/parameter-hungry |
Do not model a community as one pooled "bag" model; use a tool that keeps members compartmentalized and connects them through a shared extracellular medium.
Goal: Combine member models (weighted by their metagenomic abundance) and predict community and per-member growth under a medium.
Approach: Assemble a taxonomy table (one row per taxon with an id, a model file, and an abundance), build the Community (which compartmentalizes members correctly), and solve with cooperative tradeoff - which finds a community growth optimum while spreading growth across members rather than letting one taxon dominate. Reserve the fraction argument to trade community optimum against individual growth.
from micom import Community
from micom.data import test_taxonomy
# taxonomy: columns id, file (per-taxon SBML), and abundance (from metagenomics). test_taxonomy()
# ships a ready E. coli example community.
taxonomy = test_taxonomy()
community = Community(taxonomy) # builds the compartmentalized multi-species model
solution = community.cooperative_tradeoff(fraction=1.0) # QP; needs HiGHS/CPLEX/Gurobi
print('community growth rate:', solution.growth_rate)
print(solution.members[['growth_rate']]) # per-taxon growth; NaN row is the shared medium
# SMETANA (separate install) scores interactions between member models built by CarveMe:
# pip install smetana # then:
# smetana model1.xml model2.xml -o community --flavor bigg
# Outputs: MRO (metabolic resource overlap = competition for shared nutrients),
# MIP (metabolic interaction potential = potential cooperation/cross-feeding),
# and per-metabolite SMETANA scores (who feeds whom). A high MIP with low MRO
# suggests cooperative cross-feeding; high MRO suggests competition.
# For the time course rather than a steady state, COMETS (cometspy) runs dynamic FBA on a lattice
# with metabolite diffusion. Use when the QUESTION is temporal (succession, diauxie, spatial
# structure), not a coexistence steady state. It is far more expensive and needs kinetic parameters
# (uptake Vmax/Km, initial biomass, diffusion constants) that a steady-state model does not.
| Symptom | Cause | Fix |
|---|---|---|
| Cross-feeding predicted that needs no secretion | compartment pooling (single shared internal pool) | use MICOM/SteadyCom (compartmentalized); connect members only via a shared extracellular medium |
| Members will not exchange metabolites | namespace mismatch (BiGG vs ModelSEED IDs) | reconcile member models via MetaNetX before combining |
| Community growth nonsensical | a member model is broken (bad biomass, energy cycle) | curate each member first; a bad member poisons the community |
cooperative_tradeoff errors on solver |
it is a QP and GLPK cannot solve it | use HiGHS (bundled), CPLEX, or Gurobi |
| One taxon takes all the growth | plain community-max FBA has alternate optima | use cooperative tradeoff (spreads growth) and set abundances from data |
| Dynamic run is impossibly slow | COMETS/BacArena are expensive and parameter-hungry | use a steady-state method unless the question is genuinely temporal/spatial |