Reagent Loader

Category Paths

Follow one of these paths in the Orion user interface, to find the floe.

  • Role-based/Cheminformatician/Medicinal Chemistry Support

  • Role-based/Cheminformatician/Corporate Collection Support


This Floe processes an uploaded archive of reagent files for use in subsequent reaction enumerations.

General approach

  • create the reagent archive on your local machine for all the reagent files in a single top level directory.

  • upload the archive file to Orion and disable any processing of the file - the raw archive file is required for the reagent processing

Reagent Archive Files

Each reaction in the archive must have a unique reaction identifier, for example, rxnkey. Each of the reagent sets corresponding to the specific reaction of that key are named with a numeric id suffix, thus: rxnkey_1.smi, rxnkey_2.smi, …

Each reagent file is processed individually to ensure it meets the minimum requirements for enumeration to products, namely, each reagent structure in each reagent file must contain at least 1 attachment point site. If the reagent structures already contain the required OESMILESFlag_ExtBonds attachment point annotations for the reagents, no additional processing of the reagents are required, and the reagents can be used directly. In this case, no alchemy.txt or .umr files should be present in the archive.

If the reagent files contain specific atom types to annotate the reagent attachment points, the archive must contain an alchemy.txt file which indicates what atom types correspond to what numbered attachment points. If the alchemy.txt file is provided, every reagent structure will be processed using that information.

There is additional support for reagent clipping or manipulation. If a specific reagent has a corresponding .umr file in the archive, that reagent is assumed to need additional reagent processing by the provided OEUniMolecularRxn SMARTS specification. That is, for rxnkey_2.smi in the presence of a rxnkey_2.umr file, a OEUniMolecularRxn will be created from the .umr contents (1st line only) and each of the reagents in rxnkey_2.smi will be modified by the specified transformation. Only reagents that have a single transformation will be considered valid reagents, if more than one site is found for the transformation, that specific reagent structure will be skipped. Care should be taken to write the OEUniMolecularRxn transformation to generate invalid valence site(s) from any clipped or broken bonds for fragments that are to be removed in the transformation process. There is no inherent support for removing general/clipped structural fragments from an OEUniMolecularRxn transformation if bonds are broken, so identifying them with illegal valence site(s) is a temporary workaround for this limitation. If the input reagent itself has invalid valence site(s), or if no invalid valence site(s) are generated by the transformation, all but the largest fragment will be removed post-transformation to ensure no extra fragments are retained.

The stages of reagent archive validation are thus,

  • Collect all the unique reaction keys

  • Verify correct naming of reagents for each reaction key (at least 2 reagent files, at most 4 reagents, and reagent file numeric ids in consecutive order)

  • Find the (optional) specification for alchemy conversions (archive-specific)

  • Collect any .umr transformations (reagent-specific)

For all the reagent files that pass the reaction naming validations, loop over all reagents in each reagent file verifying,

  • a valid SMILES structure specification for the reagent

  • (optional) apply any .umr transformation specification to each reagent - requiring reagents to contain only a single transformation site - remove any generated fragments from the .umr transformation due to bond breaks.

  • (optional) perform alchemy conversion(s) if alchemy.txt is present

  • verify that at least one attachment site is present on the processed reagent

All the reagent files with valid names and all reagent structures therein that meet the reagent validations are exported to a reagent enumeration collection that can be enumerated to products.

Alchemy File Format

The optional alchemy.txt file should contain a single line of the following format,

  • sym1:attachpt1[,sym2:attachpt2][,sym3:attachpt3]

for example, Fe:1,Mo:2,W:3,Y:4 for iron, molybdenum, tungsten and yttrium attachment point specifications for R1-R4

Supported File Formats

The supported reagent structure formats are: .smi, .ism, .usm, .can.

The supported OEUniMolecularRxn SMARTS transformation extension is: .umr.

The supported archive formats are: .tar, .tar.gz, .tgz, .tar.xz, .txz, .tar.bz2, .tbz2, .zip. Generally the supported archive formats for any particular platform are those listed from shutil.get_unpack_formats().

Promoted Parameters

Title in user interface (promoted name)


Input Archive File (archive): Name of the non-ETL’d Orion file containing the reagents to be validated and prepared for enumerations, and loaded into a reagent collection

  • Required

  • Type: file_in


Sort Order (sort_order): Defines the ordering of the reactions in the reagent listing: name:reaction name, increasing/decreasing: total enumeration product counts

  • Required

  • Type: string

  • Default: name

  • Choices: [‘name’, ‘increasing’, ‘decreasing’]

Verbosity (verbosity): Sets the output logging verbosity

  • Type: string

  • Default: warning

  • Choices: [‘info’, ‘warning’, ‘error’, ‘debug’, ‘ddebug’]