Skip to content

Server Configuration

This page covers advanced configuration options. For basic settings that have to be specified upon installation, please refer to the mandatory configuration section of the previous page.

Changing the Configuration

The iserver application provides a variety of configuration options that can be set via a text file named application.properties. This configuration file can be located either in the same folder as the server executable (iserver) or in a dedicated /config subdirectory of the current working directory. If both are present, the latter option has the higher priority, which allows different users to easily start the server application with their own configuration.

Info

It is required to restart the server after changing the configuration file for the changes to take effect.

Scheduler and Job-Splitting Parameters

The first and most important setting concerns the cluster resource management system (scheduler) in use. If this is not SGE, this is a mandatory setting, as described here.

# Possible values: sge, pbs, torque
scheduler=sge


The next settings specifies how many resource manager slots should be used for a single virtual screening sub-job. This usually translates to processor cores. This setting can be overriden by the user when sending a remote screening request from LigandScout or KNIME.

scheduler.number.processors.screening=2


Similar to virtual screening, it is also possible to specify how many resource manager slots should be used for a single conformer generation sub-job. This setting can be overriden by the user when sending a remote conformer generation request from LigandScout or KNIME.

scheduler.number.processors.confgen=4


All supported schedulers allow to specifiy a priority when submitted a new job into the queue. The higher this value is, the less priority the job has.

scheduler.priority=0

Reference

Cited from man qsub:

Defines or redefines the priority of the job relative to other jobs. Priority is an integer in the range -1023 to 1024. The default priority value for jobs is 0.

This statement is valid for all supported schedulers.

This setting can be overriden by the user when sending a remote screening request from LigandScout or KNIME.

Info

Setting values below 0 is usually not allowed for regular cluster users. It is recommended to leave this value at 0 or increase it when jobs started via iserver should not have high priority.


When using an SGE resource manager, it is required to specify a correct parallel environment. The iserver application does not support MPI, therefore a shared-memory environment has to be set. Usually, this is smp, which is also the default setting in the iserver configuration:

scheduler.sge.parallel.environment=smp


The queue that should be used for submitting jobs to SGE can also be set. The specified queue name will be used when detecting the number of currently available slots. Many SGE installations use only one queue (all.q), in this case, it is not required to change the iserver configuration.

scheduler.sge.queue=all.q

The next option can be used to pass any arguments to an SGE scheduling system.

scheduler.sge.option.string=


The iscreen command-line tool is used for submitting virtual screening jobs to the cluster resource manager. The following options can be used for specifying the resources these iscreen jobs should be allowed to consum. Practical evaluation has showed that the best performance is usually achieved when using around 1.5 to 2 times as many iscreen cores as scheduler slots. This is because not all jobs are always consuming 100% of the resources that are assigned to them.

The iscreen.memory should be set to around 1.5 times the amound of iscreen.amount.cores.

# iScreen
iscreen.amount.cores=4
iscreen.memory=6
This setting can be overriden by the user when sending a remote screening request from LigandScout or KNIME.

Info

These values should only be changed in conjuction with scheduler.number.processors.screening.


Similar to iscreen, it is also possible to configure the resource usage of idbgen sub-jobs, which is used for conformer generation.

# idbgen
idbgen.memory=4
idbgen.memory.slaves=3
These settings can be overriden by the user when sending a remote conformer generation request from LigandScout or KNIME.

Info

These values should only be changed in conjuction with scheduler.number.processors.confgen.


The iserver application is capable of splitting screening experiments and conformer generation jobs into multiple smaller sub-jobs. The following setting specifies how many compounds should be screened in a single virtual screening sub-job.

# Job Splitting
job.splitting.max.chunk.size= 2000000

The following figure shows the exploitation of multiple distributed-memory nodes via job splitting. If the database is screened using two separate sub-jobs, it is possible to exploit the full HPC cluster:

This setting can be overriden by the user when sending a remote screening request from LigandScout or KNIME. By default, splitting is only done per database chunk.


Similar to virtual screening, job splitting is also done for conformer generation. The following setting specifies how many input compounds should be used for each idbgen sub-job.

job.splitting.max.chunk.size.confgen = 10000

This setting can be overriden by the user when sending a remote conformer generation request from LigandScout or KNIME.

Data Management

This setting allows to enable automatic merging of output database chunks after a remote conformer generation job has finished. Per default, each sub-job creates one database chunk. Those are not merged, but only placed into a common folder.

merge.confgen.databases=false


If this parameter is set to true, the files belonging to specific virtual screening or conformer generation jobs are moved to a user defined location (see below), after the job is completed.

Info

For conformer generation, this does not concern the output screening databases, but only the log and input files. The location of the output databases is given with job.confgen.databases.directory. However, in the case of virtual screening, this also concerns the output files (i.e. hit lists).

If move_finished_jobs is set to true, the below setting specifies the location to which the files associated to jobs are moved.

# Directory to which finished and cancelled jobs will be moved if
# move_finished_jobs is set to true.
# The <user> placeholder will be replaced with the name of the
# user who started the job. Note that the server application has to be able to
# write to the respective directorie(s).
finished_jobs_directory=/home/<user>/jobs

Logging properties

It is possible to specify the directory that iserver will use for storing log files. This is especially important if iserver does not have write access to its own installation directory.

logging.directory=./logs

The remaining logging properties are mainly relevant for developers who wish to see more detailed logging output.

# DEBUG setting will produce A LOT more logging output,
# interesting only for developers
logging.level.root=INFO
logging.level.org.springframework.web: WARN
logging.level.com.tupilabs.pbs: WARN

Database properties

These settings allow to specify which relational database should be used for storing the metadata associated to virtual screening and conformer generation jobs. By default, an embedded H2 database is used, which requires no further configuration. The iserver application has also been tested extensively with MySQL, but should work with any relational database management system.

spring.datasource.url=jdbc:h2:./database/ilib-server;AUTO_SERVER=TRUE;MVCC=true
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=admin
spring.datasource.password=password
spring.jpa.generate-ddl=true
spring.jpa.show-sql=false
spring.jpa.hibernate.ddl-auto=create-update
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect
spring.jpa.hibernate.use-new-id-generator-mappings=true 
spring.h2.console.enabled=true
spring.h2.console.path=/console/

Tomcat properties

The first set of Tomcat properties specify how the embedded web server should log the incoming requests. The default settings should be fine for most users.

server.tomcat.basedir=./tomcat/tomcat-logs
server.tomcat.accesslog.enabled=true
server.tomcat.accesslog.pattern=%t %a "%r" %s (%D ms)


The following properties specify the maximum file size that can be uploaded to iserver.

The default values should be increased if large input files for conformer generation have to be uploaded. In case existing screening databases (.ldb) should be uploaded, the values might have to be increased substantually (e.g. 32768MB). Please make sure that the server host provides enough disk space if large uploads are intended.

spring.http.multipart.max-file-size=1024MB
spring.http.multipart.max-request-size=1024MB


The following setting specifies which port iserver listens on for new job requests. Please note that it is not a problem if the firewall blocks access to this port. All traffic uses the SSH port, as illustrated in the figure below.

# Port on which the server application will listen for requests. Default: 8080
server.port = 8080

Default Configuration

The iserver application comes with an embedded default configuration. This means, that even if you delete settings keys in the application.properties file within the iserver installation folder, the default configuration still exists as a fallback.

Below, you can see the complete default configuration:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
######################################################################
# Mandatory Options
######################################################################
job.screening.directory=./jobs/screening
job.confgen.directory=./jobs/confgen

idbgen.path.executable=
iscreen.path.executable=
libsize.path.executable=
idbmerger.path.executable=

# directories considered by the monitoring process, which looks for newly added compound databases (.ldb format required)
ldb.directories=./ldb_databases
ldb.directories.monitoring.recursive=true

job.confgen.databases.directory=./ldb_databases/re-confgen

ldb.directories.upload = ./ldb_databases/upload



######################################################################
# Scheduler and Job-Splitting Parameters
######################################################################

# Possible values: sge, pbs, torque
scheduler=sge

scheduler.number.processors.screening=2
scheduler.number.processors.confgen=4

# Priority  is an integer in the range -1023 to 1024. 
# Setting a value above 0 is only be possible if the server user has special permissions
scheduler.priority=0

# SGE
scheduler.sge.parallel.environment=smp
scheduler.sge.queue=all.q
scheduler.sge.option.string=

# iScreen
iscreen.amount.cores=4
iscreen.memory=6

# idbgen
idbgen.memory=4
idbgen.memory.slaves=3

# Job Splitting
job.splitting.max.chunk.size= 10000
job.splitting.max.chunk.size.confgen = 1000

##Data Management
merge.confgen.databases=false
move_finished_jobs=false
# Directory to which finished and cancelled jobs will be moved if move_finished_jobs is set to true.
# The <user> placeholder will be replaced with the name of the user who started the job. 
# Note that the server application has to be able to write to the respective directorie(s).
finished_jobs_directory=/home/<user>/jobs



######################################################################
# Logging properties
######################################################################
# DEBUG setting will produce A LOT more logging output, interesting only for developers
logging.level.root=INFO

logging.level.org.springframework.web: WARN
logging.level.com.tupilabs.pbs: WARN

logging.directory=./logs



######################################################################
#Database properties
######################################################################
spring.datasource.url=jdbc:h2:./database/ilib-server;AUTO_SERVER=TRUE;MVCC=true
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=admin
spring.datasource.password=password
spring.jpa.generate-ddl=true
spring.jpa.show-sql=false
spring.jpa.hibernate.ddl-auto=update
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect
spring.jpa.hibernate.use-new-id-generator-mappings=true 
spring.h2.console.enabled=true
spring.h2.console.path=/console/



######################################################################
# Tomcat properties
######################################################################
server.tomcat.basedir=./tomcat-logs
server.tomcat.accesslog.enabled=true
server.tomcat.accesslog.pattern=%t %a "%r" %s (%D ms)


spring.http.multipart.max-file-size=32768MB
spring.http.multipart.max-request-size=32768MB

# Port on which the server application will listen for requests. Default: 8080
server.port = 8080