How To Load New ZINC Databases: Difference between revisions
Line 107: | Line 107: | ||
... | ... | ||
to be clear, you would only want to export any of the variables for a particular stage if that stage succeeded the previous time you ran the script. | to be clear, you would only want to export any of the variables for a particular stage if that stage succeeded the previous time you ran the script. It saves time to not re-do any work. | ||
</nowiki> | </nowiki> |
Revision as of 18:45, 15 June 2020
Start
- log in to machine
- check that /local2/load directory exists and is owned by xyz
- clear it out if it does exist
- do "netstat -plunt" and check ports 5434-54XX to see which tin databases are online
- if tin databases are not online, look for postgres installation and creation scripts in /nfs/home/chinzo/code/installation-utilities/*
- login as xyz through sudo -i
- go to ~/btingle/zinc_deploy/zinc-deploy-V2
- this is where you will launch the zinc loading script from
- the run_p39, run_p40, run_p41, run_p42 files are scripts to load individual partitions of the m tranches
- open one of these in an editor
Environment Variables
PARALLEL_JOBS
the number of concurrent slurm jobs for this load
the higher this number the faster certain parts of the load script will be
you want to make sure you are not queuing more parallel jobs than there are cpu cores on the machine
PARTITION_NO
the # of the partition of the tranche database to load. this decides which molecules are loaded
these partitions are defined in the partitions.txt file
the # of the partitions we deploy should start at 39 and increase sequentially from there, up to a max of 134]
(so far I have deployed through 42, so start at 43)
TRANCHE_SRC
location of the source tranche directory on the nfs
the different sources are in /mnt/nfs/exa/work/jyoung/phase2_tranche/*
it is ok to load databases with the same partition number if they are from different tranche sources
CATALOG_SHORTNAME
m or s, depending on the source directory you choose
ZINC_HOST
the name of the machine you are running this script on
ZINC_PORT
the port number of the postgres database
if you're loading a database from a different source but the same partition number as another database, you must use the same host and port number as that database
Running the Script
I run the run_pXX scripts like so:
screen -S p_${PARTITION_NO}_${PORT} time bash run_p${PARTITION_NO}
I'd prefer if the zinc-deploy-v2 folder was not crammed with any more of these one-off script files, so you should put this header in your own script files:
RUN_DIR=~/btingle/zinc_deploy/zinc-deploy-V2 cd $RUN_DIR ...
and store them in a different folder
before you load up a postgres database for the first time, make sure to run the tin_wipe script in ~/btingle/zinc_deploy/misc WARNING: this will truncate all of the major tables in the database, so make sure you're not too attached to whatever's in there
bash ./tin_wipe ${HOST_NAME} ${PORT_NUMBER}
Logging
check batch_logs/<step name>_<job id>_<array id>.out for the log output of various jobs
<step name> : <description>
run_catalog_load : main job output, loading and resolution script output
pre_process : pre processing job output
post_process : post processing job output
Email to Khanh, 6/15
Khanh The reason there was an error is because of misconfigured environment variables, but I've fixed them now. Your script seems to have succeeded in pre-processing the molecules, but failed on the following stages. No big deal, you can just re-run the script with some changes. If the pre-processing stage went through but there was an error in any of the following stages I added the option to skip that(those) stage(s) in the following run. You can also skip the resolution and post processing stages if something goes wrong there. To see if there was an error with any of the stages you can check .err, but you can also check .out to see what the main script output is. If you don't see any jobs pop up for a particular stage, or if the output indicates it processed zero entries for that stage you can be sure something went wrong. You can re-run the script with these environment variables to skip that stage. Only export this environment variable if there was an error during a previous time you ran the script, for example you would not want to export any of these when running the script for a particular partition the first time. export SKIP_PRE_PROCESS="TRUE" export SKIP_RESOLUTION="TRUE" export SKIP_POST_PROCESS="TRUE" export SKIP_LOADING="TRUE" (I have no idea why you would ever want to use that last one, but it's there for completeness's sake) Lmk if you have questions. Ben ... to be clear, you would only want to export any of the variables for a particular stage if that stage succeeded the previous time you ran the script. It saves time to not re-do any work.