How to resolve organometallics

[marcosfelt]

From @rvanputt:

Resolution of complex ligands and metal complexes was more difficult. There is extensive diversity in naming here, so this should indeed be more difficult. I tried systematic names, CAS#, and trade names such as SL-J001-1, but unfortunately this didn’t yet work for most structures. I suspect including CAS and ChemSpider should improve this, as they have entries for many of these chemicals. (Could you help with that?)

I think the key here is (1) enabling more services and (2) relaxing the agreement algorithm in some cases to handle when only one service can find a compound (see #7).

Taking SL-J001-1 as an example, only PubChem could resolve this name out of the currently available services (PubChem, CIR, CAS, ChemSpider, OPSIN). Even when I looked up SL-J001-1 by its CAS number on Common Chemistry, which should be the definitive source for CAS numbers, nothing returned.

In terms of more services, here are some ideas:

• SigmaAlddrich: They have large number of commercially available compounds and, via inspection, it looks like they now have a well-formed (GraphQL?) API. However, there might be rate limiting issues, so we'd need to only use it as a last resort.
• Solvias: They have a wide range of commercially available ligands listed. However, the website doesn't have an API, so we'd need to do some type of RPA which would be slow.

@rvanputt, could you sample some of your difficult organometallics and see if they are available on Sigma or Solvias. If so, I'll look into writing a service for one of those.

[rvanputt]

Regarding SL-J001-1: I get a partial match in ChemSpider (they have 'Josiphos SL-J001-1' in their record), and a good match in CAS SciFinder with substance search. I'm surprised Common Chemistry doesn't know this ligand. Is it possible SciFinder has access to a different CAS database?

Addition of Sigma-Aldrich and Solvias catalogues would definitely help, but it might not be a silver bullet. Their products should already be in at least one of the databases. That makes me wonder if it is more a matter of finding them. This could, e.g., by done by allowing partial name matches for trade names or by using look-up tables for slightly different spellings ((R,R)-iPr-DuPhos, (R,R)-i-Pr-DuPhos, etc.). Again, this information is available in SciFinder, see below. Question is how to get to it. Or do you think that won't be feasible?

[marcosfelt]

I like the idea of doing different lookup names. Maybe we could have an option in the resolution algorithm to automatically replace certain "phrases" in the name with alternative spellings if the lookup fails.

An additional idea is to have a lookup table of pre-catalysts since there are a smaller number of those. I wrote something that did this for a project with all Ruthenium catalysts last year. I just used regex:

regex_lookup = {
        r"^(Chloro)([\{\}\[\]\+\-\(\),'a-zA-z\dηα]+)ruthenium\(II\) chloride": "Cl[Ru]Cl",
        r"^(Chloro)([\{\}\[\]\+\-\(\),'a-zA-z\dηα]+)\(p-cymene\)ruthenium\(II\) chloride": "Cl[Ru]Cl.CC(C)c1ccc(C)cc1",
        r"^(Dichloro)([\[\]\+\-\(\),'a-zA-z\dηα]+)ruthenium\(II\)": "Cl[Ru]Cl",
        r"^(Dichloro)([\[\]\+\-\(\),'a-zA-z\dηα]+)(?:\(p-cymene\))ruthenium\(II\)": "Cl[Ru]Cl.CC(C)c1ccc(C)cc1",
        r"(Diacetato)([\{\}\[\]\+\-\(\),'a-zA-z\dηα]+)ruthenium\(II\)": "[O-]CC(=O)[Ru]CC(=O)[O-]",
        r"(Chloro)([\[\]\+\-\(\),'a-zA-z\d]+)\(mesitylene\)ruthenium\(II\)": "Cc1cc(cc(c1)C)C.Cl[Ru]",
        r"(Chloro)([\[\]\+\-\(\),'a-zA-z\d]+)\(pyridine\)ruthenium\(II\)": "c1ccncc1.Cl[Ru]Cl",
        r"(Chloro)([\[\]\+\-\(\),'a-zA-z\d]+)ruthenium\(II\)": "Cl[Ru]",
        r"([\[\]\+\-\(\),'a-zA-z\d]+)\(p-cymene\)ruthenium\(II\) chloride": "[Ru]Cl",
        r"^(Chloro)([\{\}\[\]\+\-\(\),'a-zA-z\dηα]+)\(p-cymene\)ruthen(?:ium\(II\))?": "Cl[Ru].CC(C)c1ccc(C)cc1",
        r"^(Chloro)([\{\}\[\]\+\-\(\),'a-zA-z\dηα]+)ruthenium\(II\)": "Cl[Ru]",
}

Going even further, it may be possible to train a ML model to do this automatically (because writing regex strings takes a lot of effort, even if you know what you're doing). I wonder if we could come up with a dataset of a bunch of pre-catalysts and ligands and then just create a dataset from the enumeration of them with different spellings? We could then basically just fine-tune this model on that data.

[rvanputt]

I think both the look-up and regex direction (when coupled to ML) might be viable options for a majority of common cases and organic fragments. For metal precursors and chiral ligands I'm not fully sure, though. Again, this is because naming of metal precursors is hopelessly unsystematic (same problem as the chiral ligands) . This means there will be a lot of different names, and getting sufficient agreement will be difficult. For example, let's consider Rh(NBD)2BF4 as an example. A quick search on SciFinder, PubChem, and ChemSpider (by CAS#) returned a lot of known aliases:

36620-11-8
Rh(nbd)2BF4
Rhodium(1+), bis[(2,3,5,6-η)-bicyclo[2.2.1]hepta-2,5-diene]-, tetrafluoroborate(1-) (1:1) (ACI)
Bicyclo[2.2.1]hepta-2,5-diene, rhodium complex (ZCI)
Borate(1-), tetrafluoro-, bis[(2,3,5,6-η)-bicyclo[2.2.1]hepta-2,5-diene]rhodium(1+) (ZCI)
Rhodium(1+), bis[(2,3,5,6-η)-bicyclo[2.2.1]hepta-2,5-diene]-, tetrafluoroborate(1-) (9CI)
(NBD)2RhBF4
Bis(bicyclo[2.2.1]hepta-2,5-diene)rhodium tetrafluoroborate
Bis(norbornadiene)(tetrafluoroborato)rhodium
Bis(norbornadiene)rhodium tetrafluoroborate
Bis(norbornadiene)rhodium(1+) tetrafluoroborate
Bis(norbornadiene)rhodium(I) tetrafluoroborate
[Rh(NBD)2]BF4
[rh(norbornadiene)2]bf4
Chiralyst P374
bis[??-(2,5-norbornadiene)]rhodium(i) tetrafluoroborate
Bis[η-(2,5-norbornadiene)]rhodium(I) Tetrafluoroborate
[Bis[eta-(2,5-norbornadiene)]rhodium(I) Tetrafluoroborate]
MFCD00671775

This made me think about how to leverage the services that are already available. I see that they probably contain what we're looking for, but it is a matter of using the right query to get to it.

In order to do that, what do you think about using an iterative approach? Think of it as a two-stage rocket. First, a given query is given to all services. Chances are it will be found in at least one of these (a ranked output would probably also be helpful here). This service will probably also have a record of its CAS number or other alias. This CAS# or alias can then be used to query the other services for a second round in order to get sufficient agreement.

Advantage of this approach is that it relies on the code you've written so far. Of course, it also comes with a risk of false positives, but if we can prioritise CAS# for the second round, I think this should be fairly minimal.

What do you think?

[marcosfelt]

That's brilliant! I think I could have an argument like "backup_identifier_type" (not sure about the name yet) that would be used as a fallback like you've described. I'll try to implement that today!

…

On Thu, 27 Oct 2022 at 17:21, rvanputt ***@***.***> wrote: I think both the look-up and regex direction (when coupled to ML) might be viable options for a majority of common cases and organic fragments. For metal precursors and chiral ligands I'm not fully sure, though. Again, this is because naming of metal precursors is hopelessly unsystematic (same problem as the chiral ligands) . This means there will be a lot of different names, and getting sufficient agreement will be difficult. For example, let's consider Rh(NBD)2BF4 as an example. A quick search on SciFinder, PubChem, and ChemSpider (by CAS#) returned *a lot* of known aliases: 36620-11-8 Rh(nbd)2BF4 Rhodium(1+), bis[(2,3,5,6-η)-bicyclo[2.2.1]hepta-2,5-diene]-, tetrafluoroborate(1-) (1:1) (ACI) Bicyclo[2.2.1]hepta-2,5-diene, rhodium complex (ZCI) Borate(1-), tetrafluoro-, bis[(2,3,5,6-η)-bicyclo[2.2.1]hepta-2,5-diene]rhodium(1+) (ZCI) Rhodium(1+), bis[(2,3,5,6-η)-bicyclo[2.2.1]hepta-2,5-diene]-, tetrafluoroborate(1-) (9CI) (NBD)2RhBF4 Bis(bicyclo[2.2.1]hepta-2,5-diene)rhodium tetrafluoroborate Bis(norbornadiene)(tetrafluoroborato)rhodium Bis(norbornadiene)rhodium tetrafluoroborate Bis(norbornadiene)rhodium(1+) tetrafluoroborate Bis(norbornadiene)rhodium(I) tetrafluoroborate [Rh(NBD)2]BF4 [rh(norbornadiene)2]bf4 Chiralyst P374 bis[??-(2,5-norbornadiene)]rhodium(i) tetrafluoroborate Bis[η-(2,5-norbornadiene)]rhodium(I) Tetrafluoroborate [Bis[eta-(2,5-norbornadiene)]rhodium(I) Tetrafluoroborate] MFCD00671775 This made me think about how to leverage the services that are already available. I see that they probably contain what we're looking for, but it is a matter of using the right query to get to it. In order to do that, what do you think about using an iterative approach? Think of it as a two-stage rocket. First, a given query is given to all services. Chances are it will be found in at least one of these (a ranked output would probably also be helpful here). This service will probably also have a record of its CAS number or other alias. This CAS# or alias can then be used to query the other services for a second round in order to get sufficient agreement. Advantage of this approach is that it relies on the code you've written so far. Of course, it also comes with a risk of false positives, but if we can prioritise CAS# for the second round, I think this should be fairly minimal. What do you think? — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGF3OR355MDB5Z46GD3K44DWFKTX7ANCNFSM6AAAAAARN75QSU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rvanputt]

Cool! Curious how well it will work and what the hit rate is going to be. Let me know if you want more things to test beyond the pptx. The examples in there are already difficult ones, so if the new approach can do those, I'm hopeful it will be able to handle the rest.

[marcosfelt]

Okay perfect!

…

On Fri, 28 Oct 2022 at 11:40, rvanputt ***@***.***> wrote: Cool! Curious how well it will work and what the hit rate is going to be. Let me know if you want more things to test beyond the pptx. The examples in there are already difficult ones, so if the new approach can do those, I'm hopeful it will be able to handle the rest. — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGF3OR6IBXZ24U6U6RX7NC3WFOUQVANCNFSM6AAAAAARN75QSU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[marcosfelt]

@rvanputt Could you take a look at this PR and see if it's what you were thinking: #14

[rvanputt]

Looks good! I'm curious to see how well it works!

[marcosfelt]

I just pushed a new version to pypi with these changes, so you can install that (instead of directly from source):

pip install -U pura

To use the new feature, add a backup_identifier_types keyword argument to resolve_identifiers:

resolved = resolve_identifiers(
    ["Josiphos SL-J001-1"],
    input_identifer_type=CompoundIdentifierType.NAME,
    output_identifier_type=CompoundIdentifierType.SMILES,
    backup_identifier_types=[CompoundIdentifierType.INCHI_KEY],
    services=[
        PubChem(),
        CIR(),
    ],
    agreement=2,
)
print(resolved)

[rvanputt]

I have just tested the new code with a small set of chiral ligands and metal precursors, using PubChem, CIR, and ChemSpider. It is now able to resolve more than before - very good! I've also seen some behaviour that I don't yet fully understand that I think is interesting.

First of all, the test set and code:

from pura.services import PubChem, CIR, ChemSpider
from pura.resolvers import resolve_identifiers
from pura.compound import CompoundIdentifierType

resolved = resolve_identifiers(
    [
    "(R,R)-Dipamp",
    "(R,R)-Et-DUPHOS",
    "(R)-Phanephos",
    "(R,R)-Et-BPE",
    "Taniaphos SL-T001-1",
    "(R,R)-BenzP*",
    "(R)-DM-BINAP",
    "(R)-DTBM-SEGPHOS",
    "Rh(nbd)2BF4",
    "(p-Cymene)ruthenium(II) chloride dimer",
    ],
    input_identifer_type=CompoundIdentifierType.NAME,
    output_identifier_type=CompoundIdentifierType.SMILES,
    backup_identifier_types=[CompoundIdentifierType.INCHI_KEY],
    services=[
        PubChem(),
        CIR(),
        ChemSpider(token="token"),
    ],
    agreement=2,
)

(R,R)-Dipamp, (R)-Phanephos, (R,R)-Et-BPE, Taniaphos SL-T001-1, (R)-DM-BINAP, (R)-DTBM-SEGPHOS, and (p-Cymene)rutenium(II) chloride dimer resolve well. Not sure whether this is because I included ChemSpider or because the back-up resolution works well. Did not test that. But in either case, this is a good result.

The other entries somehow were more difficult, despite these exact queries being present in at least one of the databases. For example, DuPhos and (R,R)-BenzP* are very common ligands with unambiguous structures or names. Perhaps unsurprisingly, SL-T001-1 alone did not work, but the inclusion of Taniaphos helped. This is not ideal (no partial matches then?), but can be addressed in a pre-cleaning step because Solvias' encoding is straightforward (SL-J00X for JosiPhos, SL-T00X for TaniaPhos, W00X for WalPhos, M00X for Mandyphos, etc. Have not tested how it handles the BIPHEPs (SL-A10X-X) and ChenPhos ligands).

Frustratingly, Rh(NBD)2BF4 still is not resolved. I'm not sure what the problem is. It is present in PubChem with exactly that naming. I get an error that the SMILES string is not electrically neutral, but then it just gives up.

I noticed two more things. First, execution of the queue stops when the current query cannot be resolved. This means that the code above won't run until all bad entries are commented out. Not mission critical, but a bit annoying. Makes me want to write a loop to call the code one-by-one... :)

Finally, I played around a bit with using different output- and backup identifier types. Here I am a bit puzzled. Using INCHI and INCHI_KEY works well most of the time. (I suspect not all services have this information for all examples above, even though I haven't checked.) But when using CAS_NUMBER for either identifier, unfortunately I get errors. Last output:

File "/.../pura/services/pubchem.py", line 165, in get_properties
    properties = ",".join([PROPERTY_MAP.get(p, p) for p in properties])
TypeError: sequence item 0: expected str instance, NoneType found

When I remove PubChem from the services and try it with the other two, the error changes

ValueError: [<CompoundIdentifierType.CAS_NUMBER: 7>] are invalid output identifier type(s) for ChemSpider

Does that make any sense to you?

All in all, I think this is a leap towards automatically resolving these more difficult compounds! I'm curious to hear what you think about these results. And fingers crossed you know how to work with CAS#!

[marcosfelt]

Thanks for the detailed feedback!

The other entries somehow were more difficult, despite these exact queries being present in at least one of the databases. For example, DuPhos and (R,R)-BenzP* are very common ligands with unambiguous structures or names. Perhaps unsurprisingly, SL-T001-1 alone did not work, but the inclusion of Taniaphos helped. This is not ideal (no partial matches then?), but can be addressed in a pre-cleaning step because Solvias' encoding is straightforward (SL-J00X for JosiPhos, SL-T00X for TaniaPhos, W00X for WalPhos, M00X for Mandyphos, etc. Have not tested how it handles the BIPHEPs (SL-A10X-X) and ChenPhos ligands).

I think this is an issue of there not being exact matches (e.g., DuPhos vs (S,S)-I-Pr-DUPHOS). I'll look into the partial names question in this issue: #18 .

Frustratingly, Rh(NBD)2BF4 still is not resolved. I'm not sure what the problem is. It is present in PubChem with exactly that naming. I get an error that the SMILES string is not electrically neutral, but then it just gives up.

Hopefully, the electrically neutral bit is a warning. I checked and Rh(NBD)2BF4 resolves only on PubChem. I want to go back and check to see if I can handle it by fixing some of the other bugs below.

I noticed two more things. First, execution of the queue stops when the current query cannot be resolved. This means that the code above won't run until all bad entries are commented out. Not mission critical, but a bit annoying. Makes me want to write a loop to call the code one-by-one... :)

I failed to mention this earlier: add the keyword argument silent=True. This will allow the algorithm to continue running even if there is an error.

Finally, I played around a bit with using different output- and backup identifier types. Here I am a bit puzzled. Using INCHI and INCHI_KEY works well most of the time. (I suspect not all services have this information for all examples above, even though I haven't checked.) But when using CAS_NUMBER for either identifier, unfortunately I get errors. Last output:

File "/.../pura/services/pubchem.py", line 165, in get_properties
    properties = ",".join([PROPERTY_MAP.get(p, p) for p in properties])
TypeError: sequence item 0: expected str instance, NoneType found

This is a bug which I'll fix (#17)

When I remove PubChem from the services and try it with the other two, the error changes

ValueError: [<CompoundIdentifierType.CAS_NUMBER: 7>] are invalid output identifier type(s) for ChemSpider

Does that make any sense to you?

This error is expected since some services are not compatible with certain CompoundIdentifierType. If you set silent=True, then the error should be skipped over. I'll make sure to mention the use of silent=True in the documentation when I get to it.

[rvanputt]

I failed to mention this earlier: add the keyword argument silent=True. This will allow the algorithm to continue running even if there is an error.

This is nice! Thanks a lot. Let me know if there is anything I can do to test. If all goes well, I might try some of our real set next time.

[marcosfelt]

I just published 0.2.1 to pypi which includes a partial name search feature for PubChem and fixes to the bugs mentioned above. So a complete example would look like:

resolved = resolve_identifiers(
    ["Josiphos SL-J001-1", "Rh(NBD)2BF4", "DuPhos"],
    input_identifer_type=CompoundIdentifierType.NAME,
    output_identifier_type=CompoundIdentifierType.SMILES,
    backup_identifier_types=[
        CompoundIdentifierType.INCHI_KEY,
        CompoundIdentifierType.CAS_NUMBER,
    ],
    services=[PubChem(autocomplete=True), CIR(), CAS(), ChemSpider()],
    agreement=1,
    silent=True,
)
print(resolved)

To install

pip install -U pura