In the past it was possible to submit molecules which were duplicates of suggestions from other researchers - they were simply flagged as duplicate (regardless of whether the rationale or fragments shared anything in common).
Now when you submit a set of molecules, if one or more is inadvertenty a duplicate of some-one else’s submission the whole batch is rejected without any indication of which molecules is the duplicate. This makes the batch entry redundant unless one downloads and performs a duplicate check immediately prior to submission.
Ideally, those of us performing virtual screening would like to upload a file of SMILES (or SD) structures. We currently have a big backlog of molecules to submit - and I’m really excited about some of the covalent ligands which interact with both CYS(145) and HIS(41) - analogously (but different) to those in PDB code 4imq. (Most virtual screening/docking programmes are not designed to cope with covalent constraints).
We had started to outsource this data entry to a student but entering them one at a time because of a reluctance to entertain duplicate molecules supported by different rationales is sole destroying … it also means retaining links to our unique identifiers or to those of commercial libraries becomes 100x more difficult!
So I just tested it, and want to clarify that it only rejects duplicate designs when the duplicate is within your submission. Thus, I suspect that you may has mistakingly added a molecule twice within your own submission – though I may be missing something – so feel free to send over a counterexample.
As for bulk/file upload: This was actually intentional on our part. We have have been approached multiple times with people wanting to dump tens of thousands of molecules from docking or generative models; however, we really appreciate focused submissions, since we do not have the bandwidth to order thousands upon thousands of compounds or evaluate every docking methodology in detail. Therefore, I suggest that you pick out the few molecules with those exciting interactions and focus on submitting a smaller number of those. It is much easier for us to consider a small number than to have to look through a large list for the most exciting ones – you are in the best position to do that since you know the results and method very well.
In summary, it appears that the front-end performs checks to ensure that your set of molecules does not include duplicates and the backend server performs a further duplicate checks. These give difference error messages. The backend check appears to report duplicates when there are not present!
Unless our algorithm is faulty this does not contain duplicates. When adding these 100 molecules the front end did not report any duplicates. For the sake of clarity we then tried to enter a duplicate and got the expected error message " Unable to add molecule. Cannot submit duplicate molecules" and the duplicate was not added to the set. (See slide 4 in the attached open office file).
On submission we got a further different error message complaining that submitted molecules could not contain duplicates. “Unable to submit for synthesis. Cannot submit duplicate molecules”.
I also checked that there were no duplicates of earlier molecules we had submitted (a logical possibility). It is conceivable that there are different tautomers (I havent checked) but obviously there’s no scope for stereochemistry duplicates.
Index 68 and index 93, Oc1ccc(cc1O)C(O)CNC and Oc1cc(ccc1O)C(O)CNC respectively, seem to be duplicates once the SMILES are canonicalized. I expect that is the issue. I will look into why our frontend did not catch that.
Since our code didnt spot the duplicate I suspect the original published algorithm had a minor fault relating to dealing with rings. We’d really like an error message from the backend which told us which molecules cause a problem … and ideally not removing them from the entry form!