Database Structure¶

Overview¶

NutMEG simulations can become expensive, particularly if you’re performing calculations over a wide range of parameters or working over long timescales. To prevent you having to rerun simulations NutMEG saves a copy of the state of the ecosystem every 100 steps up until the final step by default to a named SQL database. This is by default named ‘NutMEG_db’ and placed in the working directory, but can be changed by specifying dbpath, a common keyword argument for objects in NutMEG, or changing std_dbpath in NutMEG.util.NutMEGparams.py.

Three key identifiers are used throughout NutMEG’s database: SimID, OrgID, and LocID. SimID is the primary key of the Summary table, and each one links to a table with the name 'FullResults_Sim_'+SimID.

LocID identifies reactor-like objects and is a primary key of the Reactor table. Similarly OrgID identifies base_organism-like objects and is a primary key of the organism table. Of course, organisms and reactors can take different forms and have different attributes depending on the level of complexity you want to achieve with your simulations and whether you’re using saved_systems or saved_organisms. Instance variables of reactors and organisms are store in the NutMEG database so as to tell if a simulation has ben performed before or not. Each instance of a reactor-like or base_organism-like object has a name attribute. This variable tells NutMEG which table the objects parameters should be saved to, handy if you’ve included your own output helper class. It also assigns the prefix of the relevant OrgID or LocID.

Tables¶

Below is the structure of some of the tables, populated with some example organisms, reactors, and simulations.

Summary Table: static results for each simulation

FullResults_Sim_1_010120 Table:

Organism table. Match up organisms to metabolisms so we know which table to pull up for them

Methanogen Table:

Reactor table. Match up locales to named systems so we know which table to pull up for them

Enceladus Table:

Extracting data for analysis¶

Generally you can extract any simulation parameters using the static methods found in ecosystem_dbhelper . The method extract_param_db_Sim() will extract parameters for the given SimID pertaining to the given orgID, if specified, and return them. These could be entries in Summary (e.g. PeakGR for the maximum growth rate in the simulation), or entries in the FullResults_Sim_ table (e.g. no_alive for the active current population throughout the simulation).

You can’t extract specific parameters from the organism and reactor relevant tables, but you can initialise an identical object using the r_from_db() or bo_from_db() class methods — think of this as similar to pickling.