Arthor Documentation for Future Developer: Difference between revisions
No edit summary |
No edit summary |
||
Line 206: | Line 206: | ||
==Uploading Indexes to the Web Application== | ==Uploading Indexes to the Web Application== | ||
==Further Arthor Optimizations== | |||
The following edits can be made to the arthor.cfg to optimize substructure search queries. More information can be found in pages 6-8 in the Arthor Documentation file. | |||
'''NodeAffinity NUMA''': optimized flag, pin processing to specific CPU sets to where the data is located in memory. There is a small start-up cost and is most useful for long running services (see Non-Uniform Memory Access (NUMA)) | |||
'''AsyncHitCountAllowed=true|false''' After fetching a page from a substructure or formula search the server will spin off a background process to count the total number of hits. This can be resource intensive for large databases and may not be desirable for servers under heavy load and may not even be needed. | |||
'''AsyncHitCountMax=#''' The upper-bound for the number of hits to retrieve in background searches. If very generic queries are issued (e.g. benzene or methane) hundred’s of millions of hits may be counted. Setting this value to anything other than zero (e.g. 10,000) will stop the background search if it exceeds this limit. Note some pathological queries may find very few hits but still end up looking at everything. | |||
'''MaxConcurrentSearches=#''' Controls the maximum number of searches that can be run concurrently by setting the database pool size. The searches may be on the same or different databases. If a search comes in and the pool is full it will have to wait for another search to finish - this increases the request time.
| |||
Typically if each search is using all the processing cores on a machine then additional searches will run at 1/Nth the speed. If the request time is substantially larger that the search time the request had to wait for resources to become available. When switching between a large number of databases it can be useful to have a larger pool size, the only trade off is keeping file pointers open.
Default: 6 | |||
'''Binary Fingerprint Folding''' Arthor uses binary circular fingerprints (ECFP4/radius=2) for similarity. When creating an ATFP index you can specify how large to make your fingerprints. Circular fingerprints are sparser than path based fingerprints (e.g. Daylight) and so can be folded smaller without too much degradation in performance. Folding can significantly reduce the footprint size of a database and improve search speeds. A 256-bit fingerprint takes up 1/4 of the space of 1024-bit and can therefore be traversed 4x faster. | |||
This is more important for very large databases with billions of compounds, in such instances a minor drop in precision is likely tolerable as ultimately all that happens is some hits may swap places in the hit list. | |||
==Virtual Memory== | |||
In addition to modifying the arthor.cfg file, virtual memory can also be used to make queries faster. More information can be found in pages 10-16 in the Arthor Documentation. | |||
==Setting up Round Table== | ==Setting up Round Table== |
Revision as of 18:23, 12 August 2020
Written by Jennifer Young on December 16, 2019. Last edited January 30, 2020
Install and Set Up on TomCat
Arthor currently runs on n-1-136, which runs CentOS Linux release 7.7.1908 (Core). You can check the version of CentOS with the following command
cat /etc/centos-release
Check your current version of Java with the following command:
java -version
On n-1-136 we are running openjdk version "1.8.0_222", OpenJDK Runtime Environment (build 1.8.0_222-b10), and OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) If Java is not installed, install it using yum
See this wiki page for more detailed information about installing Tomcat on our cluster
http://wiki.docking.org/index.php/Tomcat_Installation
Open port for Arthor
In order for Arthor to be usable in the browser, the port you wish to run it on must be opened. https://www.thegeekdiary.com/how-to-open-a-ports-in-centos-rhel-7/
Step 1: Check Port Status
Check that the port is not open and that Apache is not showing that port.
netstat -na | grep <port number you are checking>
lsof -i -P |grep http
Step 2: Check Port Status in IP Tables
iptables-save | grep <port number you are checking>
I skipped Step 3 from the guide, because there was a lot of information in the /etc/services file and I didn't want to edit it and break something.
Step 4: Open Firewall Ports
I did not include the zone=public section because the stand-alone servers are usually used for private instances of Arthor and SmallWorld. Run as root.
firewall-cmd --add-port=<port number you are adding>/tcp --permanent
You need to reload the firewall after a change is made.
firewall-cmd --reload
Step 5: Check that port is working
To check that the port is active, run.
iptables -nL
You should see something along the lines of:
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:<port number you're adding> ctstate NEW,UNTRACKED
How to run standalone Arthor instance
Step 1: Use or start a bash shell
You can check your default shell using
echo $SHELL
If your default shell is csh, use
bash
to start a new bash shell in the current terminal window. Note that echo $SHELL will show you your default shell regardless of the current shell.
Step 2: Set your environment variables
export ARTHOR_DIR=/opt/nextmove/arthor/arthor-3.0-rt-beta-linux export PATH=$ARTHOR_DIR/bin/:$PATH
Make sure the ARTHOR_DIR variable is set to the directory for the latest version of Arthor or whichever version you would like to test. The PATH environment variable is needed if you wish to use the Arthor tools from the command line
Step 3: Run the arthor-server.jar
java -jar /opt/nextmove/arthor/arthor-3.0-rt-beta-linux/java/arthor-server.jar --httpPort <your httpPort>
Setting environment variables for TomCat Server
Set the environment variables in the setenv.sh file. Note: Be sure to edit the file in the directory corresponding to the latest version of TomCat. As of December 2019, we are running 9.0.27 on n-1-136.
vim /opt/tomcat/apache-tomcat-9.0.27/bin/setenv.sh
Add the line below to the setenv.sh file above, or substitute the path to wherever you currently store the arthor.cfg file
export ARTHOR_CONFIG=/usr/local/tomcat/arthor.cfg
Here is an example of the arthor.cfg file:
# Arthor generated config file BINDIR=/opt/nextmove/arthor/arthor-2.1.2-centos7/bin DATADIR=/usr/local/tomcat/arthor_data STAGEDIR=/usr/local/arthor_data/stage NTHREADS=64 . NODEAFFINITY=true SearchAsYouDraw=true AutomaticIndex=true DEPICTION=./depict/bot/svg?w=%w&h=%h&svgunits=px&smi=%s&zoom=0.8&sma=%m&smalim=1 RESOLVER=
Important parts of the arthor.cfg file
BINDIR is the location of the Arthor command line binaries. These are used to generate the Arthor index files and to perform searches directly on n-1-136. An example of this would be using atdbgrep for substructure search.
DATADIR This is the directory where the Arthor data files live. Location where the index files will be created and loaded from.
STAGEDIR Location where the index files will be built before being moved into the DATADIR.
NTHREADS The number of threads to use for both ATDB and ATFP searches
Set AutomaticIndex to false if you don't want new smiles files added to the data directory to be indexed automatically
Background
Before working with Arthor, it is recommended that you familiarize yourself with the Arthor documentation. Some useful pages to look at include 3-5, 22-25 and 33-39. Of course, reading everything would be the best!
Checking Memory Usage
Before building arthor indexes, it's always a good thing to check what percent of the memory is being used. Try to be cautious with how much memory you have left, and make sure to check while building indexes to make sure that you have enough space. To check, run the following command:
df -h /<directory with disc>
Building Large Databases
At the moment, we are building databases of size 500M molecules by merging smile files. There are multiple methods of trying to create large databases, one being merging based off of the same H?? prefix and stopping once the database reaches > 500M molecules (or whatever upperbound you want to use). Here is some python code that simulates this merging process. Essentially the program takes all of the .smi files within an input directory, sorts them lexiographically, and begins merging these .smi files together in order until the size reaches > 500M molecules.
Feel free to modify it if you think a better method exists.
import subprocess import sys import os from os import listdir from os.path import isfile, join mypath = "<Path to directory holding .smi files>" onlyfiles = [f for f in listdir(mypath) if isfile(join(mypath, f))] onlyfiles.sort() create_fp = True cur_mols = 0 lower_bound = 500000000 upper_bound = 600000000 files_to_merge = [] def merge_files(f_t_m): arr = f_t_m[0].split(".") arr2 = f_t_m[len(f_t_m) - 1].split(".") file_name_merge = (arr[0] + "_" + arr2[0] + ".smi") print ("File being created: " + file_name_merge) for file in f_t_m: tmp = file.split(".") process = subprocess.Popen("cat " + join(mypath, file) + " >> " + file_name_merge, shell=True) process.wait() for file in onlyfiles: arr = file.split(".") if (arr[len(arr) - 1] == "smi"): print("Working with " + file) mol = sum(1 for line in open(join(mypath, file))) print(file, mol, cur_mols) if (cur_mols + mol > lower_bound): if (cur_mols + mol < upper_bound): files_to_merge.append(file) merge_files(files_to_merge) cur_mols = 0 files_to_merge.clear() else: merge_files(files_to_merge) files_to_merge.clear() files_to_merge.append(file) merge_files(files_to_merge) cur_mols = 0 files_to_merge.clear() else: cur_mols += mol files_to_merge.append(file) if (len(files_to_merge) != 0): merge_files(files_to_merge)
Building Arthor Indexes
Once you've merged the .smi files together, it's time to start building the databases themselves. To do this we use the command
smi2atdb -j 0 -p <The .smi file> <The .atdb>
The flag "-j 0" enables parallel generation and utilizes all available processors to generate the .atdb file. The "-p" flag stores the offset position in the ATDB file. Since we're building indexes for the Web Application, you must use the "-p" flag when building indexes. Please note that the name of the .smi file should also be the name of the .atdb file. That way, the Web Application knows to use these files together and correctly display the required images. Refer to pages 33-34 in the Arthor documentation for more information.
If there are too many large .smi files and you do not want to manually build each .atdb file, you can use this python script which takes all of the .smi files in the current directory and converts them to .atdb files. Make sure to modify mypath to the directory containing the .smi files. You can change the variable "create_fp" to false if you don't want to create .atdb.fp files (refer to page 9 in the Arthor documentation).
import subprocess import sys import os from os import listdir from os.path import isfile, join mypath = "<Path containing the .smi files" onlyfiles = [f for f in listdir(mypath) if isfile(join(mypath, f))] create_fp = True for file in onlyfiles: arr = file.split(".") if (arr[len(arr) - 1] == "smi"): process = subprocess.Popen("/nfs/ex9/work/xyz/psql/arthor-3.3-centos7/bin/smi2atdb -j 0 -p {0} {1}.atdb".format(join(mypath, file), arr[0]), shell=True) process.wait() print("SUCCESS! {0}.atdb file was created!".format(arr[0])) if (create_fp): process = subprocess.Popen("/nfs/ex9/work/xyz/psql/arthor-3.3-centos7/bin/atdb2fp -j 0 {0}.atdb".format(arr[0]), shell=True) process.wait() print("SUCCESS! {0}.atdb.fp file was created!".format(arr[0]))
Search Queries
Uploading Indexes to the Web Application
Further Arthor Optimizations
The following edits can be made to the arthor.cfg to optimize substructure search queries. More information can be found in pages 6-8 in the Arthor Documentation file.
NodeAffinity NUMA: optimized flag, pin processing to specific CPU sets to where the data is located in memory. There is a small start-up cost and is most useful for long running services (see Non-Uniform Memory Access (NUMA))
AsyncHitCountAllowed=true|false After fetching a page from a substructure or formula search the server will spin off a background process to count the total number of hits. This can be resource intensive for large databases and may not be desirable for servers under heavy load and may not even be needed.
AsyncHitCountMax=# The upper-bound for the number of hits to retrieve in background searches. If very generic queries are issued (e.g. benzene or methane) hundred’s of millions of hits may be counted. Setting this value to anything other than zero (e.g. 10,000) will stop the background search if it exceeds this limit. Note some pathological queries may find very few hits but still end up looking at everything.
MaxConcurrentSearches=# Controls the maximum number of searches that can be run concurrently by setting the database pool size. The searches may be on the same or different databases. If a search comes in and the pool is full it will have to wait for another search to finish - this increases the request time.
Typically if each search is using all the processing cores on a machine then additional searches will run at 1/Nth the speed. If the request time is substantially larger that the search time the request had to wait for resources to become available. When switching between a large number of databases it can be useful to have a larger pool size, the only trade off is keeping file pointers open. Default: 6
Binary Fingerprint Folding Arthor uses binary circular fingerprints (ECFP4/radius=2) for similarity. When creating an ATFP index you can specify how large to make your fingerprints. Circular fingerprints are sparser than path based fingerprints (e.g. Daylight) and so can be folded smaller without too much degradation in performance. Folding can significantly reduce the footprint size of a database and improve search speeds. A 256-bit fingerprint takes up 1/4 of the space of 1024-bit and can therefore be traversed 4x faster.
This is more important for very large databases with billions of compounds, in such instances a minor drop in precision is likely tolerable as ultimately all that happens is some hits may swap places in the hit list.
Virtual Memory
In addition to modifying the arthor.cfg file, virtual memory can also be used to make queries faster. More information can be found in pages 10-16 in the Arthor Documentation.
Setting up Round Table
This is a new feature in Arthor 3.0 and is currently beta (January 2020). See section 2.4 in the manual As explained in the manual, "Round Table allows you to serve and split chemical searches across multiple host machines. The implementation provides a lightweight proxy that forwards requests to other Arthor host servers that do the actual search. Communication is done using the existing Web APIs.
Since Arthor requires CentOS 7, as of January 2020 we have 6 servers that are capable of running Arthor with Round Table. See the table below for the machines currently involved in Round Table
CentOS 7 Machine | Private IP | Arthor Install Location | Round Table Data Directory |
---|---|---|---|
n-1-136 | 10.20.10.136 | /opt/nextmove/arthor/arthor-3.0-rt-beta-linux | N/A. Round Table Server |
abacus | 10.20.0.5 | /opt/nextmove/arthor/arthor-3.0-rt-beta-linux | /export/db2/arthor_round_table_abacus |
shin | 10.20.0.1 | /opt/nextmove/arthor/arthor-3.0-rt-beta-linux | /export/db/arthor |
zayin | 10.20.0.2 | /opt/nextmove/arthor/arthor-3.0-rt-beta-linux | /export/exa/work/jyoung/arthor_round_table_zayin |
qof | 10.20.9.29 | /opt/nextmove/arthor/arthor-3.0-rt-beta-linux | /export/ex9/work/jyoung/arthor_data_qof/data |
lamed | 10.20.9.15 | /opt/nextmove/arthor/arthor-3.0-rt-beta-linux | /export/ex6/work/jyoung |
Setting up Host Server
If we want to add machines to the Round Table, for example 'nun' and 'samekh', we need to edit their arthor.cfg file so that when our Local Machine passes commands these secondary servers know to perform the search they are given.
$ cat arthor.cfg MaxThreadsPerSearch=4 AutomaticIndex=false DATADIR=<Directory where smiles are located>
We then run the jar server on each of these host machines containing data on any available port.
For our local machine, the arthor.cfg file will look different.
$ cat arthor.cfg [RoundTable] RemoteClient=http://skynet:<port number where jar server is running>/ RemoteClient=http://hal:<port number where jar server is running>/
Please refer to Section 2 in the RoundTable Documentation file (pages 6-8) for more useful information on configuration.