CMF-CW is a web application composed of Chemical Match Finder (CMF), an in-house cheminformatics application, and its integrated database of lists of chemicals controlled under international chemical weapons disarmament and nonproliferation frameworks (CW-control lists). Read the sections below to learn more about how CMF-CW works.
- General Description
- Handling Exact and Markush-type Regulatory Entries
- Converting Search Terms into Structures
- Generating Molecular Variants
- Evaluating Query Structures Against Exact and Markush Entries
- Learn More and Launch CMF-CW
General Description
The CMF-CW frontend, written in JavaScript and HTML, provides the user interface for the CMF application, where the user enters the search term (or a search file) and selects the search settings. It sends the search request to the backend and, once the backend has completed the search process, assembles and displays the report in HTML format.
The CMF-CW backend comprises the CMF cheminformatics engine and its integrated database of CW-control lists. Crucially, both components of the backend can handle databases that include entries that identify individual chemicals, represented as exact structures, as well as entries that define chemical families characterized by shared cores and a range of allowed variable chemical groups, represented as Markush structures. This feature is essential for CMF-CW, as some of the CW-control lists featured in its integrated database — namely the Schedules of the Chemical Weapons Convention (CWC) and the Wassenaar Arrangement Munitions List 7 (ML7) — include not only individual chemicals but also Markush-type chemical families.
The CW-control lists database is composed of CSV files (one per list) and Python scripts (one for each Markush-type entry). For each entry, the CSV file contains (i) a SMILES field that defines the exact structure of individually listed chemicals and the invariable core structure of Markush-type entries and (ii) a metadata field containing the names and family definitions explicitly listed in the CW-control lists, as well as certain SMILES strings that cannot be converted into structures. For each Markush-type entry, an entry-specific Python script encodes the allowed variable chemical groups, the rules for their connection to the core, and any exclusions specified in the regulatory text (i.e., chemicals that are excluded from entry coverage despite fitting the Markush definition).
The CMF cheminformatics engine is written in Python and is based on the RDKit [1] toolkit through its Python API [2]. The CMF cheminformatics engine detects matches between the search term and the database entries by performing the operations outlined below, with an architecture that allows it to match exact query structures with both exact and Markush-type database entries.
Step 1. Entry of Search Terms.
The user enters a single search term directly into the frontend, uploads multiple search terms in TXT format, or uploads chemical structures in SDF format. As the user types into the search box, the frontend retrieves autocomplete suggestions through the Wikidata entity-search API and the PubChem autocomplete API. The results are combined and duplicate suggestions are removed. Selecting a suggestion inserts it into the search box; the term is not processed until the search is launched.
Step 2. Conversion to Structure.
Upon receiving the search term from the frontend, the CMF cheminformatics engine first converts it into a molecular structure (an RDKit molecule object) – see Converting Search Terms into Structures.
Step 3. Generation of Variants.
If the Generate Variants option was selected, the CMF cheminformatics engine then generates chemically relevant variants of that structure – see Generating Molecular Variants.
Step 4. Evaluation of Structure and Metadata Matches.
Subsequently, the CMF cheminformatics engine checks the structure corresponding to the search term and any generated variants against the exact and Markush-type structures in the database, leading to the identification of any existing matches (Matches in Structure Search). Additionally, the cheminformatics engine checks the term directly, as a text string, against the metadata column in the database lists (Matches in Metadata Search) - Evaluating Structure and Metadata Matches.
Step 5. Production of Report.
Finally, the backend sends the results to the frontend, which formats them into an HTML report.
Converting Search Terms into Structures
For the CMF cheminformatics engine to be able to identify structural matches, search terms – whether typed manually or read from an uploaded TXT or SDF file – must be converted into a chemical structure represented as an RDKit molecule object.
Depending on the search term type, this conversion is either handled entirely by the CMF cheminformatics engine or assisted by external services (listed below), which resolve the search term into a SMILES string that CMF then uses to generate the corresponding RDKit molecule object. Depending on the service and the search term, the SMILES string may be generated algorithmically or retrieved via database lookup.
Search Term to SMILES services
- PubChem, developed by the National Library of Medicine of the U.S. National Institutes of Health, is a large database of over 121 million chemical structures [3, 4]
- Chemical Identifier Resolver (CIR), developed by the National Cancer Institute of the U.S. National Institutes of Health, is a database of approximately 16 million structures, associated with approximately 68 million chemical names. CIR also provides algorithmic resolvers for IUPAC names and structural identifiers, including, among others, SMILES and InChI codes [5, 6, 7].
- CAS Common Chemistry, developed by the Chemical Abstract Service (CAS) Division of the American Chemical Society, is a database of 500,000 chemical substances, entirely curated by expert scientists [8, 9].
- OPSIN, originally developed by the University of Cambridge and currently hosted by EMBL-EBI, is an algorithmic parser designed to interpret systematic, IUPAC-style chemical names [10].
- ChemSpider, developed by the UK Royal Society of Chemistry, is a large database of over 128 million chemical structures [11, 12].
Search Terms Directly Algorithmically Converted into RDKit Molecule Objects by CMF
- Structures and structural identifiers
Structures in SDF format and structural identifiers in SMILES and InChI format are handled entirely by the CMF cheminformatics engine, which converts them directly into RDKit molecule objects. In the rare event that they are not recognized internally, SMILES and InChI strings are passed to the “Search Term to SMILES” services. CIR resolves these structural identifiers algorithmically. CAS Common Chemistry, PubChem, and ChemSpider resolve them via database lookup.
Search Terms that Require Prior Resolution to SMILES
Algorithmic Resolution
- Systematic chemical names
Systematic chemical names can be resolved algorithmically using CIR or OPSIN. These tools tend to work very well—especially when the name is complete and properly formatted according to IUPAC conventions, as is the case for many computer-generated names.
- Systematic chemical names
Resolution via Database Lookup
For other types of search terms, resolution relies entirely on database lookup—so success depends on whether the database contains the term and whether it's correctly mapped to a structure. While these databases serve broader purposes, the CMF cheminformatics engine utilizes them as relational systems to associate chemical names and synonyms with precomputed SMILES representations. These databases differ in terms of their size (both regarding the number of entries and the information that they contain for each entry) and the extent of data curation and verification. A higher degree of curation is expected to increase accuracy, with the tradeoff of a narrower coverage. The CAS Common Chemistry database is entirely curated by CAS scientists. Conversely, both PubChem and ChemSpider rely heavily on information acquired through crowdsourcing and community-submitted data. These databases provide a very broad coverage of structures and chemical synonyms, including names in non-English languages, catalogue numbers, database identifiers. As a result, they enable broad compatibility with identifiers used across commercial catalogs, regulatory lists, and public databases. They both rely on filtering processes intended to check the consistency of the submitted data, which, however, does not necessarily reflect their accuracy [13]. As a result, at times, their accuracy may be lower than that of manually curated databases or algorithmic conversions. Of note, in ChemSpider, the chemical names associated with a given entry are divided into a “verified” section and an “unverified” section [14]. The ChemSpider API utilized by the CMF cheminformatics engine does not distinguish between the two sections.- Common or trade names
Common or trade names can be looked up using PubChem, CIR, CAS Common Chemistry, or ChemSpider. - InChIKey strings
InChIKey strings can be resolved into SMILES through database lookup via CAS Common Chemistry, CIR, PubChem, or ChemSpider. When they’re resolvable, InChIKeys are generally very reliable, since they’re standardized identifiers. - Numerical database identifiers
- CAS Registry Numbers: When using a CAS Registry Number® as a search term, we strongly recommend using CAS Common Chemistry as the Search Term to SMILES Service. This is the most reliable public source of verified CAS Registry Numbers. Other services used by CMF-CW can derive structures from CAS Registry Numbers too. However, because CAS Registry Numbers are proprietary identifiers maintained by the Chemical Abstracts Service (CAS), some numbers found through sources other than CAS may be inaccurate or outdated.
- PubChem CIDs and ChemSpider CSIDs: PubChem CID and ChemSpider CSID numbers can be resolved into SMILES by PubChem and ChemSpider, respectively. These identifiers are purely numerical, and selecting the wrong service will lead to incorrect structure resolution. If the numerical identifiers are prefixed with the CID: or the CSID: tags, CMF-CW will route the lookup accordingly — to PubChem for CIDs and to ChemSpider for CSIDs. See the How to Use CMF-CW page for an example.
- Common or trade names
Generating variants
The CMF cheminformatics engine can generate representational and molecular variants of the input chemical. Representational variants are alternative computational representations of a chemical’s molecular structure (e.g., implicit vs explicit encoding of hydrogens or ionic vs coordination encoding of metal-nonmetal bonds). Molecular variants are alternative versions of a chemical that have the same heavy-atom connectivity (ignoring hydrogen placement and bond orders) but constitute different chemically plausible forms (e.g., isotopic or stereochemical variants, tautomers, and protonation states). The CMF cheminformatics engine also treats individual chemical components of mixtures, including salts and hydrates, as variants of the mixture. During componentization, standalone inorganic components, such as counterions and water, are dropped, yielding desalted or desolvated variants.
Once the search term has been converted into an RDKit molecule object, and if the Generate Variants option is selected, the CMF cheminformatics engine generates a pool of plausible representational or molecular variants by applying a series of transformations.
Representational variants are generated by:
- Converting explicit hydrogens to implicit hydrogens
- Disconnecting metal-nonmetal bonds
Molecular variants are generated by:
- Combinatorially decomposing mixtures into their individual components (any remaining standalone inorganic components, such as salt counterions and water, are dropped)
- Removing isotopic specification
- Removing stereochemical specification
- Enumerating tautomers
- Generating uncharged forms by adding and/or removing hydrogens
- Generating protonation states based on pKa estimates
All variants are generated combinatorially through a serial pipeline of transformation steps. Each variant generation step is applied not only to the original search term, but also to all variants produced by preceding steps in the pipeline. This recursive approach ensures that all combinations of modifications are captured and evaluated.
Whether variants are actually generated depends on the nature of the RDKit molecule object corresponding to the search term. For example, a single-component RDKit molecule object already in its standard representation, with no explicit isotopes or stereochemistry, and with no alternative protonation or tautomeric states possible, will not produce any variants.
Evaluating Structure and Metadata Matches
For search terms that can be converted to structures, the CMF cheminformatics engine performs structural comparisons as well. Once the search terms have been converted to RDKit molecule objects and variants have been generated (collectively referred to as query molecule objects), the CMF cheminformatics engine systematically compares them with each entry in the integrated database.
For entries that define individual chemicals, matching is performed by checking for identity between the query molecule objects and the molecule object derived from the SMILES listed for that entry. Comparing RDKit molecule objects rather than SMILES is essential, as different SMILES strings can represent the same molecular structure.
For entries that define Markush-type families, matching is performed using a two-step process. First, the CMF cheminformatics engine checks whether the query molecule objects contain the molecule object derived from the SMILES of the core scaffold listed for that entry. If the core matches, the CMF cheminformatics engine then invokes an entry-specific Python script to conduct a more detailed evaluation. This script checks whether the substituents and connectivity present in the query molecule object conform to the rules defined for that family and ensures that the molecule is not among any explicitly excluded compounds.
For all search terms, the CMF cheminformatics engine performs a direct text comparison, always case-insensitive, with the metadata field of each entry in the integrated CW-control lists database. The behavior differs depending on whether the user has enclosed the search term in quotation marks. Search terms enclosed in quotation marks are treated as an exact phrase: a match occurs only if the entire quoted phrase exactly matches one of the metadata fields associated with the entry. Unquoted search terms are treated as individual words: a full match occurs if the entire search term exactly matches one complete metadata field; a partial match occurs if at least one complete metadata field is fully contained within the user's search term. If a match is only partial, this is flagged in a warning message in the report.
Structural comparisons can only be performed for search terms that can be converted into structures. Conversely, metadata comparisons can be performed for all search terms, but are limited to the information explicitly listed in the metadata field of the integrated database. This combined approach enhances the robustness of the identification process, due to the complementary strengths and limitations of the two methods.
Learn More and Launch CMF-CW
To explore CMF-CW in more detail, visit the following pages:
- About CMF-CW – Background on the project and its development
- Database of CW-Control Lists – The database currently implemented in CMF-CW
- How to Use CMF-CW – A step-by-step user guide
- Frequenty Asked Questions – Answers to common questions about CMF-CW
When you are ready, launch the CMF-CW screening tool.
References
- RDKit: Open-Source Cheminformatics Software, Link
- Python API Reference, Link
- PubChem Data Counts, Link
- Kim, S., Chen, J., Cheng, T., Gindulyte, A., He, J., He, S., Li, Q., Shoemaker, B. A., Thiessen, P. A., Yu, B., Zaslavsky, L., Zhang, J., & Bolton, E. E. (2025). PubChem 2025 update. Nucleic Acids Res., 53(D1), D1516–D1525. Link
- NCI CADD Group – About, Link
- Chemical Identifier Resolver documentation, Link
- NCI/CADD Chemical Structure Web Services, ACS Meeting New Orleans 2013 (CINF), Link
- CAS Common Chemistry, Link
- Jacobs, A., Williams, D., Hickey, K., Patrick, N., Williams, A. J., Chalk, S., McEwen, L., Willighagen, E., Walker, M., Bolton, E., Sinclair, G., & Sanford, A. (2022). CAS Common Chemistry in 2021: Expanding Access to Trusted Chemical Information for the Scientific Community. Journal of Chemical Information and Modeling, 62(11), 2737–2743. Link
- Lowe, D. M., Corbett, P. T., Murray-Rust, P., & Glen, R. C. (2011). Chemical Name to Structure: OPSIN, an Open Source Solution. Journal of Chemical Information and Modeling, 51(3), 739–753. Link
- ChemSpider, Chemical Vendors, Link
- Pence, H. E., & Williams, A. (2010). ChemSpider: An Online Chemical Information Resource. Journal of Chemical Education, 87(11), 1123–1124. Link
- Kim, S., Yu, B., Li, Q., & Bolton, E. E. (2024). PubChem synonym filtering process using crowdsourcing. Journal of Cheminformatics, 16(1), Article 69. Link
- ChemSpider FAQs, https://www.chemspider.com/faq" target="_blank" rel="noreferrer" class="banner-logo-link">Link