DISI - User contributions [en]

User talk:Zack

2026-04-29T00:06:47Z

Khtang: Welcome!

'''Welcome to ''DISI''!'''
We hope you will contribute much and well.
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].
Again, welcome and have fun! [[User:Khtang|Khtang]] ([[User talk:Khtang|talk]]) 00:06, 29 April 2026 (UTC)

User:Zack

2026-04-29T00:06:47Z

Khtang: Creating user page for new user.

I am a grad student in BKS lab circa 2024 until TBD. If you are from the future, hello.

Install Schrodinger Suite in local computer

2026-03-13T03:11:58Z

Khtang: /* Command line */

== Download Schrodinger Suite file ==
You need to register an account for access. Our lab uses the Advanced Suite, please contact Schrodinger if you don't have access to this suite.
https://www.schrodinger.com/downloads/releases
You can also download them from BKS Cluster in
/nfs/soft/schrodinger/downloads

== Install ==
tar -xvf Advance....tar.gz
cd Advance....
./INSTALL

== Connect to bkslab's license server (MAKE SURE YOUR UCSF VPN IS ON if you are off campus)==
<b><big>Announcement: Schrodinger started implementing Schrodinger License Manager in place of the FlexNET license system for version 2024-2 and newer. You need to update the software to 2024-2 or newer.</big></b>

=== Suite version 2024-2 or newer ===
==== GUI Instruction for Mac/Windows ====
There should be a license popup when you start Maestro, if there isn't run this command below
export SCHRODINGER=/opt/schrodinger/suites<version>
$SCHRODINGER/run licensing_gui.py

Enter the information as following in the prompt

Hostname: bet2.compbio.ucsf.edu
Port: 53001

==== Command line ====
/opt/schrodinger/suites<version>/licadmin install -s bet2.compbio.ucsf.edu:53001

If you disabled the SCHRODINGER_LICENSE_MANAGER previously, you can enable it again
export SCHRODINGER=/opt/schrodinger/suites<version>
$SCHRODINGER/utilities/feature_flags -e SCHRODINGER_LICENSE_MANAGER

[[Category:Software]][[Category:Sysadmin]]

Install Schrodinger Suite in local computer

2026-03-13T03:11:39Z

Khtang: /* Connect to bkslab's license server (MAKE SURE YOUR UCSF VPN IS ON if you are off campus) */

Create new user

2026-01-29T00:27:36Z

Khtang:

===Identify a UID===
'''Check if a uid that is not taken by any other users'''. Start from 150**
On CentOS 6
$ getent passwd | grep 150**
On CentOS 7
$ id 150**

===Create users and superuser on the LDAP GUI:===
Make sure you turn on Switchy Omega
https://ds.ucsf.bkslab.org/ldapadmin/cmd.php

If you are seeing this error message
You cannot visit ds.ucsf.bkslab.org right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.
You will need to delete 'bkslab.org' domain from your 'Domain security policies' in Chrome
chrome://net-internals/#hsts

====To create a visitor: ====
Click OU=Visitors
Click Create new entry here
Select Generic: User Account
Fill in appropriate sections
-home dir should be /nfs/home/<username>
-password should be encrypted with sha512
-group should be visitors
Keep the uid LDAP suggested and edit in the one you picked later.

==== Create User's Home Directory ====
Log in as root on mem
$ sh /nfs/home/[create-visitor.sh/create-member.sh] <user_name>

=== Generate ssh for login ===
====Create ssh key ====
In the user's home directory's personal computer:
$ ssh keygen

==== Add user's public key to Portal ====
$ ssh s_khtang@portal.ucsf.bkslab.org
$ sudo -i
$ cd /opt/keys/user
$ vim <username>
Copy the .rsa_key.pub content into the file

==== Add user into Portal ====
On LDAP Admin
Choose ''' dc=bkslab,dc=org (17)''' > '''Group''' > '''Portal'''
Enter <username> in Add Value

==== Add user into SLURM ====
sudo sacctmgr create user name=<username> account=bks

=== Add s_ user in alpha ===
Since Alpha was created before ldap admin system, new user must be created individually on this machine.

Add the s_ user in
vim /etc/passwd
vim /etc/group

Change password
passwd s_<user>

[[Category: Ben]] [[Category:Sysadmin]]

Install Schrodinger Suite in local computer

2025-10-09T20:14:23Z

Khtang: /* Download Schrodinger Suite file */

== Download Schrodinger Suite file ==
You need to register an account for access. Our lab uses the Advanced Suite, please contact Schrodinger if you don't have access to this suite.
https://www.schrodinger.com/downloads/releases
You can also download them from BKS Cluster in
/nfs/soft/schrodinger/downloads

== Install ==
tar -xvf Advance....tar.gz
cd Advance....
./INSTALL

== Connect to bkslab's license server (MAKE SURE YOUR UCSF VPN IS ON if you are off campus)==
<b><big>Announcement: Schrodinger started implementing Schrodinger License Manager in place of the FlexNET license system for version 2024-2 and newer. You need to update the software to 2024-2 or newer.</big></b>

=== Suite version 2024-2 or newer ===
==== Instruction for Mac/Windows ====
There should be a license popup when you start Maestro, if there isn't run this command below
export SCHRODINGER=/opt/schrodinger/suites<version>
$SCHRODINGER/run licensing_gui.py

Enter the information as following in the prompt

Hostname: bet2.compbio.ucsf.edu
Port: 53001

If you disabled the SCHRODINGER_LICENSE_MANAGER previously, you can enable it again
export SCHRODINGER=/opt/schrodinger/suites<version>
$SCHRODINGER/utilities/feature_flags -e SCHRODINGER_LICENSE_MANAGER

[[Category:Software]][[Category:Sysadmin]]

Connect VSCode to cluster

2025-10-07T00:09:34Z

Khtang:

== Link ==
https://code.visualstudio.com/docs/remote/ssh
== Instruction ==
=== 1. Install extension ===
Go to 'Extension' tab in VSCode, look up 'Remote-SSH' and install
=== 2. Setup tunnel ===
To connect with VS code, forward the 22 port on the machine that you’d like to use using the following command
ssh -CL localhost:2222:epyc:22 <username>@portal3.ucsf.bkslab.org
=== 3. Setup configuration in Remote - SSH ===
- Click on the 'Connect to...' under Start in the 'Welcome' page

- Choose 'Connect to Host...' > '+ Add New SSH host'

- Type into the prompt this
ssh -p 2222 <username>@localhost

Connect VSCode to cluster

2025-10-07T00:09:19Z

Khtang:

Connect VSCode to cluster

2025-10-07T00:09:09Z

Khtang: Created page with "== Link == https://code.visualstudio.com/docs/remote/ssh == Instruction == === 1. Install extension === Go to 'Extension' tab in VSCode, look up 'Remote-SSH' and install === 2. Setup tunnel === To connect with VS code, forward the 22 port on the machine that you’d like to use using the following command ssh -CL localhost:2222:epyc:22 <username>@portal3.ucsf.bkslab.org === 3. Setup configuration in Remote - SSH === - Click on the 'Connect to...' under Start in the 'Welc..."

== Link ==
https://code.visualstudio.com/docs/remote/ssh
== Instruction ==
=== 1. Install extension ===
Go to 'Extension' tab in VSCode, look up 'Remote-SSH' and install
=== 2. Setup tunnel ===
To connect with VS code, forward the 22 port on the machine that you’d like to use using the following command
ssh -CL localhost:2222:epyc:22 <username>@portal3.ucsf.bkslab.org
=== 3. Setup configuration in Remote - SSH ===
- Click on the 'Connect to...' under Start in the 'Welcome' page
- Choose 'Connect to Host...' > '+ Add New SSH host'
- Type into the prompt this 'ssh -p 2222 <username>@localhost'

Looking up CAS

2025-09-12T23:47:55Z

Khtang:

CAS registry number is the unique identification number assigned by Chemical Abstract Service for every chemical substance identified in open scientific literature. Looking them up could be a tedious task.

There are several CAS lookup APIs services:
PUBMED : https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/[CAS]/property/CanonicalSMILES/JSON
CAS.org : https://commonchemistry.cas.org/api/detail?cas_rn=[CAS]

The script for fetching CAS using those API is in the folder '''/nfs/home/khtang/code/SMILES_lookup'''
source /nfs/soft/anaconda3/bin/activate ~khtang/.conda/envs/my-rdkit-env/
python /nfs/home/khtang/code/SMILES_lookup/lookup_CAS.py [input.xlsx] [output.xlsx]

Looking up CAS

2025-09-11T18:40:48Z

Khtang: Created page with "CAS registry number is the unique identification number assigned by Chemical Abstract Service for every chemical substance identified in open scientific literature. Looking them up could be a tedious task. There are several CAS lookup APIs services: PUBMED : https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/[CAS]/property/CanonicalSMILES/JSON CAS.org : https://commonchemistry.cas.org/api/detail?cas_rn=[CAS]"

User talk:Pseemann

2025-08-28T18:25:55Z

Khtang: Welcome!

User:Pseemann

2025-08-28T18:25:55Z

Khtang: Creating user page for new user.

I am a postdoctoral researcher from Germany and completed my PhD at FAU Erlangen-Nueremberg in Prof. Peter Gmeiner's laboratory. I am currently a member of the Shoichet Lab and my work focuses on symmetric docking approaches.

Manage Lab Websites

2025-08-19T00:44:28Z

Khtang: /* List of Websites */

We are trying to migrate all services to gitlab.
This page is perpetually out-of-date. Look at gitlab first. If not there, look below.

== List of Websites ==
Last updated on 08/18/2025
{| class="wikitable"
!Website
!Machine:Port
!Run on
!Hosted in (httpd/conf.d)
!Working
|-
|Amis: https://amis.docking.org/
|n-9-38:5066
|docker
|epyc
|Yes
|-
|Arthor: https://arthor.docking.org/
|nun, samekh, n-9-22; Port 8000
|Screen
|epyc
|Yes
|-
|BKSLab: https://www.bkslab.org/
|n-5-13:5002
|docker
|epyc
|Yes
|-
|Blaster: https://blaster.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Cartblanche22: https://cartblanche22.docking.org/
|n-9-22:5068
|docker
|epyc
|Yes
|-
|Covalent: http://covalent.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|DSF: https://dsf.docking.org/
|
|
|Vav (169.230.26.43)
|No (wrong website)
|-
|Duc: https://duc.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|Dud: https://dud.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Dude18: http://dude18.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|Dude: http://dude.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Dudez: http://dudez.docking.org/
|
|
|Files2 (169.230.75.3)
|Yes
|-
|Excipients: http://excipients.docking.org/
|gimel:8093
|Supervisord
|Vav (169.230.26.43)
|Yes
|-
|Gitlab: https://gitlab.docking.org/
|
|
|Files2 (169.230.75.3)
|No
|-
|HG: https://hg.docking.org/
|
|
|Files2 (169.230.75.3)
|No
|-
|IrwinLab: http://irwinlab.compbio.ucsf.edu/
|n-5-13:5004
|docker
|epyc
|Yes
|-
|Metabolite: http://metabolite.docking.org/
|
|
|Tau (169.230.26.43, can not be moved to files2)
|showing wrong website
|-
|Deepchemworkshop: http://deepchemworkshop.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Prices: http://prices.docking.org/
|gimel:5022
|
|Tau (169.230.26.43)
|No
|-
|Psicquic: http://psicquic.docking.org/
|
|
|Tau (169.230.26.43)
|Yes (broken???)
|-
|Reactor: http://reactor.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Transporters: http://transporters.ucsf.bkslab.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Sea16: http://sea16.docking.org/
|gimel:8086
|
|Files2 (169.230.75.3)
|Yes
|-
|SEC: http://sec.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Smallworld Public: http://sw.docking.org/
|abacus:5020
|screen
|epyc
|Yes
|-
|Smallworld Private: http://swp.docking.org/
|abacus:8080
|screen
|epyc
|Yes
|-
|Smallworld Super Private: http://swc.docking.org/
|abacus:5099
|screen
|epyc
|Yes
|-
|Stats: http://stats.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|No
|-
|Symp: http://symp.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|TLDR http://tldr.docking.org/
|epyc-A40:5011
|systemd
|Files2 (169.230.26.43)
|Yes
|-
|Tool-Selector: http://tool-selector.ucsf.bkslab.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Transportal: http://transportal.docking.org/
|n-9-23 : port 8123
|screen
|Vav (169.230.26.43)
|Yes
|-
|Upload: http://upload.docking.org/
|
|
|Tau (169.230.26.43)
|Yes
|-
|Zinc12: http://zinc12.docking.org/
|
|
|Tau (169.230.26.43, can not be moved to files2)
|Yes
|-
|-
|Zinc15: http://zinc15.docking.org/
|epyc2:5064
|docker
|epyc
|Yes
|-
|Zinc20: http://zinc20.docking.org/
|epyc2:5065
|docker
|epyc
|Yes
|-
|Chemistry Commons: https://commons.docking.org/
|epyc2:5010
|docker
|epyc
|Yes
|-
|}

== Restart Instructions after UPS==
=== For websites running on Docker ===
Login to machine using sudoer account.
$ sudo docker ps //to list all apps, including non-running
$ sudo docker start <name>

To restart a container
$ sudo docker restart <name>

=== For websites running on Screen ===

==== SEA ====
SEA is running on a screen on gimel

Become www on gimel
$ cd /nfs/soft/www/apps/seadev/
On bash shell
$ source tools/anaconda2/bin/activate sea16
$ cd work/seaware/seaware-academic
$ make SEAserver-stop-devel
$ make all
$ make SEAserver-start-devel
Ctrl A+D to detach screen

=== For websites running on Supervisord ===
==== Restart applications ====
* Become root on server the website runs on gimel
$ supervisorctl status //to list all of current running apps
$ supervisorctl restart <name>
i.e
$ supervisorctl restart bks-lab

==== Start Supervisord ====
$ supervisord

=== For websites running on Systemd ===
==== Restart applications ====
$ sudo systemctl restart <name>

<b>TLDR</b> is running on epyc-A40 and managed by systemd
$ sudo systemctl restart tldr

[[Category:Sysadmin]]
[[Category:Curator]]

Manage Lab Websites

2025-08-19T00:43:46Z

Khtang: /* Transportal */

We are trying to migrate all services to gitlab.
This page is perpetually out-of-date. Look at gitlab first. If not there, look below.

== List of Websites ==
Last updated on 11/10/2024
{| class="wikitable"
!Website
!Machine:Port
!Run on
!Hosted in (httpd/conf.d)
!Working
|-
|Amis: https://amis.docking.org/
|n-9-38:5066
|docker
|epyc
|Yes
|-
|Arthor: https://arthor.docking.org/
|nun, samekh, n-9-22; Port 8000
|Screen
|epyc
|Yes
|-
|BKSLab: http://www.bkslab.org/
|n-5-13:5002
|docker
|epyc
|Yes
|-
|Blaster: https://blaster.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Cartblanche22: https://cartblanche22.docking.org/
|n-9-22:5068
|docker
|epyc
|Yes
|-
|Covalent: http://covalent.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|DSF: https://dsf.docking.org/
|
|
|Vav (169.230.26.43)
|No (wrong website)
|-
|Duc: https://duc.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|Dud: https://dud.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Dude18: http://dude18.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|Dude: http://dude.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Dudez: http://dudez.docking.org/
|
|
|Files2 (169.230.75.3)
|Yes
|-
|Excipients: http://excipients.docking.org/
|gimel:8093
|Supervisord
|Vav (169.230.26.43)
|Yes
|-
|Gitlab: https://gitlab.docking.org/
|
|
|Files2 (169.230.75.3)
|No
|-
|HG: https://hg.docking.org/
|
|
|Files2 (169.230.75.3)
|No
|-
|IrwinLab: http://irwinlab.compbio.ucsf.edu/
|n-5-13:5004
|docker
|epyc
|Yes
|-
|Metabolite: http://metabolite.docking.org/
|
|
|Tau (169.230.26.43, can not be moved to files2)
|showing wrong website
|-
|Deepchemworkshop: http://deepchemworkshop.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Prices: http://prices.docking.org/
|gimel:5022
|
|Tau (169.230.26.43)
|No
|-
|Psicquic: http://psicquic.docking.org/
|
|
|Tau (169.230.26.43)
|Yes (broken???)
|-
|Reactor: http://reactor.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Transporters: http://transporters.ucsf.bkslab.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Sea16: http://sea16.docking.org/
|gimel:8086
|
|Files2 (169.230.75.3)
|Yes
|-
|SEC: http://sec.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Smallworld Public: http://sw.docking.org/
|abacus:5020
|screen
|epyc
|Yes
|-
|Smallworld Private: http://swp.docking.org/
|abacus:8080
|screen
|epyc
|Yes
|-
|Smallworld Super Private: http://swc.docking.org/
|abacus:5099
|screen
|epyc
|Yes
|-
|Stats: http://stats.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|No
|-
|Symp: http://symp.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|TLDR http://tldr.docking.org/
|epyc-A40:5011
|systemd
|Files2 (169.230.26.43)
|Yes
|-
|Tool-Selector: http://tool-selector.ucsf.bkslab.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Transportal: http://transportal.docking.org/
|n-9-23 : port 8123
|screen
|Vav (169.230.26.43)
|Yes
|-
|Upload: http://upload.docking.org/
|
|
|Tau (169.230.26.43)
|Yes
|-
|Zinc12: http://zinc12.docking.org/
|
|
|Tau (169.230.26.43, can not be moved to files2)
|Yes
|-
|-
|Zinc15: http://zinc15.docking.org/
|epyc2:5064
|docker
|epyc
|Yes
|-
|Zinc20: http://zinc20.docking.org/
|epyc2:5065
|docker
|epyc
|Yes
|-
|Chemistry Commons: https://commons.docking.org/
|epyc2:5010
|docker
|epyc
|Yes
|-
|}

== Restart Instructions after UPS==
=== For websites running on Docker ===
Login to machine using sudoer account.
$ sudo docker ps //to list all apps, including non-running
$ sudo docker start <name>

To restart a container
$ sudo docker restart <name>

=== For websites running on Screen ===

==== SEA ====
SEA is running on a screen on gimel

Become www on gimel
$ cd /nfs/soft/www/apps/seadev/
On bash shell
$ source tools/anaconda2/bin/activate sea16
$ cd work/seaware/seaware-academic
$ make SEAserver-stop-devel
$ make all
$ make SEAserver-start-devel
Ctrl A+D to detach screen

=== For websites running on Supervisord ===
==== Restart applications ====
* Become root on server the website runs on gimel
$ supervisorctl status //to list all of current running apps
$ supervisorctl restart <name>
i.e
$ supervisorctl restart bks-lab

==== Start Supervisord ====
$ supervisord

=== For websites running on Systemd ===
==== Restart applications ====
$ sudo systemctl restart <name>

<b>TLDR</b> is running on epyc-A40 and managed by systemd
$ sudo systemctl restart tldr

[[Category:Sysadmin]]
[[Category:Curator]]

Create new user

2025-08-18T22:49:11Z

Khtang: /* Create users and superuser on the LDAP GUI: */

===Identify a UID===
'''Check if a uid that is not taken by any other users'''. Start from 150**
On CentOS 6
$ getent passwd | grep 150**
On CentOS 7
$ id 150**

===Create users and superuser on the LDAP GUI:===
Make sure you turn on Switchy Omega
https://ds.ucsf.bkslab.org/ldapadmin/cmd.php

If you are seeing this error message
You cannot visit ds.ucsf.bkslab.org right now because the website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.
You will need to delete 'bkslab.org' domain from your 'Domain security policies' in Chrome
chrome://net-internals/#hsts

====To create a visitor: ====
Click OU=Visitors
Click Create new entry here
Select Generic: User Account
Fill in appropriate sections
-home dir should be /nfs/home/<username>
-password should be encrypted with sha512
-group should be visitors
Keep the uid LDAP suggested and edit in the one you picked later.

==== Create User's Home Directory ====
Log in as root on mem
$ sh /nfs/home/[create-visitor.sh/create-member.sh] <user_name>

=== Generate ssh for login ===
====Create ssh key ====
In the user's home directory's personal computer:
$ ssh keygen

==== Add user's public key to Portal ====
$ ssh s_khtang@portal.ucsf.bkslab.org
$ sudo -i
$ cd /opt/keys/user
$ vim <username>
Copy the .rsa_key.pub content into the file

==== Add user into Portal ====
On LDAP Admin
Choose ''' dc=bkslab,dc=org (17)''' > '''Group''' > '''Portal'''
Enter <username> in Add Value

=== Add s_ user in alpha ===
Since Alpha was created before ldap admin system, new user must be created individually on this machine.

Add the s_ user in
vim /etc/passwd
vim /etc/group

Change password
passwd s_<user>

[[Category: Ben]] [[Category:Sysadmin]]

How to dock in DOCK3.8

2025-08-08T19:37:08Z

Khtang: /* Example: Running a lot of docking jobs */

= IMPORTANT - UPDATED DOCUMENTATION =

https://wiki.docking.org/index.php/SUBDOCK_DOCK3.8

= OLD DOCUMENTATION =

How to dock in DOCK 3.8.0

Related page: Docking Analysis with DOCK 3.8

http://wiki.docking.org/index.php/Docking_Analysis_in_DOCK3.8

[[How to install DOCK 3.8]]

== Checkpointing & Restartability in DOCK3.8 ==

DOCK 3.8 can be interrupted safely and restarted, which allows more flexibility when submitting docking jobs.

For example, you could set QSUB_ARGS="-l s_rt=00:05:00 -l h_rt=00:07:00" (or SBATCH_ARGS="--time=00:07:00")
so that each docking job will only run for 5 minutes before being interrupted. The new subdock.bash script allows submitting the same set of jobs multiple times until they are all complete. A more pragmatic choice might be "-l s_rt=00:28:00 -l h_rt=00:30:00" to get the benefit of faster scheduling on wynton in the short.q.
Another advantage is that the job can be interrupted at any time on AWS and it will checkpoint and be restartable.

== Submitting Jobs/Running the Script ==

New subdock scripts are here:

$DOCKBASE/docking/submit/sge/subdock.bash
$DOCKBASE/docking/submit/slurm/subdock.bash

subdock.bash requires a number of environmental variables to be passed as arguments.

=== Required Arguments ===

==== INPUT_SOURCE ====

INPUT_SOURCE should be either:

a) A directory containing one or more db2.tgz files OR

b) A text file containing a list of paths to db2.tgz files

A db2.tgz file should be a tarred + gzipped archive (tar -czf archive.tgz) that contains one or more db2 or db2.gz files.

A job will be launched for each db2.tgz file in INPUT_SOURCE.

==== EXPORT_DEST ====

A directory on the NFS where you would like your docking output to end up. If the directory does not exist, the script will try to create it.

==== DOCKEXEC ====

An NFS path to a DOCK binary executable (NOT a wrapper script).

==== DOCKFILES ====

An NFS path to the dockfiles (INDOCK, spheres, receptor files, grids, etc.) being used for this docking run. Note that INDOCK is expected to be part of these files.

=== Optional Arguments ===

==== SHRTCACHE ====

The directory DOCK will perform it's work in. Files saved to this directory will be deleted once the docking job has concluded. By default this is /scratch. If /scratch is not available, change this to something else.

==== LONGCACHE ====

The directory DOCK will store files that are shared between multiple docking jobs. Files saved to this directory (dockexec and dockfiles) will persist on compute nodes until they are deleted by hand or an automated culling process. By default this directory is /scratch.

==== SBATCH_ARGS ====

Additional arguments to provide to slurm's sbatch, if using the slurm version of subdock.bash.

==== QSUB_ARGS ====

Additional arguments to provide to sge's qsub, if using the sge version of subdock.bash

==== SHRTCACHE_USE_ENV ====

At script runtime, have SHRTCACHE be set to the value of another environment variable, whose name is the value of SHRTCACHE_USE_ENV. This is useful for example if the scheduler sets up a directory for your job to perform work in, e.g Wynton's TMPDIR.

== Examples ==

BKS Example

<nowiki>
export INPUT_SOURCE=/path/to/example.in
export EXPORT_DEST=/path/to/output
export DOCKEXEC=$DOCKBASE/docking/DOCK/bin/dock64
export DOCKFILES=/path/to/dockfiles.example
export SHRTCACHE=/scratch
export LONGCACHE=/scratch
export SBATCH_ARGS="--time=02:00:00"

bash $DOCKBASE/docking/submit/slurm/subdock.bash
</nowiki>

Wynton Example

<nowiki>
export INPUT_SOURCE=/path/to/example.in
export EXPORT_DEST=/path/to/output
export DOCKEXEC=$DOCKBASE/docking/DOCK/bin/dock64
export DOCKFILES=/path/to/dockfiles.example
export SHRTCACHE_USE_ENV=TMPDIR
export LONGCACHE=/scratch
export QSUB_ARGS="-l s_rt=00:28:00 -l h_rt=00:30:00"

bash $DOCKBASE/docking/submit/sge/subdock.bash
</nowiki>

== Note on using SHRTCACHE and LONGCACHE ==

You should avoid using global networked directories for SHRTCACHE, these would be directories prefixed with /nfs/ on BKS and directories starting with /wynton/ on wynton. SHRTCACHE is used for writing out logs & job output in real time- a high latency network disk is inappropriate for this task. If running many jobs in parallel, there is a good chance that the network disk will be overloaded from all the jobs trying to send write requests simultaneously. I feel the difference between RAM, network directories and local directories is misunderstood, so I'll explain it with an analogy:

Imagine you just finished washing your clothes and you need to put them away.

Writing data to RAM (or /dev/shm) is like dropping them in a basket next to the washing machine.

Writing data to your local disk is like walking to your closet to put them away.

Writing data to a network disk is like walking to your neighbor's house and putting them away in his closet.

Now, networked disks don't perform much worse than local disks (your neighbor is just next door, after all), but what if everyone in the neighborhood put their stuff away in your neighbor's closet? For one there would be a line of people out his front door, meaning it would take you way longer to put away your clothes. Your neighbor also would probably not be happy with this arrangement, just like the wynton admins will not be happy if you set SHRTCACHE/LONGCACHE to a /wynton directory.

== Developer Example: Building your own db2.tgz files & Submitting jobs ==

What you need:
# One or more db2(.gz) files
# An nfs directory(s) to store:
## docking input/output
## dockfiles
## dock executable
# subdock & rundock scripts

Create a list of all the db2 files you want to run docking against. The example below is merely a suggestion, make the list in any way you please so long as each entry is a *full* path (relative to your working directory) to a db2 (or db2.gz) file.

<nowiki>
find $MY_DB2_SOURCE -type f -name "*.db2*" > my_db2_list</nowiki>

Split this list into reasonably sized chunks, our standard is 5000 but you can make them as large or small as you like. Do be careful about making the chunks larger- 5000 db2s is already quite heavy.

<nowiki>
>> split -a 3 --lines=5000 my_db2_list db2_chunk.

>> ls
db2_chunk_aaa
db2_chunk_aab
db2_chunk_aac
...
my_db2_list</nowiki>

Create a db2.tgz archive from each of these lists.

<nowiki>
for db2_chunk in db2_chunk.*; do
tar -czf $db2_chunk.db2.tgz --files-from $db2_chunk
done</nowiki>

If you already have premade db2.tgz files, for example from the zinc22 3D archive, start the tutorial here.

Create a list of every db2.tgz archive. Each job will evaluate one db2.tgz archive. Again, this example is a suggestion applicable only if you've been following the tutorial up to this point.

<nowiki>
find . -type f -name "db2_chunk.*.db2.tgz" > job_input_list</nowiki>

Now all you need to do is specify your docking parameters and launch the jobs. Set INPUT_SOURCE to be the job_input_list created in the previous step.

SGE

<nowiki>
export DOCKEXEC=<dock executable path>
export DOCKFILES=<dockfiles path>
export EXPORT_DEST=<output directory path>
# optional arguments for the job controller. Note that these arguments are examples and not the only configuration recommended
export QSUB_ARGS="-l s_rt=00:28:00 -l h_rt=00:30:00 -l mem_free=2G"

export INPUT_SOURCE=job_input_list

bash <scripts directory>/sge/subdock.bash</nowiki>

SLURM

<nowiki>
export DOCKEXEC=<dock executable path>
export DOCKFILES=<dockfiles path>
export EXPORT_DEST=<output directory path>
export SBATCH_ARGS="--time=00:30:00 --mem-per-cpu=2G"

export INPUT_SOURCE=job_input_list

bash <scripts directory>/slurm/subdock.bash</nowiki>

=== Large Docking Jobs ===

If your list of db2.tgz files is very large you may want to further split it. Each db2.tgz file in the job_input_list represents a job submitted to the queue, and often there is a limit on how many jobs can be queued at once.

In order to avoid this problem, we will need an automatic solution to split up our job_input_list and submit batches of jobs only when there is space left in the queue.

For example, imagine we want to submit in batches of 10,000 and limit total jobs to 50,000 (with a package size of 5000 this is 250M molecules in the queue maximum, submitting 50M at a time). The example I have shows how you would do this in slurm.

<nowiki>
#!/bin/bash
### submit_all_slurm.bash

BINDIR=$(dirname $0)

BATCH_SIZE=10000
MAX_QUEUED=50000

# the script is more portable if we provide the various parameters as arguments instead of hard-coding
INPUT_LIST=$1
BASE_EXPORT_DEST=$2 # this is the directory where further subdirectories will be created that contain docking job results
export DOCKEXEC=$3
export DOCKFILES=$4

# we can use our EXPORT_DEST as staging grounds for our input
mkdir -p $BASE_EXPORT_DEST/input

split --lines=$BATCH_SIZE -a 3 -n $INPUT_LIST $BASE_EXPORT_DEST/input/job_input.

export SBATCH_ARGS="--time=00:30:00 --mem-per-cpu=2G -J dock"

for job_input in $BASE_EXPORT_DEST/input/job_input.*; do

export INPUT_SOURCE=$job_input
input_num=$(printf $job_input | cut -d'.' -f2) # get the suffix of the split filename

export EXPORT_DEST=$BASE_EXPORT_DEST/$input_num

# loop forever
while [ -z ]; do

# counts how many jobs in total are pending or running on this user
njobs=$(squeue -u $(whoami) -h -t pending,running -r | wc -l)
# if you want to instead set a limit on how many *dock* jobs are pending or running you would just run the command through a filter
# njobs=$(squeue -u $(whoami) -h -t pending,running -r | grep "dock" | wc -l)

if [ $njobs -lt $((MAX_QUEUED-BATCH_SIZE)) ]; then
break
fi

sleep 10
done

# the slurm subdock and rundock scripts need to live next to this script in a directory named "slurm"
bash $BINDIR/slurm/subdock.bash
done</nowiki>

This script will run until all jobs are submitted, so for very large jobs you may want to keep the process alive in a screen.

== Tip: Using Wynton's $TMPDIR ==

<b>Doing this with SHRTCACHE_USE_ENV</b>

Before you run subdock, simply export the SHRTCACHE_USE_ENV option.

<nowiki>
export SHRTCACHE_USE_ENV=TMPDIR</nowiki>

This will cause the script to use the $TMPDIR variable for SHRTCACHE.

== Example: Running a lot of docking jobs ==

* see [[ZINC22:Current status]] for more info about where ZINC can be found.

* 1. set up sdi files
mkdir sdi
export sdi=sdi
ls /wynton/group/bks/zinc-22/H19/H19P0??/*.db2.tgz > $sdi/h19p0.in
ls /wynton/group/bks/zinc-22/H19/H19P1??/*.db2.tgz > $sdi/h19p1.in
ls /wynton/group/bks/zinc-22/H19/H19P2??/*.db2.tgz > $sdi/h19p2.in
ls /wynton/group/bks/zinc-22/H19/H19P3??/*.db2.tgz > $sdi/h19p3.in
and so on

* 2. set up INDOCK and dockfiles. rename dockfiles to dockfiles.$indockhash. On some nodes, the shasum command is called by sha1sum. Ultimately, renaming the dockfiles to a unique dockfiles is key.

Note: As of 3/19/2021, this is no longer necessary

bash
indockhash=$(cat INDOCK | shasum | awk '{print substr($1, 1, 12)}')

* 3. super script:

<nowiki>
export DOCKBASE=/wynton/group/bks/work/jji/DOCK
export DOCKFILES=$WORKDIR/dockfiles.21751f1bb16b
export DOCKEXEC=$DOCKBASE/docking/DOCK/bin/dock64
#export SHRTCACHE=/scratch # default
export SHRTCACHE=/scratch
export LONGCACHE=/scratch
export QSUB_ARGS="-l s_rt=00:28:00 -l h_rt=00:30:00 -l mem_free=2G"

for i in sdi/*.in ; do
export k=$(basename $i .in)
echo k $k
export INPUT_SOURCE=$PWD/$i
export EXPORT_DEST=$PWD/output/$k
$DOCKBASE/docking/submit/sge/subdock.bash
done
</nowiki>

# 3a. to run for first time
sh super

# 4. how to restart (to make sure complete, iterate until complete)

sh super

# 5. check which output is valid (and broken or incomplete output)

# 6. extract all blazing fast

# 7. extract mol2

more soon, under active development, Jan 28.

== Appendix: Docking mono-cations of ZINC22 with DOCK3.8 on Wynton ==
Added by Ying 3/10/2021

To use: copy and paste the code section into terminal. '''Note to change the path where labelled with ''CHANGE this'' '''

* '''set up the folder to run docking. '''
Path to my example: /wynton/home/shoichetlab/yingyang/work/5HT-5a/10_AL-dock/zinc22_3d_build_3-10-2021
mkdir zinc22_3d_build_3-10-2021
cd zinc22_3d_build_3-10-2021

* '''copy INDOCK into dockfiles folder, and transfer to the created folder'''
cp INDOCK dockfiles
scp -r INDOCK dockfiles dt2.wynton.ucsf.edu:/path_to_created_folder

* '''get sdi of monocations of already built ZINC22 (<= H26 heavy atom count)'''
Modify to your own need...
<nowiki>
mkdir sdi

foreach i (`seq 4 1 26`)
set hac = `printf "H%02d" $i `
echo $i $hac

touch sdi/${hac}.sdi
# CHANGE this: to your need
foreach tgz (`ls /wynton/group/bks/zinc-22*/${hac}/${hac}[PM]???/*-O*.db2.tgz`)
ls $tgz
echo $tgz >> sdi/${hac}.sdi
end
end
</nowiki>

* '''rename the dockfiles directory'''

Note: As of 3/19/2021 this step is no longer necessary

indockhash=$(cat INDOCK | sha1sum | awk '{print substr($1, 1, 12)}')
mv dockfiles dockfiles.${indockhash}

* '''write and run the super_run.sh'''
<nowiki>
cat <<EOF > super_run.sh
export DOCKBASE=/wynton/group/bks/soft/DOCK-3.8.0.1
export DOCKEXEC=\$DOCKBASE/docking/DOCK/bin/dock64

# CHANGE here: path to the previously renamed dockfiles.\${indockhash}
### Note: as of 3/19/2021 renaming your dockfiles is no longer necessary
export DOCKFILES=/wynton/group/bks/work/yingyang/5HT-5a/10_AL-dock/zinc22_3d_build_3-10-2021/dockfiles.${indockhash}
export SHRTCACHE=/scratch
export LONGCACHE=/scratch
export QSUB_ARGS="-l s_rt=00:28:00 -l h_rt=00:30:00 -l mem_free=2G"

for i in sdi/*.sdi ; do
export k=\$(basename \$i .sdi)
echo k \$k
export INPUT_SOURCE=$PWD/\$i
export EXPORT_DEST=$PWD/output/\$k
\$DOCKBASE/docking/submit/sge/subdock.bash
done
EOF

bash super_run.sh
</nowiki>

* '''keep submitting the super_run script until all db2s have been docked. '''
After all docking jobs finish, check the output. If no weird error, we can use a while loop to restart.
<nowiki>
while true
do
export jobN=$(qstat | grep -c 'rundock')
if [[ $jobN -gt 0 ]]
then
sleep 60
else
bash super_run.sh
fi
done
</nowiki>
When no new job is going to be submitted, use Ctrl+c to exit the while loop.

* '''extract scores from output. '''
<nowiki>
cat << EOF > qsub_extract.csh
#\$ -S /bin/csh
#\$ -cwd
#\$ -pe smp 1
#\$ -l mem_free=100G
#\$ -l scratch=100G
#\$ -l h_rt=50:00:00
#\$ -j yes
#\$ -o extract_all.out

hostname
date

setenv DOCKBASE /wynton/group/bks/soft/DOCK-3.8.0.1

setenv dir_in $PWD

if ! (-d \$TMPDIR ) then
if (-d /scratch ) then
setenv TMPDIR /scratch/\$USER
else
setenv TMPDIR /tmp/\$USER
endif
mkdir -p \$TMPDIR
endif
pushd \$TMPDIR

ls -d \${dir_in}/output/*/*/ > dirlist

python \$DOCKBASE/analysis/extract_all_blazing_fast.py \
dirlist extract_all.txt -30

mv extract_all.* \$dir_in

popd

echo '---job info---'
qstat -j \$JOB_ID
echo '---complete---'
EOF

qsub qsub_extract.csh
</nowiki>

Another way is to run the command from the login node (Not recommended since sorting utilizes large memory)
ls -d output/*/*/ > dirlist
python $DOCKBASE/analysis/extract_all_blazing_fast.py dirlist extract_all.txt -20

* '''get poses in parallel'''
<nowiki>
set score_file = $PWD/extract_all.sort.uniq.txt
set score_name = ${score_file:t:r}
set fileprefix = 'tmp_'
set number_per_file = 5000

set workdir = $PWD/${score_name}_poses
mkdir -p $workdir
cd $workdir

split --lines=$number_per_file --suffix-length=4 \
-d $score_file ${fileprefix}

set num = ` ls ${fileprefix}* | wc -l `
echo "Number of score files to process:" $num

cat << EOF > qsub_poses.csh
#\$ -S /bin/csh
#\$ -cwd
#\$ -j yes
#\$ -pe smp 1
#\$ -l mem_free=5G
#\$ -l scratch=20G
#\$ -l h_rt=25:00:00
#\$ -t 1-$num

hostname
date

setenv DOCKBASE /wynton/group/bks/soft/DOCK-3.8.0.1

set list = \` ls \$PWD/${fileprefix}* \`
set MOL = "\${list[\$SGE_TASK_ID]}"
set name = \${MOL:t:r}

python2 $DOCKBASE/analysis/getposes_blazing_faster.py \
"" \${MOL} $number_per_file poses_\${name}.mol2 test.mol2.gz

EOF

qsub qsub_poses.csh
cd ../
</nowiki>

* '''Post-processing...'''

[[Category:DOCK 3.8]]

How to dock in DOCK3.8

2025-08-08T19:36:25Z

Khtang: /* Examples */

= IMPORTANT - UPDATED DOCUMENTATION =

https://wiki.docking.org/index.php/SUBDOCK_DOCK3.8

= OLD DOCUMENTATION =

How to dock in DOCK 3.8.0

Related page: Docking Analysis with DOCK 3.8

http://wiki.docking.org/index.php/Docking_Analysis_in_DOCK3.8

[[How to install DOCK 3.8]]

== Checkpointing & Restartability in DOCK3.8 ==

DOCK 3.8 can be interrupted safely and restarted, which allows more flexibility when submitting docking jobs.

For example, you could set QSUB_ARGS="-l s_rt=00:05:00 -l h_rt=00:07:00" (or SBATCH_ARGS="--time=00:07:00")
so that each docking job will only run for 5 minutes before being interrupted. The new subdock.bash script allows submitting the same set of jobs multiple times until they are all complete. A more pragmatic choice might be "-l s_rt=00:28:00 -l h_rt=00:30:00" to get the benefit of faster scheduling on wynton in the short.q.
Another advantage is that the job can be interrupted at any time on AWS and it will checkpoint and be restartable.

== Submitting Jobs/Running the Script ==

New subdock scripts are here:

$DOCKBASE/docking/submit/sge/subdock.bash
$DOCKBASE/docking/submit/slurm/subdock.bash

subdock.bash requires a number of environmental variables to be passed as arguments.

=== Required Arguments ===

==== INPUT_SOURCE ====

INPUT_SOURCE should be either:

a) A directory containing one or more db2.tgz files OR

b) A text file containing a list of paths to db2.tgz files

A db2.tgz file should be a tarred + gzipped archive (tar -czf archive.tgz) that contains one or more db2 or db2.gz files.

A job will be launched for each db2.tgz file in INPUT_SOURCE.

==== EXPORT_DEST ====

A directory on the NFS where you would like your docking output to end up. If the directory does not exist, the script will try to create it.

==== DOCKEXEC ====

An NFS path to a DOCK binary executable (NOT a wrapper script).

==== DOCKFILES ====

An NFS path to the dockfiles (INDOCK, spheres, receptor files, grids, etc.) being used for this docking run. Note that INDOCK is expected to be part of these files.

=== Optional Arguments ===

==== SHRTCACHE ====

The directory DOCK will perform it's work in. Files saved to this directory will be deleted once the docking job has concluded. By default this is /scratch. If /scratch is not available, change this to something else.

==== LONGCACHE ====

The directory DOCK will store files that are shared between multiple docking jobs. Files saved to this directory (dockexec and dockfiles) will persist on compute nodes until they are deleted by hand or an automated culling process. By default this directory is /scratch.

==== SBATCH_ARGS ====

Additional arguments to provide to slurm's sbatch, if using the slurm version of subdock.bash.

==== QSUB_ARGS ====

Additional arguments to provide to sge's qsub, if using the sge version of subdock.bash

==== SHRTCACHE_USE_ENV ====

At script runtime, have SHRTCACHE be set to the value of another environment variable, whose name is the value of SHRTCACHE_USE_ENV. This is useful for example if the scheduler sets up a directory for your job to perform work in, e.g Wynton's TMPDIR.

== Examples ==

BKS Example

<nowiki>
export INPUT_SOURCE=/path/to/example.in
export EXPORT_DEST=/path/to/output
export DOCKEXEC=$DOCKBASE/docking/DOCK/bin/dock64
export DOCKFILES=/path/to/dockfiles.example
export SHRTCACHE=/scratch
export LONGCACHE=/scratch
export SBATCH_ARGS="--time=02:00:00"

bash $DOCKBASE/docking/submit/slurm/subdock.bash
</nowiki>

Wynton Example

<nowiki>
export INPUT_SOURCE=/path/to/example.in
export EXPORT_DEST=/path/to/output
export DOCKEXEC=$DOCKBASE/docking/DOCK/bin/dock64
export DOCKFILES=/path/to/dockfiles.example
export SHRTCACHE_USE_ENV=TMPDIR
export LONGCACHE=/scratch
export QSUB_ARGS="-l s_rt=00:28:00 -l h_rt=00:30:00"

bash $DOCKBASE/docking/submit/sge/subdock.bash
</nowiki>

== Note on using SHRTCACHE and LONGCACHE ==

You should avoid using global networked directories for SHRTCACHE, these would be directories prefixed with /nfs/ on BKS and directories starting with /wynton/ on wynton. SHRTCACHE is used for writing out logs & job output in real time- a high latency network disk is inappropriate for this task. If running many jobs in parallel, there is a good chance that the network disk will be overloaded from all the jobs trying to send write requests simultaneously. I feel the difference between RAM, network directories and local directories is misunderstood, so I'll explain it with an analogy:

Imagine you just finished washing your clothes and you need to put them away.

Writing data to RAM (or /dev/shm) is like dropping them in a basket next to the washing machine.

Writing data to your local disk is like walking to your closet to put them away.

Writing data to a network disk is like walking to your neighbor's house and putting them away in his closet.

Now, networked disks don't perform much worse than local disks (your neighbor is just next door, after all), but what if everyone in the neighborhood put their stuff away in your neighbor's closet? For one there would be a line of people out his front door, meaning it would take you way longer to put away your clothes. Your neighbor also would probably not be happy with this arrangement, just like the wynton admins will not be happy if you set SHRTCACHE/LONGCACHE to a /wynton directory.

== Developer Example: Building your own db2.tgz files & Submitting jobs ==

What you need:
# One or more db2(.gz) files
# An nfs directory(s) to store:
## docking input/output
## dockfiles
## dock executable
# subdock & rundock scripts

Create a list of all the db2 files you want to run docking against. The example below is merely a suggestion, make the list in any way you please so long as each entry is a *full* path (relative to your working directory) to a db2 (or db2.gz) file.

<nowiki>
find $MY_DB2_SOURCE -type f -name "*.db2*" > my_db2_list</nowiki>

Split this list into reasonably sized chunks, our standard is 5000 but you can make them as large or small as you like. Do be careful about making the chunks larger- 5000 db2s is already quite heavy.

<nowiki>
>> split -a 3 --lines=5000 my_db2_list db2_chunk.

>> ls
db2_chunk_aaa
db2_chunk_aab
db2_chunk_aac
...
my_db2_list</nowiki>

Create a db2.tgz archive from each of these lists.

<nowiki>
for db2_chunk in db2_chunk.*; do
tar -czf $db2_chunk.db2.tgz --files-from $db2_chunk
done</nowiki>

If you already have premade db2.tgz files, for example from the zinc22 3D archive, start the tutorial here.

Create a list of every db2.tgz archive. Each job will evaluate one db2.tgz archive. Again, this example is a suggestion applicable only if you've been following the tutorial up to this point.

<nowiki>
find . -type f -name "db2_chunk.*.db2.tgz" > job_input_list</nowiki>

Now all you need to do is specify your docking parameters and launch the jobs. Set INPUT_SOURCE to be the job_input_list created in the previous step.

SGE

<nowiki>
export DOCKEXEC=<dock executable path>
export DOCKFILES=<dockfiles path>
export EXPORT_DEST=<output directory path>
# optional arguments for the job controller. Note that these arguments are examples and not the only configuration recommended
export QSUB_ARGS="-l s_rt=00:28:00 -l h_rt=00:30:00 -l mem_free=2G"

export INPUT_SOURCE=job_input_list

bash <scripts directory>/sge/subdock.bash</nowiki>

SLURM

<nowiki>
export DOCKEXEC=<dock executable path>
export DOCKFILES=<dockfiles path>
export EXPORT_DEST=<output directory path>
export SBATCH_ARGS="--time=00:30:00 --mem-per-cpu=2G"

export INPUT_SOURCE=job_input_list

bash <scripts directory>/slurm/subdock.bash</nowiki>

=== Large Docking Jobs ===

If your list of db2.tgz files is very large you may want to further split it. Each db2.tgz file in the job_input_list represents a job submitted to the queue, and often there is a limit on how many jobs can be queued at once.

In order to avoid this problem, we will need an automatic solution to split up our job_input_list and submit batches of jobs only when there is space left in the queue.

For example, imagine we want to submit in batches of 10,000 and limit total jobs to 50,000 (with a package size of 5000 this is 250M molecules in the queue maximum, submitting 50M at a time). The example I have shows how you would do this in slurm.

<nowiki>
#!/bin/bash
### submit_all_slurm.bash

BINDIR=$(dirname $0)

BATCH_SIZE=10000
MAX_QUEUED=50000

# the script is more portable if we provide the various parameters as arguments instead of hard-coding
INPUT_LIST=$1
BASE_EXPORT_DEST=$2 # this is the directory where further subdirectories will be created that contain docking job results
export DOCKEXEC=$3
export DOCKFILES=$4

# we can use our EXPORT_DEST as staging grounds for our input
mkdir -p $BASE_EXPORT_DEST/input

split --lines=$BATCH_SIZE -a 3 -n $INPUT_LIST $BASE_EXPORT_DEST/input/job_input.

export SBATCH_ARGS="--time=00:30:00 --mem-per-cpu=2G -J dock"

for job_input in $BASE_EXPORT_DEST/input/job_input.*; do

export INPUT_SOURCE=$job_input
input_num=$(printf $job_input | cut -d'.' -f2) # get the suffix of the split filename

export EXPORT_DEST=$BASE_EXPORT_DEST/$input_num

# loop forever
while [ -z ]; do

# counts how many jobs in total are pending or running on this user
njobs=$(squeue -u $(whoami) -h -t pending,running -r | wc -l)
# if you want to instead set a limit on how many *dock* jobs are pending or running you would just run the command through a filter
# njobs=$(squeue -u $(whoami) -h -t pending,running -r | grep "dock" | wc -l)

if [ $njobs -lt $((MAX_QUEUED-BATCH_SIZE)) ]; then
break
fi

sleep 10
done

# the slurm subdock and rundock scripts need to live next to this script in a directory named "slurm"
bash $BINDIR/slurm/subdock.bash
done</nowiki>

This script will run until all jobs are submitted, so for very large jobs you may want to keep the process alive in a screen.

== Tip: Using Wynton's $TMPDIR ==

<b>Doing this with SHRTCACHE_USE_ENV</b>

Before you run subdock, simply export the SHRTCACHE_USE_ENV option.

<nowiki>
export SHRTCACHE_USE_ENV=TMPDIR</nowiki>

This will cause the script to use the $TMPDIR variable for SHRTCACHE.

== Example: Running a lot of docking jobs ==

* see [[ZINC22:Current status]] for more info about where ZINC can be found.

* 1. set up sdi files
mkdir sdi
export sdi=sdi
ls /wynton/group/bks/zinc-22/H19/H19P0??/*.db2.tgz > $sdi/h19p0.in
ls /wynton/group/bks/zinc-22/H19/H19P1??/*.db2.tgz > $sdi/h19p1.in
ls /wynton/group/bks/zinc-22/H19/H19P2??/*.db2.tgz > $sdi/h19p2.in
ls /wynton/group/bks/zinc-22/H19/H19P3??/*.db2.tgz > $sdi/h19p3.in
and so on

* 2. set up INDOCK and dockfiles. rename dockfiles to dockfiles.$indockhash. On some nodes, the shasum command is called by sha1sum. Ultimately, renaming the dockfiles to a unique dockfiles is key.

Note: As of 3/19/2021, this is no longer necessary

bash
indockhash=$(cat INDOCK | shasum | awk '{print substr($1, 1, 12)}')

* 3. super script:

<nowiki>
export DOCKBASE=/wynton/group/bks/work/jji/DOCK
export DOCKFILES=$WORKDIR/dockfiles.21751f1bb16b
export DOCKEXEC=$DOCKBASE/docking/DOCK/bin/dock64
#export SHRTCACHE=/dev/shm # default
export SHRTCACHE=/scratch
export LONGCACHE=/scratch
export QSUB_ARGS="-l s_rt=00:28:00 -l h_rt=00:30:00 -l mem_free=2G"

for i in sdi/*.in ; do
export k=$(basename $i .in)
echo k $k
export INPUT_SOURCE=$PWD/$i
export EXPORT_DEST=$PWD/output/$k
$DOCKBASE/docking/submit/sge/subdock.bash
done
</nowiki>

# 3a. to run for first time
sh super

# 4. how to restart (to make sure complete, iterate until complete)

sh super

# 5. check which output is valid (and broken or incomplete output)

# 6. extract all blazing fast

# 7. extract mol2

more soon, under active development, Jan 28.

== Appendix: Docking mono-cations of ZINC22 with DOCK3.8 on Wynton ==
Added by Ying 3/10/2021

To use: copy and paste the code section into terminal. '''Note to change the path where labelled with ''CHANGE this'' '''

* '''set up the folder to run docking. '''
Path to my example: /wynton/home/shoichetlab/yingyang/work/5HT-5a/10_AL-dock/zinc22_3d_build_3-10-2021
mkdir zinc22_3d_build_3-10-2021
cd zinc22_3d_build_3-10-2021

* '''copy INDOCK into dockfiles folder, and transfer to the created folder'''
cp INDOCK dockfiles
scp -r INDOCK dockfiles dt2.wynton.ucsf.edu:/path_to_created_folder

* '''get sdi of monocations of already built ZINC22 (<= H26 heavy atom count)'''
Modify to your own need...
<nowiki>
mkdir sdi

foreach i (`seq 4 1 26`)
set hac = `printf "H%02d" $i `
echo $i $hac

touch sdi/${hac}.sdi
# CHANGE this: to your need
foreach tgz (`ls /wynton/group/bks/zinc-22*/${hac}/${hac}[PM]???/*-O*.db2.tgz`)
ls $tgz
echo $tgz >> sdi/${hac}.sdi
end
end
</nowiki>

* '''rename the dockfiles directory'''

Note: As of 3/19/2021 this step is no longer necessary

indockhash=$(cat INDOCK | sha1sum | awk '{print substr($1, 1, 12)}')
mv dockfiles dockfiles.${indockhash}

* '''write and run the super_run.sh'''
<nowiki>
cat <<EOF > super_run.sh
export DOCKBASE=/wynton/group/bks/soft/DOCK-3.8.0.1
export DOCKEXEC=\$DOCKBASE/docking/DOCK/bin/dock64

# CHANGE here: path to the previously renamed dockfiles.\${indockhash}
### Note: as of 3/19/2021 renaming your dockfiles is no longer necessary
export DOCKFILES=/wynton/group/bks/work/yingyang/5HT-5a/10_AL-dock/zinc22_3d_build_3-10-2021/dockfiles.${indockhash}
export SHRTCACHE=/scratch
export LONGCACHE=/scratch
export QSUB_ARGS="-l s_rt=00:28:00 -l h_rt=00:30:00 -l mem_free=2G"

for i in sdi/*.sdi ; do
export k=\$(basename \$i .sdi)
echo k \$k
export INPUT_SOURCE=$PWD/\$i
export EXPORT_DEST=$PWD/output/\$k
\$DOCKBASE/docking/submit/sge/subdock.bash
done
EOF

bash super_run.sh
</nowiki>

* '''keep submitting the super_run script until all db2s have been docked. '''
After all docking jobs finish, check the output. If no weird error, we can use a while loop to restart.
<nowiki>
while true
do
export jobN=$(qstat | grep -c 'rundock')
if [[ $jobN -gt 0 ]]
then
sleep 60
else
bash super_run.sh
fi
done
</nowiki>
When no new job is going to be submitted, use Ctrl+c to exit the while loop.

* '''extract scores from output. '''
<nowiki>
cat << EOF > qsub_extract.csh
#\$ -S /bin/csh
#\$ -cwd
#\$ -pe smp 1
#\$ -l mem_free=100G
#\$ -l scratch=100G
#\$ -l h_rt=50:00:00
#\$ -j yes
#\$ -o extract_all.out

hostname
date

setenv DOCKBASE /wynton/group/bks/soft/DOCK-3.8.0.1

setenv dir_in $PWD

if ! (-d \$TMPDIR ) then
if (-d /scratch ) then
setenv TMPDIR /scratch/\$USER
else
setenv TMPDIR /tmp/\$USER
endif
mkdir -p \$TMPDIR
endif
pushd \$TMPDIR

ls -d \${dir_in}/output/*/*/ > dirlist

python \$DOCKBASE/analysis/extract_all_blazing_fast.py \
dirlist extract_all.txt -30

mv extract_all.* \$dir_in

popd

echo '---job info---'
qstat -j \$JOB_ID
echo '---complete---'
EOF

qsub qsub_extract.csh
</nowiki>

Another way is to run the command from the login node (Not recommended since sorting utilizes large memory)
ls -d output/*/*/ > dirlist
python $DOCKBASE/analysis/extract_all_blazing_fast.py dirlist extract_all.txt -20

* '''get poses in parallel'''
<nowiki>
set score_file = $PWD/extract_all.sort.uniq.txt
set score_name = ${score_file:t:r}
set fileprefix = 'tmp_'
set number_per_file = 5000

set workdir = $PWD/${score_name}_poses
mkdir -p $workdir
cd $workdir

split --lines=$number_per_file --suffix-length=4 \
-d $score_file ${fileprefix}

set num = ` ls ${fileprefix}* | wc -l `
echo "Number of score files to process:" $num

cat << EOF > qsub_poses.csh
#\$ -S /bin/csh
#\$ -cwd
#\$ -j yes
#\$ -pe smp 1
#\$ -l mem_free=5G
#\$ -l scratch=20G
#\$ -l h_rt=25:00:00
#\$ -t 1-$num

hostname
date

setenv DOCKBASE /wynton/group/bks/soft/DOCK-3.8.0.1

set list = \` ls \$PWD/${fileprefix}* \`
set MOL = "\${list[\$SGE_TASK_ID]}"
set name = \${MOL:t:r}

python2 $DOCKBASE/analysis/getposes_blazing_faster.py \
"" \${MOL} $number_per_file poses_\${name}.mol2 test.mol2.gz

EOF

qsub qsub_poses.csh
cd ../
</nowiki>

* '''Post-processing...'''

[[Category:DOCK 3.8]]

2025-01-14T07:52:12Z

Khtang:

Here is quick guide to add your script into [[TLDR]] interface
=== Scripts ===

=== Add job type into psql table ===
*Access the database
$ psql -h mem2 -d blaster -U blasteruser

*Look for the next available index on job_types table
blaster=> select * from job_types order by job_type_id;
You will see table like this
job_type_id | last_updated | short_name
-------------+----------------------------+-------------------
1 | 2018-10-05 00:00:00 | analog
2 | 2018-10-05 00:00:00 | blaster
3 | 2018-10-05 00:00:00 | blasterpdb
4 | 2018-10-05 00:00:00 | build2d
5 | 2018-10-05 00:00:00 | build3d
6 | 2018-10-05 00:00:00 | cluster
7 | 2018-10-05 00:00:00 | covalent
8 | 2018-10-05 00:00:00 | dude
9 | 2018-10-05 00:00:00 | libanalysis
10 | 2018-10-05 00:00:00 | reaction
11 | 2018-10-05 00:00:00 | sea
12 | 2018-10-05 00:00:00 | threec
13 | 2018-10-05 00:00:00 | transform
14 | 2018-10-05 00:00:00 | zincbatch
15 | 2018-12-01 18:47:34 | cluster_molecules

* Insert new job type (Please be extra careful when doing this step)
'''This is important to start command with 'begin;' so that if any syntax mistakes could be undo.'''
blaster=> begin; insert into job_types values(<next_available_id>, now(), '<your_job_name>');
Example:
blaster=> begin; insert into job_types values(16, now(), 'shape');
//To save data
blaster=> commit;
//Or if made mistake, to reverse cmd
blaster=> rollback;

=== Setting up templates ===
* Create template directory
sudo -i
su - www
cd /nfs/ex7/blaster/templates/
mkdir <job_name> // job_name must match the shortname in job_types table
chmod 777 job_name //for now...
* Get parameters.json
This is recommend that you go though all the currently existing modules on [https://tldr.docking.org TLDR] and reuse instead of starting one from scratch.
cd job_name
cp <whatever parameters.json you pick>
vim parameters.json
Change the variables. Check on the website if the module shows up.
* Move your shell scripts in directory

=== Test run! ===

[[Category: Developer]]
[[Category: TLDR]]

Add TLDR module

2025-01-14T07:51:58Z

Khtang: Khtang moved page Add Tools18 module to Add TLDR module without leaving a redirect

Here is quick guide to add your script into [[Tools18]] interface
=== Scripts ===

=== Add job type into psql table ===
*Access the database
$ psql -h mem2 -d blaster -U blasteruser

*Look for the next available index on job_types table
blaster=> select * from job_types order by job_type_id;
You will see table like this
job_type_id | last_updated | short_name
-------------+----------------------------+-------------------
1 | 2018-10-05 00:00:00 | analog
2 | 2018-10-05 00:00:00 | blaster
3 | 2018-10-05 00:00:00 | blasterpdb
4 | 2018-10-05 00:00:00 | build2d
5 | 2018-10-05 00:00:00 | build3d
6 | 2018-10-05 00:00:00 | cluster
7 | 2018-10-05 00:00:00 | covalent
8 | 2018-10-05 00:00:00 | dude
9 | 2018-10-05 00:00:00 | libanalysis
10 | 2018-10-05 00:00:00 | reaction
11 | 2018-10-05 00:00:00 | sea
12 | 2018-10-05 00:00:00 | threec
13 | 2018-10-05 00:00:00 | transform
14 | 2018-10-05 00:00:00 | zincbatch
15 | 2018-12-01 18:47:34 | cluster_molecules

* Insert new job type (Please be extra careful when doing this step)
'''This is important to start command with 'begin;' so that if any syntax mistakes could be undo.'''
blaster=> begin; insert into job_types values(<next_available_id>, now(), '<your_job_name>');
Example:
blaster=> begin; insert into job_types values(16, now(), 'shape');
//To save data
blaster=> commit;
//Or if made mistake, to reverse cmd
blaster=> rollback;

=== Setting up templates ===
* Create template directory
sudo -i
su - www
cd /nfs/ex7/blaster/templates/
mkdir <job_name> // job_name must match the shortname in job_types table
chmod 777 job_name //for now...
* Get parameters.json
This is recommend that you go though all the currently existing modules on [https://tldr.docking.org TLDR] and reuse instead of starting one from scratch.
cd job_name
cp <whatever parameters.json you pick>
vim parameters.json
Change the variables. Check on the website if the module shows up.
* Move your shell scripts in directory

=== Test run! ===

[[Category: Developer]]
[[Category: TLDR]]

Add TLDR module

2025-01-14T07:51:28Z

Khtang: /* Setting up templates */

Add TLDR module

2025-01-14T07:44:18Z

Khtang: /* Add job type into psql table */

Here is quick guide to add your script into [[Tools18]] interface
=== Scripts ===

=== Add job type into psql table ===
*Access the database
$ psql -h mem2 -d blaster -U blasteruser

*Look for the next available index on job_types table
blaster=> select * from job_types order by job_type_id;
You will see table like this
job_type_id | last_updated | short_name
-------------+----------------------------+-------------------
1 | 2018-10-05 00:00:00 | analog
2 | 2018-10-05 00:00:00 | blaster
3 | 2018-10-05 00:00:00 | blasterpdb
4 | 2018-10-05 00:00:00 | build2d
5 | 2018-10-05 00:00:00 | build3d
6 | 2018-10-05 00:00:00 | cluster
7 | 2018-10-05 00:00:00 | covalent
8 | 2018-10-05 00:00:00 | dude
9 | 2018-10-05 00:00:00 | libanalysis
10 | 2018-10-05 00:00:00 | reaction
11 | 2018-10-05 00:00:00 | sea
12 | 2018-10-05 00:00:00 | threec
13 | 2018-10-05 00:00:00 | transform
14 | 2018-10-05 00:00:00 | zincbatch
15 | 2018-12-01 18:47:34 | cluster_molecules

* Insert new job type (Please be extra careful when doing this step)
'''This is important to start command with 'begin;' so that if any syntax mistakes could be undo.'''
blaster=> begin; insert into job_types values(<next_available_id>, now(), '<your_job_name>');
Example:
blaster=> begin; insert into job_types values(16, now(), 'shape');
//To save data
blaster=> commit;
//Or if made mistake, to reverse cmd
blaster=> rollback;

=== Setting up templates ===
* Create directory
$ cd /nfs/ex7/blaster/templates/
$ mkdir <job_name> // job_name must match the shortname in job_types table
$ chmod 777 job_name //for now...
* Get parameters.json
This is recommend that you go though all the currently existing modules on [https://tldr.docking.org TLDR] and reuse instead of starting one from scratch.
$ cd job_name
$ cp <whatever parameters.json you pick>
$ vim parameters.json
Change the variables. Check on the website if the module shows up.
* Move your shell scripts in directory

=== Test run! ===

[[Category: Developer]]
[[Category: TLDR]]

User talk:Sstrizhov

2025-01-07T19:48:59Z

Khtang: Welcome!

User:Sstrizhov

2025-01-07T19:48:59Z

Khtang: Creating user page for new user.

I want to work here period.

TLDR

2025-01-06T23:31:00Z

Khtang:

Create new user

2024-11-12T19:30:38Z

Khtang:

===Identify a UID===
'''Check if a uid that is not taken by any other users'''. Start from 150**
On CentOS 6
$ getent passwd | grep 150**
On CentOS 7
$ id 150**

===Create users and superuser on the LDAP GUI:===
https://ds.ucsf.bkslab.org/ldapadmin/cmd.php

====To create a visitor: ====
Click OU=Visitors
Click Create new entry here
Select Generic: User Account
Fill in appropriate sections
-home dir should be /nfs/home/<username>
-password should be encrypted with sha512
-group should be visitors
Keep the uid LDAP suggested and edit in the one you picked later.

==== Create User's Home Directory ====
Log in as root on mem
$ sh /nfs/home/[create-visitor.sh/create-member.sh] <user_name>

=== Generate ssh for login ===
====Create ssh key ====
In the user's home directory's personal computer:
$ ssh keygen

==== Add user's public key to Portal ====
$ ssh s_khtang@portal.ucsf.bkslab.org
$ sudo -i
$ cd /opt/keys/user
$ vim <username>
Copy the .rsa_key.pub content into the file

==== Add user into Portal ====
On LDAP Admin
Choose ''' dc=bkslab,dc=org (17)''' > '''Group''' > '''Portal'''
Enter <username> in Add Value

=== Add s_ user in alpha ===
Since Alpha was created before ldap admin system, new user must be created individually on this machine.

Add the s_ user in
vim /etc/passwd
vim /etc/group

Change password
passwd s_<user>

[[Category: Ben]] [[Category:Sysadmin]]

TLDR

2024-11-12T06:21:45Z

Khtang: /* Current available modules */

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"

{{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]]

== 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 ==
See [[Add Tools18 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.

[[Category: TLDR]]
[[Category: Tools18]]

Manage Lab Websites

2024-11-11T04:21:22Z

Khtang: /* Restart Instructions after UPS */

We are trying to migrate all services to gitlab.
This page is perpetually out-of-date. Look at gitlab first. If not there, look below.

== List of Websites ==
Last updated on 11/10/2024
{| class="wikitable"
!Website
!Machine:Port
!Run on
!Hosted in (httpd/conf.d)
!Working
|-
|Amis: https://amis.docking.org/
|n-9-38:5066
|docker
|epyc
|Yes
|-
|Arthor: https://arthor.docking.org/
|nun, samekh, n-9-22; Port 8000
|Screen
|epyc
|Yes
|-
|BKSLab: http://www.bkslab.org/
|n-5-13:5002
|docker
|epyc
|Yes
|-
|Blaster: https://blaster.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Cartblanche22: https://cartblanche22.docking.org/
|n-9-22:5068
|docker
|epyc
|Yes
|-
|Covalent: http://covalent.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|DSF: https://dsf.docking.org/
|
|
|Vav (169.230.26.43)
|No (wrong website)
|-
|Duc: https://duc.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|Dud: https://dud.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Dude18: http://dude18.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|Dude: http://dude.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Dudez: http://dudez.docking.org/
|
|
|Files2 (169.230.75.3)
|Yes
|-
|Excipients: http://excipients.docking.org/
|gimel:8093
|Supervisord
|Vav (169.230.26.43)
|Yes
|-
|Gitlab: https://gitlab.docking.org/
|
|
|Files2 (169.230.75.3)
|No
|-
|HG: https://hg.docking.org/
|
|
|Files2 (169.230.75.3)
|No
|-
|IrwinLab: http://irwinlab.compbio.ucsf.edu/
|n-5-13:5004
|docker
|epyc
|Yes
|-
|Metabolite: http://metabolite.docking.org/
|
|
|Tau (169.230.26.43, can not be moved to files2)
|showing wrong website
|-
|Deepchemworkshop: http://deepchemworkshop.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Prices: http://prices.docking.org/
|gimel:5022
|
|Tau (169.230.26.43)
|No
|-
|Psicquic: http://psicquic.docking.org/
|
|
|Tau (169.230.26.43)
|Yes (broken???)
|-
|Reactor: http://reactor.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Transporters: http://transporters.ucsf.bkslab.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Sea16: http://sea16.docking.org/
|gimel:8086
|
|Files2 (169.230.75.3)
|Yes
|-
|SEC: http://sec.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Smallworld Public: http://sw.docking.org/
|abacus:5020
|screen
|epyc
|Yes
|-
|Smallworld Private: http://swp.docking.org/
|abacus:8080
|screen
|epyc
|Yes
|-
|Smallworld Super Private: http://swc.docking.org/
|abacus:5099
|screen
|epyc
|Yes
|-
|Stats: http://stats.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|No
|-
|Symp: http://symp.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|TLDR http://tldr.docking.org/
|epyc-A40:5011
|systemd
|Files2 (169.230.26.43)
|Yes
|-
|Tool-Selector: http://tool-selector.ucsf.bkslab.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Transportal: http://transportal.docking.org/
|n-9-23 : port 8123
|screen
|Vav (169.230.26.43)
|Yes
|-
|Upload: http://upload.docking.org/
|
|
|Tau (169.230.26.43)
|Yes
|-
|Zinc12: http://zinc12.docking.org/
|
|
|Tau (169.230.26.43, can not be moved to files2)
|Yes
|-
|-
|Zinc15: http://zinc15.docking.org/
|epyc2:5064
|docker
|epyc
|Yes
|-
|Zinc20: http://zinc20.docking.org/
|epyc2:5065
|docker
|epyc
|Yes
|-
|Chemistry Commons: https://commons.docking.org/
|epyc2:5010
|docker
|epyc
|Yes
|-
|}

== Restart Instructions after UPS==
=== For websites running on Docker ===
Login to machine using sudoer account.
$ sudo docker ps //to list all apps, including non-running
$ sudo docker start <name>

To restart a container
$ sudo docker restart <name>

=== For websites running on Screen ===

==== SEA ====
SEA is running on a screen on gimel

Become www on gimel
$ cd /nfs/soft/www/apps/seadev/
On bash shell
$ source tools/anaconda2/bin/activate sea16
$ cd work/seaware/seaware-academic
$ make SEAserver-stop-devel
$ make all
$ make SEAserver-start-devel
Ctrl A+D to detach screen

==== Transportal ====
Login n-9-23 and become www
$ screen -ls
$ screen -r transportal
$ cd /mnt/nfs/soft/www/apps/transportal/
$ source envs/production-3.6/bin/activate.csh
$ cd /nfs/soft/www/home/apps/transportal/src/transportal_2022/transportal
$ python manage.py runserver 0.0.0.0:8123
Ctrl A+D to detach screen

=== For websites running on Supervisord ===
==== Restart applications ====
* Become root on server the website runs on gimel
$ supervisorctl status //to list all of current running apps
$ supervisorctl restart <name>
i.e
$ supervisorctl restart bks-lab

==== Start Supervisord ====
$ supervisord

=== For websites running on Systemd ===
==== Restart applications ====
$ sudo systemctl restart <name>

<b>TLDR</b> is running on epyc-A40 and managed by systemd
$ sudo systemctl restart tldr

[[Category:Sysadmin]]
[[Category:Curator]]

Manage Lab Websites

2024-11-11T04:19:16Z

Khtang: /* List of Websites */

We are trying to migrate all services to gitlab.
This page is perpetually out-of-date. Look at gitlab first. If not there, look below.

== List of Websites ==
Last updated on 11/10/2024
{| class="wikitable"
!Website
!Machine:Port
!Run on
!Hosted in (httpd/conf.d)
!Working
|-
|Amis: https://amis.docking.org/
|n-9-38:5066
|docker
|epyc
|Yes
|-
|Arthor: https://arthor.docking.org/
|nun, samekh, n-9-22; Port 8000
|Screen
|epyc
|Yes
|-
|BKSLab: http://www.bkslab.org/
|n-5-13:5002
|docker
|epyc
|Yes
|-
|Blaster: https://blaster.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Cartblanche22: https://cartblanche22.docking.org/
|n-9-22:5068
|docker
|epyc
|Yes
|-
|Covalent: http://covalent.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|DSF: https://dsf.docking.org/
|
|
|Vav (169.230.26.43)
|No (wrong website)
|-
|Duc: https://duc.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|Dud: https://dud.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Dude18: http://dude18.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|Dude: http://dude.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|Yes
|-
|Dudez: http://dudez.docking.org/
|
|
|Files2 (169.230.75.3)
|Yes
|-
|Excipients: http://excipients.docking.org/
|gimel:8093
|Supervisord
|Vav (169.230.26.43)
|Yes
|-
|Gitlab: https://gitlab.docking.org/
|
|
|Files2 (169.230.75.3)
|No
|-
|HG: https://hg.docking.org/
|
|
|Files2 (169.230.75.3)
|No
|-
|IrwinLab: http://irwinlab.compbio.ucsf.edu/
|n-5-13:5004
|docker
|epyc
|Yes
|-
|Metabolite: http://metabolite.docking.org/
|
|
|Tau (169.230.26.43, can not be moved to files2)
|showing wrong website
|-
|Deepchemworkshop: http://deepchemworkshop.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Prices: http://prices.docking.org/
|gimel:5022
|
|Tau (169.230.26.43)
|No
|-
|Psicquic: http://psicquic.docking.org/
|
|
|Tau (169.230.26.43)
|Yes (broken???)
|-
|Reactor: http://reactor.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Transporters: http://transporters.ucsf.bkslab.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Sea16: http://sea16.docking.org/
|gimel:8086
|
|Files2 (169.230.75.3)
|Yes
|-
|SEC: http://sec.docking.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Smallworld Public: http://sw.docking.org/
|abacus:5020
|screen
|epyc
|Yes
|-
|Smallworld Private: http://swp.docking.org/
|abacus:8080
|screen
|epyc
|Yes
|-
|Smallworld Super Private: http://swc.docking.org/
|abacus:5099
|screen
|epyc
|Yes
|-
|Stats: http://stats.docking.org/
|
|
|Vav (169.230.26.43, can not be moved to files2)
|No
|-
|Symp: http://symp.docking.org/
|
|
|Vav (169.230.26.43)
|No
|-
|TLDR http://tldr.docking.org/
|epyc-A40:5011
|systemd
|Files2 (169.230.26.43)
|Yes
|-
|Tool-Selector: http://tool-selector.ucsf.bkslab.org/
|
|
|Vav (169.230.26.43)
|Yes
|-
|Transportal: http://transportal.docking.org/
|n-9-23 : port 8123
|screen
|Vav (169.230.26.43)
|Yes
|-
|Upload: http://upload.docking.org/
|
|
|Tau (169.230.26.43)
|Yes
|-
|Zinc12: http://zinc12.docking.org/
|
|
|Tau (169.230.26.43, can not be moved to files2)
|Yes
|-
|-
|Zinc15: http://zinc15.docking.org/
|epyc2:5064
|docker
|epyc
|Yes
|-
|Zinc20: http://zinc20.docking.org/
|epyc2:5065
|docker
|epyc
|Yes
|-
|Chemistry Commons: https://commons.docking.org/
|epyc2:5010
|docker
|epyc
|Yes
|-
|}

== Restart Instructions after UPS==
=== For websites running on Docker ===
Login to machine using sudoer account.
$ sudo docker ps //to list all apps, including non-running
$ sudo docker start <name>

To restart a container
$ sudo docker restart <name>

=== For websites running on Screen ===

==== SEA ====
SEA is running on a screen on gimel

Become www on gimel
$ cd /nfs/soft/www/apps/seadev/
On bash shell
$ source tools/anaconda2/bin/activate sea16
$ cd work/seaware/seaware-academic
$ make SEAserver-stop-devel
$ make all
$ make SEAserver-start-devel
Ctrl A+D to detach screen

==== Transportal ====
Login n-9-23 and become www
$ screen -ls
$ screen -r transportal
$ cd /mnt/nfs/soft/www/apps/transportal/
$ source envs/production-3.6/bin/activate.csh
$ cd /nfs/soft/www/home/apps/transportal/src/transportal_2022/transportal
$ python manage.py runserver 0.0.0.0:8123
Ctrl A+D to detach screen

=== For websites running on Supervisord ===
==== Restart applications ====
* Become root on server the website runs on gimel
$ supervisorctl status //to list all of current running apps
$ supervisorctl restart <name>
i.e
$ supervisorctl restart bks-lab

<b>TLDR</b> is running on gimel2 and managed by supervisord
$ supervisorctl restart tldr
==== Start Supervisord ====
$ supervisord

[[Category:Sysadmin]]
[[Category:Curator]]
[[Category:Khanh]]