Incorporating DruGUI into ProDy

[Cventura18]

This is an update of DruGUI to DruGUI 2.0, which is compatible with Python 3 and ProDy. Unlike the previous which was made in TCL, DruGUI 2.0 is written fully in python. The user will have to provide their vmd executable, which will prepare the system for druggability simulations. There is a GUI version and a non-gui version as well. DruGUI 2.0 uses the most update CHARMM forcefields, allows for easier preparation of membrane proteins, and an updated set of probe molecules. (Membrane protein druggability simulations have only been done with POPC membranes)

from prody.drugui import DruGUI
DruGUI()

This will open the DruGUI 2.0 GUI which is similar to the current GUI of DruGUI. Preparation and analysis of druggability simulations can be performed here. Probe grid calculations and druggability assessment have been combined and is under the Analysis Result section. Future updates will include evaluating a hotspot with a known ligand of the protein. Using the GUI only allows for the preparation of seven unique probes. The non-GUI version allows for more probes to be selected for druggability simulations.

from prody.drugui import drugui_prepare

drugui_prepare(pdb="/Users/carlosventura/Desktop/druggability/testprotein/MDM2/1ycr_chainA_autopsf.pdb", psf="/Users/carlosventura/Desktop/druggability/testprotein/MDM2/1ycr_chainA_autopsf.psf", prefix = "dg",
outdir_location="/Users/carlosventura/Desktop/druggability/testprotein/MDM2",
vmd='/Applications/VMD1.9.4a57-arm64-Rev12.app/Contents/vmd/vmd_MACOSXARM64')

from prody.drugui import drugui_analysis

drugui_analysis(pdb='/Users/carlosventura/Desktop/druggability/testprotein/pthr_membrane/simulation_run1/newcgenff.pdb',
psf='/Users/carlosventura/Desktop/druggability/testprotein/pthr_membrane/simulation_run1/newcgenff.psf',
dcds='/Users/carlosventura/Desktop/druggability/testprotein/pthr_membrane/simulation_run1/final.dcd',
outdir_location='/Users/carlosventura/Desktop/druggability/testprotein/pthr_membrane/simulation_run1/al1',
probes=['IPAM', 'IPRO', 'ACTT', 'IBUT', 'ACAM', 'IMID', 'BENZ'])

This is how the non-gui version is called. {"IPRO": 16, "IMID": 14, "ACTT": 14, "ACAM": 14, "IPAM": 14, "IBTN": 14, "BENZ": 14} is the default probe composition that is currently used in the lab and is the default probes for drugui_prepare. The user can provide their own custom probe composition. For drugui_analysis, ['IPAM', 'IPRO', 'ACTT', 'IBUT', 'ACAM', 'IMID', 'BENZ'] are the default probes for the analysis. Other probes can be used based on the probe composition used for druggability simulations. The parameters for analyzing druggability simulations in drugui_analyze are similar to the parameters in the GUI version.

[AnthonyBogetti]

Thanks, @Cventura18, this looks like a huge undertaking! Can you please provide us with a minimal workflow or jupyter notebook that we can use to test the code on our end? Also, we may want to write some unit tests for this, since it is a pretty complex module. Let me think about that though.

[AnthonyBogetti]

Also, we will want to remove the .DS_Store files and add that to the gitignore.

[AnthonyBogetti]

Create or open the .gitignore file in the root of your repository and add the following line:
.DS_Store

If .DS_Store files were already committed, they need to be removed from Git's tracking index. Use the git rm --cached command:
git rm --cached .DS_Store

If .DS_Store files exist in multiple directories, you might need to run this command for each instance or use a find command to automate the removal. For example:
find . -name ".DS_Store" -print0 | xargs -0 git rm --cached --ignore-unmatch

After removing the files from the index, commit these changes to the repository:
git commit -m "Remove .DS_Store files"

I just found the above on Google but that should work.

[Cventura18]

@AnthonyBogetti will do!

Thanks, @Cventura18, this looks like a huge undertaking! Can you please provide us with a minimal workflow or jupyter notebook that we can use to test the code on our end? Also, we may want to write some unit tests for this, since it is a pretty complex module. Let me think about that though.

[AnthonyBogetti]

Hi @Cventura18 this script contains three paths on your local filesystem. Would you be able to modify this script so it is more general?

[Cventura18]

Yes, I can modify it!

[AnthonyBogetti]

Thanks!

[AnthonyBogetti]

Please similarly change this to be more general.

[Cventura18]

I have had a look through. In the coming few days, I can 1) fix the typo James pointed out in test_pdbfile.py, 2) reduce (or remove) the test files to make sure ProDy doesn't take up too much storage space (I've been doing this with other tests with mock patching, which preserves the main test functions while reducing the storage space needed for large test files), 3) do thorough testing on my end and see if anything else needs changing, but right now it all looks good to me.

My only concern, and maybe this really isn't a concern, but I'm just worried about licensing and redistribution rules with respect to the charmm force field. Do you know if files like this one prody/drugui/DruGUI-script/par_all36_prot.prm and others are allowed to be redistributed as part of ProDy with our license? I think the probe prm files are fine, as long as those were generated by us, but I think it would be good to avoid potential legal issues associated with redistributing the CHARMM FF which I can't find a license for, so it would probably be best to just have users download that separately, if needed. @Cventura18 and @jamesmkrieger any thoughts on this? I'm not an experienced CHARMM user so maybe I'm wrong but I just want to be careful.

[Cventura18]

I know in the original DruGUI, the CHARMFF was provided by VMD itself. I did include a function for the nogui and gui version to add additional parameters. This can be used if were not able to redistribute the files

I have had a look through. In the coming few days, I can 1) fix the typo James pointed out in test_pdbfile.py, 2) reduce (or remove) the test files to make sure ProDy doesn't take up too much storage space (I've been doing this with other tests with mock patching, which preserves the main test functions while reducing the storage space needed for large test files), 3) do thorough testing on my end and see if anything else needs changing, but right now it all looks good to me.
My only concern, and maybe this really isn't a concern, but I'm just worried about licensing and redistribution rules with respect to the charmm force field. Do you know if files like this one prody/drugui/DruGUI-script/par_all36_prot.prm and others are allowed to be redistributed as part of ProDy with our license? I think the probe prm files are fine, as long as those were generated by us, but I think it would be good to avoid potential legal issues associated with redistributing the CHARMM FF which I can't find a license for, so it would probably be best to just have users download that separately, if needed. @Cventura18 and @jamesmkrieger any thoughts on this? I'm not an experienced CHARMM user so maybe I'm wrong but I just want to be careful.

[jamesmkrieger]

I have had a look through. In the coming few days, I can 1) fix the typo James pointed out in test_pdbfile.py, 2) reduce (or remove) the test files to make sure ProDy doesn't take up too much storage space (I've been doing this with other tests with mock patching, which preserves the main test functions while reducing the storage space needed for large test files), 3) do thorough testing on my end and see if anything else needs changing, but right now it all looks good to me.
My only concern, and maybe this really isn't a concern, but I'm just worried about licensing and redistribution rules with respect to the charmm force field. Do you know if files like this one prody/drugui/DruGUI-script/par_all36_prot.prm and others are allowed to be redistributed as part of ProDy with our license? I think the probe prm files are fine, as long as those were generated by us, but I think it would be good to avoid potential legal issues associated with redistributing the CHARMM FF which I can't find a license for, so it would probably be best to just have users download that separately, if needed. @Cventura18 and @jamesmkrieger any thoughts on this? I'm not an experienced CHARMM user so maybe I'm wrong but I just want to be careful.

Yes, we may have an issue with cgenff for commercial users. This may include probes

[AnthonyBogetti]

Hi @Cventura18, I have been testing, and so far the GUI part seems to be working. One favor though, can you make a warning message if the user leaves the Output folder blank?

Also, I would be interested in having the CHARMM force field files removed. Particularly this one: [top_all36_cgenff.rtf], but the rest as well, mostly for copyright considerations and also because they add altogether 300,000+ lines of code to ProDy. Can you think of anyway to avoid that? maybe we could still have a simple user installation step involving these files before running DruGUI() and the user could get these from prody.org or something. What do you think? Other than that, I just need to test the non-gui one but I think it should be working so this may be close.

[Cventura18]

Hi @AnthonyBogetti I can include that warning message and remove the CHARMM force field files. I think an installation step is a good idea. Do you know where in particular the lines of code are being added? That would help me come up with an idea how to make the installation step.

[AnthonyBogetti]

Hi @Cventura18, this file in particular, which is included twice is 50k lines per file: prody/drugui/DruGUI-script/druggability/top_all36_cgenff.rtf

Also, any other file with cgenff I worry about the copyright issue... do you know which ones are OK to include and which to not? I think the probe molecule prms might be OK, but any database kind of file (like the rtf one above) we probably should have the user obtain that separately.

[AnthonyBogetti]

Unfortunately, I am not as familiar with how CHARMM/NAMD does things, but you will know better which files will be necessary and which ones the user can download separately during the installation.

[Cventura18]

Hi @AnthonyBogetti,

I was able to successfully modify the code. In the GUI version there is now a section where the user must provide both the cgenff rtf file and prm. The only parameters provided is the probe.prm. The users should add the files par_all36_cgenff.prm, par_all27_prot_lipid_na.inp, par_all36_lipid.prm, par_all36_prot.prm, par_all36_carb.prm, par_all36_na.prm, and toppar_water_ions.str in the additional parameters section to run druggability simulations. In the no-GUI version, cgenff_rtf and cgenff_prm are now required variables in order to use drugui_prepare. The user states the location of both the cgenff rtf and prm files to generate the probes and should provide the previous mention CHARMM files in the additional parameter list to run druggability simulations successfully. The cgenff rtf and prm files I have used are top_all36_cgenff.rtf and par_all36_cgenff.prm