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.

[jamesmkrieger]

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

This still needs removing

[AnthonyBogetti]

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.

[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