Is the HBP module released in the the general 1.3 update? If so is there some documentation on it?
Thanks for the clarification. Perhaps in future versions this facility could be considered? To illustrate why this is important (at least to me) is this: I have a long list of common chemical entities and I want to pull their crystal structures (if they exist) and then do additional calculations (such as lattice energies) using interfaces with other program packages (such as materials studio). Now, I want to do this in an automated fashion so the search could be done on "name", "smiles string" or any other type of identifier (except of course the CSD identifier since I do not have prior knowledge of it). The problem with doing a substructure search or a name search is that there are far too many hits to go through and find the correct structure for simple chemical entities. For example, finding if a crystal structure of THF exits gives >20,000 hits alone when you do a name search, benzene is similar. In my case I have a list of 1000+ chemicals this quickly becomes difficult to handle.
I have probably a rather simple question. I would like to search the csd using a smiles string but match only on compounds in which the whole string is matched (rather than a substructure search). How would one do this?
Yes that's the one I was looking for.
In conquest there is a "compound" field that we have used in the past to add details about in-house structures. I cannot seem to find this attribute in the entry/crystal/molecule classes, does anyone know if it is available?
Thanks Dave. No free lunch I have to sit down and read the documentation.
I'm having a bit of trouble understanding an error that I'm getting (the script with minor modifications was originally written by Ilenia and I have attached it here). The api was installed on Redhat 6 and all the tests ran fine.
File "./test.py", line 109, in <module>
File "./test.py", line 102, in main
ccdc_mol = csd_reader.molecule(h)
File "/nfs/grid/software/pharmsci/apps/Linux-x86_64-RHEL6/csdPythonApi/0.7/python2.7.10/lib/python2.7/site-packages/ccdc/io.py", line 709, in molecule
File "/nfs/grid/software/pharmsci/apps/Linux-x86_64-RHEL6/csdPythonApi/0.7/python2.7.10/lib/python2.7/site-packages/ccdc/io.py", line 691, in entry
e = self._db.entry(UtilitiesLib.DatabaseEntryIdentifier(id))
File "/nfs/grid/software/pharmsci/apps/Linux-x86_64-RHEL6/csdPythonApi/0.7/python2.7.10/lib/python2.7/site-packages/ccdc/_lib/UtilitiesLib.py", line 487, in __init__
this = _UtilitiesLib.new_DatabaseEntryIdentifier(*args)
RuntimeError: DatabaseEntryIdentifier::DatabaseEntryIdentifier: Invalid DatabaseEntryIdentifier (wrong size):AHEPUY|AMUBAM|COKCEL|COTYOA02|COTYOA03|COTZAN02|COTZAN03|COTZAN04|HUMJEE|HXACAN|HXACAN01|HXACAN04|HXACAN06|HXACAN07|HXACAN08|HXACAN09|HXACAN10|HXACAN11|HXACAN12|HXACAN13|HXACAN14|HXACAN15|HXACAN16|HXACAN17|HXACAN18|HXACAN19|HXACAN21|HXACAN22|HXACAN23|HXACAN24|HXACAN25|HXACAN26|HXACAN27|HXACAN28|HXACAN29|HXACAN30|HXACAN31|HXACAN32|HXACAN33|HXACAN34|KETYUF|KETZAM|KETZEQ|KETZIU|KIGLUI|KIGLUI01|LUJSIT|LUJSOZ|LUJTAM|MUPPES|MUPPES01|MUPPES02|MUPPIW|MUPPOC|MUPPUI|MUPQAP|MUPQET|NIDPIB|NIDPOH|NIDPUN|OMISIM|SUTVAF|WAFNAT|WIGBUL|WIGCAS|WIGCEW|XAYGOV|XOMWOL
I started to track down the various dynamic libraries that are linked to the ccdc api. The most common system libraries I found were:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1094.0.0)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 9.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.19.0)
These seem to be related to c++ libraries rather than python. I do have an updated version of gcc on my machine. Do you think that there is a conflict in the possible different versions of gcc/g++ on my laptop that is causing the issue?
Update....the problem seems to be with the ccdc modules, placing the following (below) into a file and using python to execute it gives:
from ccdc.search import (
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6
As you say above it looks like when pip installs lxml, numpy and Pillow it might be reverting back to the old python. Do you know if pip unlinks the User environment before it starts to compile?
Thanks for the suggestions. My next step was to narrow down which library it might be so it sounds like I was on the right path. The problem we have here is that the company I work with has strict firewalls and poses limitations on what software can be installed so it is nearly impossible to to update system code or even install a binary version of non-approved code. The only way around it is to have a separate environment placed in my home space...hence compiling python from source....I'll let you know how I go.