• RE: Installation issue with Qt xcb

    Dave,

    Thanks for the information. Unfortunately the end result was still the same. I manage to find a couple of problems, and get around them, so I will post them here in case someone else runs into this issue:

    1. When I ran the command ldd on libqxcb.so ($PYTHONHOME/lib/python2.7/site-packages/ccdc/_lib/plugins/platforms) I found:

    libSM.so.6 => not found
    libICE.so.6 => not found

    Running "sudo apt install libsm6" solved both dependencies

    2. Once that was done then I got the following message when trying to import ccdc in python:

    Python 2.7.15 |Anaconda, Inc.| (default, Dec 14 2018, 19:04:19)
    [GCC 7.3.0] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ccdc
    QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-<userid>'
    qt.qpa.screen: QXcbConnection: Could not connect to display
    Could not connect to any X display.

    SInce I only want to run the CSD API without any display, I solved it by adding:

    export QT_QPA_PLATFORM='offscreen'

    to ~/.bashrc (https://github.com/ipython/ipython/issues/10627)

    Turning off the Qt display was one of my original questions and this is one way to do it. I'm not sure if there will be any issues going forward but I was able to run my existing docking code that was working with the CCDC 2018 version without any issues.

     

    Thanks for your help,

    Hector

     

  • Installation issue with Qt xcb

    I have successfully installed the linux version of CCDC 2019, with the Python API, on the Ubuntu terminal, 16.04.3 LTS (Xenial Xerus), of a Windows 10 system. Unfortunately, when I try importing the ccdc module:

    ./run_csd_python_api

    Python 2.7.15 |Anaconda, Inc.| (default, Dec 14 2018, 19:04:19)
    [GCC 7.3.0] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ccdc
    This application failed to start because it could not find or load the Qt platform plugin "xcb" in "".

    Available platform plugins are: xcb, eglfs, minimal, minimalegl, offscreen, vnc.

    Reinstalling the application may fix this problem.
    ./run_csd_python_api: line 4: 2116 Aborted (core dumped) python

    ***************

    The ccdc library is the only one defined in the library path

    echo $LD_LIBRARY_PATH
    /home/<userid>/CCDC/Python_API_2019/miniconda/lib/python2.7/site-packages/ccdc/_lib

    and the ccdc bin is properly set in the $PATH.

    *******

    It seems to me that there should not even be a reason for trying to load the Qt plugin at all since this is a terminal only with no need for X11 support for GUI display (I only need to run the API). Is there a way to disable it (e.g.set to TKagg or agg) or is there some way to get around this issue?

    Thanks,

    Hector

  • RE: Is it possible (license) to run our CSD API server on Google cloud?

    Ilenia,

    Perfect. Thanks,

    Hector

  • Is it possible (license) to run our CSD API server on Google cloud?

    Hi,

    We are exploring the options of using Google cloud services and would like to find out if it is possible to setup our server running the CSD API on the cloud (to run on a need to basis with variable amount of resources as needed) - is that allowed by the current licensing? Any relevant information will be helpful.

    Thanks,

    Hector

  • RE: distance constraint from fixed cofactor to substrate (ligand to be docked)

    Ilenia,

    Thanks for the update. I went to download it and try it out but I noticed it requires a 2019 license which we have not gotten yet so it will have to wait (we have the 2018 license and are in the final stage of evaluating multiple tools to decide which ones to keep/get next year). We will be making a decision soon.

    Thanks for all your help,

    Hector

  • RE: distance constraint from fixed cofactor to substrate (ligand to be docked)

    That will be helpful, Thanks...

  • RE: distance constraint from fixed cofactor to substrate (ligand to be docked)

    Ilenia,

    I'm just going to run the docking without that constraint for now until the new release comes out and then I'll have to re-run it and redo the analysis. I have until the middle of December to decide if we are going to use the docking API or not so hopefully that should be enough time.

    What would be the best way to find out when the November release is made available for download?

    Thanks,

    Hector

     

  • RE: distance constraint from fixed cofactor to substrate (ligand to be docked)

    Ilenia,

    Glad you could confirm it. Your suggestion will be a problem to complete the project I'm working on since I'll be going through thousands of protein files and some do not have a unique atom names. I went ahead and tried your suggestion on a small set of protein files where it should have worked but unfortunately I was not able to get it to work. I was able to get the atom properly using the protein.atom function. I also generated the config file and then modified it as you indicated (and confirmed the change was done properly). Unfortunately, when I ran the docking, using the existing settings file, I got an 'index out of range' error when docking.py tried to access the settings.ligands[0].atoms[...] for the constraint. It is possible that something is not right with my 'rig up' and re-docking setup (I assume that it actually worked for you).

    At this point, I've wasted way too much time on this issue. Can you provide me with a time frame for the fix to be implemented so I can figure out what my options are?

    Thanks,

    Hector

     

  • RE: distance constraint from fixed cofactor to substrate (ligand to be docked)

     Ilenia,

    I know it's been a few days but I wanted to see if you could look at the 'output/gold.err' log that was generated when you ran the code you previously provided above. Another option would be to provide me with the test files (protein.mol2 and ligand.mol2) you used and I will run the code and check the log.

    The reason for wanting to do so is that I just found all the docking logs I've generated contain a warning message in gold.err like:

    ********************************************************************************
    Ligand in file /home/hdelrisco/projects/kreds/Substrate_R_v2.mol2, named Substrate_R,
    starting at address 70 raised the following warnings and/or errors
    Warning message:
    Distance constraint disabled for ligand Substrate_R; no atom 72 in Ligand

    ---- happens even with your sample SAH.mol2

    What this means is that using a different ligand (from the CCDC files) or changing the format of our ligand did not solve the issue; it just moved the error message to a warning message somewhere else. It would be real simple to find out if this is really a problem with my files (using your code to test them) by making sure that using your code and files results in no warning. It's very important to remember that we only have any issues with docking when we try to set the distance constraint between the cofactor (in the protein file) and the ligand - if we use a protein atom instead of the cofactor, it all works perfectly and the API does not have any issues with the ligand file format.

    Thanks,

    Hector

     

     

  • RE: distance constraint from fixed cofactor to substrate (ligand to be docked)

    Ilenia,

    As a result of running your code with my data, it seemed likely that it was a file issue and it was.

    It turned out to be the substrate mol2 file (ligand to be docked). None of the other utilities had any problems with it but it seems to cause problems for Gold. It was using an asterisk character for the internal name which I've seen happen before when working on files across multiple apps. I changed it manually just to try it and I can set the constraint now - the person who generated the file will be fixing it properly later.

    Thanks for all your help,

    Hector