RXNFP inputs and parameters

You provide one or more reaction SMILES in reactants>>products form. Two parameters shape the result: fingerprint_type, which decides what a fingerprint is and therefore what similarity even means, and min_similarity, which decides how much of the tail you see. Raise min_similarity for close matches only, lower it to widen the set.

Reaction SMILES format

Input reactions in the standard SMILES format:

reactants>>products

Multiple reactants are separated by . (dot).

Examples

Fingerprinting parameters (rxnfp / rxnfp_fingerprint)

Choosing a fingerprint type

The two types are different objects, not two settings of one knob, and this is the choice that decides what everything downstream can do.

⛔ Scores from the two types are not comparable. rxnfp is scored by cosine distance on the embeddings; drfp by Tanimoto on the bit vector. A 0.8 under one does not mean what a 0.8 under the other means, so do not mix them in one ranking or compare a stored score against a run that used the other type.

For nearest-neighbour class retrieval the source reports rxnfp as the stronger of the two — USPTO 1k TPL 5-NN accuracy 0.989 against 0.917 for drfp. Reach for drfp when you want a model-free, reproducible bit vector rather than the best retrieval.

Similarity search parameters (rxnfp_similarity)

The query itself is a single reaction — reaction_smiles here is one string, not an array, unlike the fingerprinting input.

By default the query is looked up against a pre-built reference index drawn from ORDerly reaction data. Pass reference_reactions to search your own set instead: that is how you compare a query against a specific series — a project's own reaction history, or the steps of one retrosynthetic route — rather than against the whole index. It replaces the index for that call; it is not searched in addition to it.

Batch fingerprinting

{
  "reaction_smiles": [
    "CC(=O)O.OCC>>CC(=O)OCC",
    "CC(=O)Cl.c1ccccc1N>>CC(=O)Nc1ccccc1",
    "c1ccc(B(O)O)cc1.c1ccc(Br)cc1>>c1ccc(-c2ccccc2)cc1"
  ]
}

Input validation rules

• Reaction SMILES must contain the >> separator.
• Both reactant and product sides must be valid SMILES.
• Very long reaction SMILES are truncated at the tokenizer's limit.
• A malformed reaction in a batch is reported per-item (is_valid: false, with an error message) — it does not fail the whole batch.

Read next