Closed pavankum closed 3 years ago
Thanks for posting this. I believe this was intentional as I wanted to try and be consistent with the use of OE rather than some things being handler by AT + RDKit and some by OE:
If you use OE then things should work fine
Thank you @SimonBoothroyd, sorry forgot about that. OE fails for few records that have implicit hydrogens such as '[NH+:1]([C@:2]([C:3](=[O:4])[O-:10])([C:5]([C:6]([C:7]([C:8]([NH+:9]([H:22])[H:23])([H:20])[H:21])([H:18])[H:19])([H:16])[H:17])([H:14])[H:15])[H:13])([H:11])[H:12]'
. May be I will download data using rdkit, save to file and parse the collection from it and continue rest of the workflow with OE.
This was the issue
Hmm can we not just exclude such molecules?
May be I will download data using rdkit, save to file and parse the collection from it and continue rest of the workflow with OE
I'm not 100% sure I follow this - could we not just use OE for everything?
results collection builds molecules and OE fails when it encounters those implicit hydrogen smiles, can I exclude them while downloading the dataset?
I guess here, while inchikey is generated, https://github.com/openforcefield/openff-qcsubmit/blob/4a239bfe606b541b4088a0f95da252ed21526197/openff/qcsubmit/results/results.py#L446-L454
@SimonBoothroyd Here is a traceback for one molecule that fails to get through qcsubmit download from server function call, the same works well when a molecule is created directly from this smiles using openff toolkit, so not sure what's happening:
This was without openeye and using rdkit, the versions of packages are: