TLDR: Difference between revisions
No edit summary |
|||
(36 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
TLDR (TLDR is a Ligand Discovery Resource, tldr.docking.org) is a web-based interface to molecular docking, cheminformatics and related tools. The system currently consists of a dozen or so apps. We plan to support dozens, perhaps a hundred. | |||
The system currently consists of a dozen apps. We plan to support dozens, perhaps a hundred | |||
== Advantages == | |||
* you don't need to install | |||
== | == Disadvantages == | ||
* limited control | |||
* limited by access to our servers | |||
* competition with other users | |||
Here we list the apps you can currently use, with usage notes. | |||
This is also called "Add TLDR Module" | |||
{{TOCright}} | |||
== Current available modules == | |||
* [[TLDR:arthorbatch|Arthorbatch]] | |||
* [[TLDR:bioisostere|Bioisostere]] | |||
* [[TLDR:bootstrap1|Bootstrap1]] | |||
* [[TLDR:bootstrap2|Bootstrap2]] | |||
* [[TLDR:dudez|DUDE-Z]] | |||
* [[TLDR:extrema|Extrema]] | |||
* [[TLDR:build3d38|Build3d38]] | |||
* [[TLDR:strain|Strain]] | |||
* [[TLDR:swbatch|Swbatch]] | |||
== Blaster == | == In Development == | ||
=== Blaster === | |||
The purpose of the blaster app is to prepare a receptor for docking, including some basic analysis. | The purpose of the blaster app is to prepare a receptor for docking, including some basic analysis. | ||
Line 53: | Line 48: | ||
Status: works. (equivalent of blastermaster.py) | Status: works. (equivalent of blastermaster.py) | ||
== Covalent == | |||
=== Covalent === | |||
Purpose: | Purpose: | ||
Line 70: | Line 64: | ||
Status: Works with special cases only. Nearly ready to use. If interested, ask jji for assistance. | Status: Works with special cases only. Nearly ready to use. If interested, ask jji for assistance. | ||
== Cluster == | === Cluster === | ||
Purpose: | Purpose: | ||
Line 84: | Line 78: | ||
Status: Works. | Status: Works. | ||
== Libanalysis == | === Libanalysis === | ||
Purpose: | Purpose: | ||
Line 114: | Line 94: | ||
Status: Not working yet | Status: Not working yet | ||
== Reaction == | === Reaction === | ||
Purpose: | Purpose: | ||
Line 132: | Line 112: | ||
* needs work to connect to reagents, reactions and schemes | * needs work to connect to reagents, reactions and schemes | ||
== Report2d == | === Report2d === | ||
Purpose: | Purpose: | ||
Line 146: | Line 126: | ||
Status: Not working yet | Status: Not working yet | ||
== Shape == | === Shape === | ||
Purpose: | Purpose: | ||
Line 162: | Line 142: | ||
Status: Not working yet | Status: Not working yet | ||
== ZINCbatch == | === ZINCbatch === | ||
Purpose: | Purpose: | ||
Line 177: | Line 157: | ||
= Technical info = | = Technical info = | ||
== Ben's info section == | |||
python environment is @ /nfs/soft/www/home/apps/tools18/envs/tldr-prod/bin/python3.9 | |||
tldr distribution packages are @ /nfs/soft/www/home/apps/tools18/dist | |||
=== How to open source code & make a change === | |||
1. unpack most recent distribution in dist folder to your preferred directory | |||
2. make changes to source code. this is left as an exercise for the reader | |||
3. once done, re-pack source code into tarball. if you want to change the version name, change the name of the source code's root directory & dist package- for organizational purposes | |||
4. copy the package back to the tldr dist directory- not strictly necessary, but again, for organizational purposes | |||
5. with the tldr python environment, pip install the package you just created | |||
* /nfs/soft/www/home/apps/tools18/envs/tldr-prod/bin/python3.9 -m pip install /nfs/soft/www/home/apps/tools18/dist/$YOUR_PACKAGE | |||
* this will uninstall the previous version- I haven't tried doing this while the server is live, but it should probably(?) be fine | |||
6. restart the tldr webserver on gimel2 | |||
* supervisorctl restart tldr | |||
=== Making changes to modules & scripts === | |||
modules are located @ /nfs/ex7/tldr-modules | |||
input files & parameters are defined by parameters.json within the module directory | |||
modules are fairly straightforward bash scripts that operate in a designated working directory created by tldr when a job is submitted | |||
job files are stored in /nfs/ex7/blaster/jobs/[0-9] | |||
the specific 0-9 directory the job directory is located in is based on the last digit of the tldr-provided job_id- these directories are striped across multiple disks | |||
within the job's working directory "results" is a special directory that will be shown to the user containing results | |||
=== TLDR database === | |||
psql -h mem2 -p 5432 -d blaster -U blasteruser | |||
can add new modules by adding to the job_types table | |||
set module private/public by modifying job_type_status_fk in this table | |||
== starting the server in single-threaded mode == | == starting the server in single-threaded mode == | ||
Line 192: | Line 219: | ||
7. Every job type has a "job_output" field, which currently stores an empty results.txt file which can be modified to do another action later. For now, the inputs uploaded, and the output file name specified by the user gets stored in the file system under the path that I mentioned in point 6. | 7. Every job type has a "job_output" field, which currently stores an empty results.txt file which can be modified to do another action later. For now, the inputs uploaded, and the output file name specified by the user gets stored in the file system under the path that I mentioned in point 6. | ||
[[Category: TLDR]] | |||
[[Category: Tools18]] |
Latest revision as of 06:21, 12 November 2024
TLDR (TLDR is a Ligand Discovery Resource, tldr.docking.org) is a web-based interface to molecular docking, cheminformatics and related tools. The system currently consists of a dozen or so apps. We plan to support dozens, perhaps a hundred.
Advantages
- you don't need to install
Disadvantages
- limited control
- limited by access to our servers
- competition with other users
Here we list the apps you can currently use, with usage notes.
This is also called "Add TLDR Module"
Current available modules
In Development
Blaster
The purpose of the blaster app is to prepare a receptor for docking, including some basic analysis.
This app requires:
- A structure for your receptor protein provided as a pdb file
- A binding site provided in one of the following ways:
1) Supply ligand in binding site 2) Provide binding site residues 3) Use a program to identify all potential binding sites. Choose which of the binding sites to test or test them all.
The app returns:
- dockfiles, which may be used for large library docking
- workfiles, which may be used for grid and sphere optimization.
The output of this app can be used by:
- asdf
- sef
- sdfafd
Status: works. (equivalent of blastermaster.py)
Covalent
Purpose:
This app requires:
- asdf
This app returns:
- asdf
The output of this app can be used by:
- adsfasdf
Status: Works with special cases only. Nearly ready to use. If interested, ask jji for assistance.
Cluster
Purpose:
This app requires:
- asdf
This app returns:
- asdf
The output of this app can be used by:
- adsfasdf
Status: Works.
Libanalysis
Purpose:
This app requires:
- asdf
This app returns:
- asdf
The output of this app can be used by:
- adsfasdf
Status: Not working yet
Reaction
Purpose:
This app requires:
- asdf
This app returns:
- asdf
The output of this app can be used by:
- adsfasdf
Status: Works at a basic level, with minor caveats.
- need to handle mwt and logP cutoff parametrically.
- needs work to handle millions of molecules
- needs work to connect to reagents, reactions and schemes
Report2d
Purpose:
This app requires:
- asdf
This app returns:
- asdf
The output of this app can be used by:
- adsfasdf
Status: Not working yet
Shape
Purpose:
Search for similar shape molecules for ligands
This app requires:
- asdf
This app returns:
- asdf
The output of this app can be used by:
- adsfasdf
Status: Not working yet
ZINCbatch
Purpose:
This app requires:
- asdf
This app returns:
- asdf
The output of this app can be used by:
- adsfasdf
Status: Not working yet
Technical info
Ben's info section
python environment is @ /nfs/soft/www/home/apps/tools18/envs/tldr-prod/bin/python3.9
tldr distribution packages are @ /nfs/soft/www/home/apps/tools18/dist
How to open source code & make a change
1. unpack most recent distribution in dist folder to your preferred directory
2. make changes to source code. this is left as an exercise for the reader
3. once done, re-pack source code into tarball. if you want to change the version name, change the name of the source code's root directory & dist package- for organizational purposes
4. copy the package back to the tldr dist directory- not strictly necessary, but again, for organizational purposes
5. with the tldr python environment, pip install the package you just created
* /nfs/soft/www/home/apps/tools18/envs/tldr-prod/bin/python3.9 -m pip install /nfs/soft/www/home/apps/tools18/dist/$YOUR_PACKAGE
* this will uninstall the previous version- I haven't tried doing this while the server is live, but it should probably(?) be fine
6. restart the tldr webserver on gimel2
* supervisorctl restart tldr
Making changes to modules & scripts
modules are located @ /nfs/ex7/tldr-modules
input files & parameters are defined by parameters.json within the module directory
modules are fairly straightforward bash scripts that operate in a designated working directory created by tldr when a job is submitted
job files are stored in /nfs/ex7/blaster/jobs/[0-9]
the specific 0-9 directory the job directory is located in is based on the last digit of the tldr-provided job_id- these directories are striped across multiple disks
within the job's working directory "results" is a special directory that will be shown to the user containing results
TLDR database
psql -h mem2 -p 5432 -d blaster -U blasteruser
can add new modules by adding to the job_types table set module private/public by modifying job_type_status_fk in this table
starting the server in single-threaded mode
source /mnt/nfs/work/chinzo/Projects/BlasterX_supritha/venv/bin/activate python code/DOCKBlaster/autoapp.py
How to add new module
Supported field types
For now, the model accepts "text_box", "check_box", "drop_down" , "radio_button", and so on
If "type" is "text_box", it can contain a text or number with a min and a max range. If there is a min and a max range, then they have to be mentioned as "value_type": "number", "value_range": {"min_value": 0.1,"max_value": 0.99} as in parameters.json for cluster. If "type" is "text_box" and "value_type" is "text", then it is a normal text box with no range or validations. 6. Every input mentioned under the key "inputs" has a field called "file_name", which the name by which the input file uploaded/filled by the user gets stored in the file system at /nfs/ex7/blaster/jobs/JobID%10/Jobname_jobID folder.
7. Every job type has a "job_output" field, which currently stores an empty results.txt file which can be modified to do another action later. For now, the inputs uploaded, and the output file name specified by the user gets stored in the file system under the path that I mentioned in point 6.