Postprocessing

5) Postprocessing

After a KiMecO run completes, postprocessing uses a user specified ensemble (ex: [G0001, GT-1]) of models to calculate their rate coefficients at new T,P conditions. This is useful for extrapolating mechanism performance beyond the original optimization temperatures and pressures, or analyzing specific ensembles.

Running postprocessing

Postprocessing is invoked after the main optimization run finishes. Use the CLI command:

kmopp input.json

This reads the same JSON input file (with pp_* keywords added) and the existing run's workdir, then executes the postprocessing workflow. The command loads all databases and GOAT file from the original run automatically.

Required keywords

Keyword	Default value	Description
pp_experiments	[]	List of dicts — postprocessing conditions to simulate. Same schema as experiments but without data_file/error_file; each entry adds its own times and species. See below.
pp_ensembles	["G0001", "GT-1"]	List of strings — tags of ensembles to process (see token syntax below).

The MESS extrapolation grid is derived automatically from the unique temperatures and pressures of pp_experiments; it is not specified directly. Rate coefficients already present in a model's existing KIN table are reused, so only the missing (P, T) conditions are computed.

When postprocessing starts, the log prints the metadata of each pp_experiment (type, temperature, pressure, species, composition).

Specifying postprocessing experiments (pp_experiments)

Each entry mirrors an experiments entry but is only simulated, never scored, so it has no data_file/error_file. Instead it must provide:

• times — list of floats (seconds, ascending): the solver/output time grid.
• species — list of strings: species recorded in the output profiles.

Required keys per entry: temp (K), pres, cantera_tpl, times, species, and exactly one of initial_ratio / initial_concentration. Optional: pres_unit (defaults to the global pres_unit). The composition syntax — including marking one species as "base" to auto-fill the remainder — is identical to experiments.

The unique temperatures/pressures across all pp_experiments define the MESS rate-coefficient grid used for extrapolation. Identical cantera_tpl files are de-duplicated, so each unique template becomes a single simulation array task.

Example entry:

{
  "temp": 500,
  "pres": 1.0,
  "pres_unit": "bar",
  "cantera_tpl": "templates/reactor_template.py",
  "initial_ratio": {"CH4": 0.01, "O2": 0.21, "N2": "base"},
  "times": [0.0, 0.01, 0.02, 0.03],
  "species": ["CH4", "O2", "HO2", "CH3"]
}

Ensemble tokens (pp_ensembles)

Each token specifies which models to extrapolate:

Token syntax	Example	Meaning
G#### (4 digits)	G0005	All models from a specific GA generation (e.g., generation 5).
GT#### or GT-#	GT0010, GT-1	GOAT (elite) ensemble for a generation. GT-1 → final/elite list.
NM#### or NM-#	NM0002, NM-1	Best model from Nelder-Mead optimization for a specific NM generation.
NMS	NMS	Nelder-Mead Swarm — all final simplex members from the last NM run.
NMSG####	NMSG0003	All Nelder-Mead Swarm candidates from a specific GA generation (advanced).

TIP: Ensembles are stored in the SOP_DB as tables named G0001, NM0001, etc. They must exist in your database for the postprocessing command to succeed. To get a GOAT ensemble, one can construct a GOAT object from the goats.txt file generated by the main run.

Example postprocessing input

{
  "mess_inputs": ["mess_input.inp"],
  "ct_yaml": "mechanism.yaml",
  "experiments": [...],
  "pp_experiments": [
    {
      "temp": 500,
      "pres": 1.0,
      "pres_unit": "bar",
      "cantera_tpl": "templates/reactor_template.py",
      "initial_ratio": {"CH4": 0.01, "O2": 0.21},
      "times": [0.00, 0.01, 0.02, 0.03],
      "species": ["CH4", "O2", "HO2", "CH3"]
    },
    {
      "temp": 600,
      "pres": 10.0,
      "pres_unit": "bar",
      "cantera_tpl": "templates/reactor_template.py",
      "initial_ratio": {"CH4": 0.01, "O2": 0.21},
      "times": [0.00, 0.01, 0.02, 0.03],
      "species": ["CH4", "O2", "HO2", "CH3"]
    }
  ],
  "pp_ensembles": ["G0001", "GT-1", "NM0005"]
}

Output and results

Postprocessing does not create separate databases. Extrapolated results are written back into the primary run databases (KMO_DB_KIN.db and KMO_DB_SIM.db), into the same per-generation tables where the models were originally created:

1. Rate coefficients — written into KMO_DB_KIN.db, in the table named after the originating optimizer prefix and generation ({prefix}{gen:04d}, e.g. G0003, NM0002, NMSG0001).

   • Already-computed k(T, P) are reused: MESS is only re-run for the (P, T) conditions in pp_experiments that are not already present in the model's KIN table; missing conditions are computed and appended.
   • The GT token (GOATs ensemble) resolves to the originating optimizer's prefix (e.g. G for the genetic algorithm), so GT and the old X prefix never appear as table names.

2. Simulation profiles — appended into the existing KMO_DB_SIM.db tables for the same generation.

   • The postprocessing simulation is always run and saved because the initial composition differs from the original run.
   • Profiles are stored with banded experiment ids (offset past the original run's experiments), so the original run's simulation results are never overwritten.

Forward-only change: earlier versions wrote separate PP_DB_KIN.db / PP_DB_SIM.db files with X-prefixed tables. Those files are no longer created, and old X-prefixed tables from prior runs are not migrated.

Where files are saved: All results are written to the run's KMO_Project/ (or your configured project_name) directory, alongside the original databases. Intermediate job scripts (SLURM or local) and scratch files are created there.

Workflow overview

1. Validate pp settings — check that all P/T/composition/time combinations are consistent.
2. Open existing run databases — SOP_DB, KIN_DB, SIM_DB from the original run.
3. Load GOAT file — read workdir/goats.txt to reconstruct elite ensembles.
4. Loop over pp_ensembles:
   • Resolve the token to its originating optimizer prefix and generation table.
   • Load models (SOP parameters) from the SOP_DB table matching the token.
   • Submit rate-coefficient jobs (MESS) only for (P, T) conditions missing from the model's KIN table, then append them into that table.
   • Submit Cantera simulation jobs to run reactor dynamics and append the profiles (with banded experiment ids) into the SIM table.
5. Finalize — no re-scoring; results are persisted as-is.