|
| 1 | +# Custom rule file formats |
| 2 | + |
| 3 | +Below are the specifications for custom reaction and matching rule files, as well as wave configuration file, used by RetroMol. These files are written in YAML format. Reaction and matching rule files are dumps of lists of rules, while the configuration file structures them into a workflow. |
| 4 | + |
| 5 | +## Wave configuration |
| 6 | + |
| 7 | +### Creating a wave_config.yml |
| 8 | + |
| 9 | +RetroMol processes molecules in waves: ordered stages that (1) apply selected reaction rules to split or transform the current “frontier” structures, and then (2) match the resulting fragments to motif classes. The behavior of each stage is controlled by a YAML file, wave_config.yml. |
| 10 | + |
| 11 | +If you don’t pass a config, RetroMol uses `retromol/data/default_wave_config.yml` (the same structure as the example below). You can point the CLI at a custom file with --wave-config (see `src/retromol/cli.py`) or pass it via the API (api.run_retromol(..., wave_configs=...)). |
| 12 | + |
| 13 | +### File structure |
| 14 | + |
| 15 | +A wave config is a YAML list, where each item is one wave. Waves run top-to-bottom. Each wave supports the keys below. |
| 16 | + |
| 17 | +Supported keys (per wave): |
| 18 | +- `wave_name` (`string`, required): Human-readable label stored on nodes produced in that wave (see `resolve_mol` in `src/retromol/apply.py`). |
| 19 | + |
| 20 | +- `reaction_groups` (`list[string]`, required): Names of reaction-rule groups to apply in this wave. These must correspond to groups defined in your reaction rules YAML (loaded via `rules.load_rules_from_files(...)`). Examples: preprocessing, linearization, NRP disassembly, PK disassembly, etc. |
| 21 | + |
| 22 | +- `matching_groups` (`list[string]`, optional): If provided, only matching rules whose groups intersect this list are considered when assigning node identities in this wave (see filtering in `apply.resolve_mol`). If omitted, all matching rules are eligible. Names correspond to groups defined in your matching rules YAML (loaded via `rules.load_rules_from_files(...)`). Examples: amino acid, polyketide building block, glycosylation, etc. |
| 23 | + |
| 24 | +- `only_leaf_nodes` (`bool`, optional; default: true): After applying the reaction rules in this wave, RetroMol selects which reaction-graph nodes to turn into motif graph nodes: |
| 25 | + * `true`: use leaf nodes created in the previous wave only (preferred; avoids duplicating intermediate steps). |
| 26 | + * `false`: use all nodes created in the previous wave. |
| 27 | + |
| 28 | + Note: If a “leafs only” wave produces no leaves (e.g., an uncontested rule returns itself), RetroMol falls back to all nodes for that wave. |
| 29 | + |
| 30 | +- `parse_identified_nodes` (`bool`, optional; default: `false`): |
| 31 | +Controls eligibility of nodes for re-parsing at the current deepest nesting level (see `find_eligible_nodes` in `src/retromol/api.py`): |
| 32 | + * `false`: skip nodes that already have an identity. |
| 33 | + * `true`: allow re-parsing nodes even if they already carry an identity. This is useful when one wave (e.g., linearization) changes structures in a way that reveals new tailoring motifs for the next wave. |
| 34 | + |
| 35 | + |
| 36 | +### Execution model (what happens under the hood) |
| 37 | + |
| 38 | +- Wave 1 operates on the input molecule to produce the initial motif graph (see `api.run_retromol` > first call to `apply.resolve_mol`). |
| 39 | + |
| 40 | +- Subsequent waves operate on the current frontier: nodes at the deepest nesting level whose graph is `None` (and, unless `parse_identified_nodes: true`, also have no identity). |
| 41 | + |
| 42 | +- In each wave: |
| 43 | + * Reaction rules are chosen from `reaction_groups`. |
| 44 | + * The reaction graph is computed; RetroMol selects leaf or all nodes according to `only_leaf_nodes`. |
| 45 | + * Selected nodes are matched to motifs using the (optionally filtered) `matching_groups`. |
| 46 | + * Each selected node becomes a node in the motif graph and is annotated with `wave_name`, `identity`, `props`, `smiles`, `smiles_no_tags`, and `tags`. |
| 47 | + * For nodes that should be further expanded in later waves, a nested graph is attached. |
| 48 | + |
| 49 | +Note: Stereochemistry matching is controlled separately (CLI `--matchstereochem` or API `match_stereochemistry`), not in the wave config. |
| 50 | + |
| 51 | +### Minimal example |
| 52 | + |
| 53 | +A minimal file needs just a name and at least one reaction group: |
| 54 | + |
| 55 | +```yaml |
| 56 | +- wave_name: preprocessing |
| 57 | + reaction_groups: |
| 58 | + - preprocessing |
| 59 | +``` |
| 60 | +
|
| 61 | +This will apply the preprocessing reaction rules and match against all matching rules. |
| 62 | +
|
| 63 | +## Reaction rules |
| 64 | +
|
| 65 | +The default reaction rules can be found at `retromol/data/default_reaction_rules.yml`. |
| 66 | + |
| 67 | +A minimal reaction rules file looks like: |
| 68 | + |
| 69 | +```yaml |
| 70 | +# reactions.yml |
| 71 | +- rid: reverse O-methylation |
| 72 | + smarts: "[O;D2:1][CH3:2]>>[O:1].[C:2]" |
| 73 | + groups: [preprocessing] |
| 74 | + props: {} # optional |
| 75 | +
|
| 76 | +- rid: break ester bond (intermolecular) |
| 77 | + smarts: "[C:1][C;!R:2](=[O:3])[O;!R:4][C:5]>>[C:1][C:2](=[O:3])[OH].[OH:4][C:5]" |
| 78 | + groups: [linearization] |
| 79 | +``` |
| 80 | + |
| 81 | +```yaml |
| 82 | +- rid: <string> # unique human-readable identifier |
| 83 | + smarts: <reaction SMARTS> # RDKit reaction SMARTS (LHS>>RHS) |
| 84 | + groups: [<string>, ...] # arbitrary grouping labels |
| 85 | + props: # optional metadata and global conditions |
| 86 | + conditions: |
| 87 | + # pre-conditions (whole molecule) |
| 88 | + reactant: |
| 89 | + requires_any: ["<SMARTS>", ...] |
| 90 | + requires_all: ["<SMARTS>", ...] |
| 91 | + forbids_any: ["<SMARTS>", ...] |
| 92 | + min_counts: {"<SMARTS>": <int>, ...} |
| 93 | + max_counts: {"<SMARTS>": <int>, ...} |
| 94 | + ring_count: {min: <int>, max: <int>} |
| 95 | + atom_count: {min: <int>, max: <int>} |
| 96 | + total_charge: {min: <int>, max: <int>} |
| 97 | + custom_props: {has_metal: <bool>, is_macrocycle: <bool>} |
| 98 | + # post-conditions (applied to each product) |
| 99 | + product: |
| 100 | + requires_any: ["<SMARTS>", ...] |
| 101 | + requires_all: ["<SMARTS>", ...] |
| 102 | + forbids_any: ["<SMARTS>", ...] |
| 103 | + min_counts: {"<SMARTS>": <int>, ...} |
| 104 | + max_counts: {"<SMARTS>": <int>, ...} |
| 105 | + ring_count: {min: <int>, max: <int>} |
| 106 | + atom_count: {min: <int>, max: <int>} |
| 107 | + total_charge: {min: <int>, max: <int>} |
| 108 | + custom_props: {has_metal: <bool>, is_macrocycle: <bool>} |
| 109 | +``` |
| 110 | + |
| 111 | +What each field means: |
| 112 | +* `rid`: A stable, unique identifier (used for logging/debugging). |
| 113 | +* `smarts`: Reaction SMARTS using RDKit’s format, including mapped atoms on both sides. Element identities and multiplicities for each map number must match (the loader enforces this). |
| 114 | +* `groups`: Tags used to select rule subsets (preprocessing, linearization, NRP disassembly, etc.). |
| 115 | +* `props.conditions.reactant`: “Global pre-filter” — the reaction only runs if the whole reactant satisfies these. |
| 116 | +* `props.conditions.product`: “Global post-filter” — each product must satisfy these (result dropped otherwise). |
| 117 | + |
| 118 | +Tip: Use local constraints inside the SMARTS for atom-level logic (e.g., “:1 must not be acyl”), and global conditions for whole-molecule predicates (e.g., “forbid nitro anywhere”). |
| 119 | + |
| 120 | +## Matching rules |
| 121 | + |
| 122 | +The default matching rules can be found at `retromol/data/default_matching_rules.yml`. |
| 123 | + |
| 124 | +A minimal matching rules file looks like: |
| 125 | + |
| 126 | +```yaml |
| 127 | +- rid: valine |
| 128 | + mol: "CC(C)C(N)C(=O)O" |
| 129 | + groups: [amino_acids] |
| 130 | + props: {} |
| 131 | +``` |
| 132 | + |
| 133 | +Matching uses exact topology equality (same atom/bond counts) plus substructure match. |
| 134 | + |
| 135 | +If you need stereochemistry matching, it’s supported by adding ste_mols in code (optional advanced usage). |
| 136 | + |
| 137 | +```yaml |
| 138 | +- rid: <string> |
| 139 | + mol: "<SMILES>" # exact structure to match (full match, not subgraph) |
| 140 | + groups: [<string>, ...] |
| 141 | + props: {} |
| 142 | +``` |
0 commit comments