Category Archives: Biochemistry

MCCCS Towhee 7.0.2

Towhee is a Monte Carlo molecular simulation code originally designed for the prediction of fluid phase equilibria using atom-based force fields and the Gibbs ensemble with particular attention paid to algorithms addressing molecule conformation sampling. The code has subsequently been extended to several ensembles, many different force fields, and solid (or at least porous) phases.

General Information

Towhee serves as a useful tool for the molecular simulation community and allows science to move forward more quickly by eliminating the need for individual research groups to rewrite routines that already exist and instead allows them to focus on algorithm advancement, force field development, and application to interesting systems.

Towhee may use different type of ensembles and Monte Carlo moves implemented into Towhee and can alos used different  force fields included with the distribution. (See here for more information )

How to Use

send_towhee

  • To send Towhee to the queue system  use the send_gulp utility. When executed,
    shows the command syntax, which is summarized below:
  • send_towhee JOBNAME NODES PROCS_PER_NODE TIME [ MEM ] [``Other queue options'' ]
JOBNAME: Is the  name of the Output.
NODES: Number of nodes.
PROCS: Number of  processors.
TIME: Time requested to the queue system, format hh:mm:ss.
MEM: Optional. Memory in Gb ( It will used 1GB/core if not set).
[``Other Torque Options'' ] Optional. There is the possibility to pass more variables to the queuing system.
See examples below.   More information about this options

Examples

We send a Towhee job1 to 1 node, 4 processors on that node, with a requested time of 4 hours . The results will be in the OUT file.

send_towhee OUT 1 4 04:00:00

We send job2  to 2 compuation nodes, 8 processors on each node, with a requested time of 192 hours, 8 GB of RAM and to start running after work 1234.arinab is finished:

send_towhee OUT 2 8 192:00:00 8 ``-W depend=afterany:1234'

We  send the input job3 to 4 nodes and 4 processors on each node, with arequested time of 200:00:00 hours, 2 GB of RAM and we request to be send an email at the beginning and end of the calculation to the direction specified.

send_towhee OUT 4 4 200:00:00 2 ``-m be -M mi.email@ehu.es''

send_towhee command copies the contents of the directory from which the job is sent to /scratch or / gscratch, if we use 2 or more nodes. And there is where the calculation is done.

Jobs Monitoring

To facilitate monitoring and/or control of the Towhee calculations, you can use remote_vi

remote_vi JOBID

It show us the *.out file  (only if it was sent using send_towhee).

More information

http://towhee.sourceforge.net/

Gulp 4.0

General Information

GULP is a program for performing a variety of types of simulation on materials using boundary conditions of 0-D (molecules and clusters), 1-D (polymers), 2-D (surfaces, slabs and grain boundaries), or 3-D (periodic solids). The focus of the code is on analytical solutions, through the use of lattice dynamics, where possible, rather than on molecular dynamics. A variety of force fields can be used within GULP spanning the shell model for ionic materials, molecular mechanics for organic systems, the embedded atom model for metals and the reactive REBO potential for hydrocarbons. Analytic derivatives are included up to at least second order for most force fields, and to third order for many.

How to Use

First, before you use it, be aware of its usage conditions.

send_gulp

  • To send GULP to the queue system  use the send_gulp utility. When executed,
    shows the command syntax, which is summarized below:
  • send_gulp JOBNAME NODES PROCS_PER_NODE TIME [ MEM ] [``Other queue options'' ]
JOBNAME: Is the  name of the input with extension.
NODES: Number of nodes.
PROCS: Number of  processors.
TIME: Time requested to the queue system, format hh:mm:ss.
MEM: Optional. Memory in Gb ( It will used 1GB/core if not set).
[``Other Torque Options'' ] Optional. There is the possibility to pass more variables to the queuing system.
See examples below.   More information about this options

Examples

We send the GULP input job1 to 1 node, 4 processors on that node, with a requested time of 4 hours :

send_gulp job1.gin 1 4 04:00:00

We send job2  to 2 compuation nodes, 8 processors on each node, with a requested time of 192 hours, 8 GB of RAM and to start running after work 1234.arinab is finished:

send_gulp job2.gin 2 8 192:00:00 8 ``-W depend=afterany:1234'

We  send the input job3 to 4 nodes and 4 processors on each node, with arequested time of 200:00:00 hours, 2 GB of RAM and we request to be send an email at the beginning and end of the calculation to the direction specified.

send_gulp job.gin 4 4 200:00:00 2 ``-m be -M mi.email@ehu.es''

send_gulp command copies the contents of the directory from which the job is sent to /scratch or / gscratch, if we use 2 or more nodes. And there is where the calculation is done.

Jobs Monitoring

To facilitate monitoring and/or control of the GULP calculations, you can use remote_vi

remote_vi JOBID

It show us the *.out file  (only if it was sent using send_lmp).

More information

http://projects.ivec.org/gulp/

LAMMPS

LAMMPS (“Large-scale Atomic/Molecular Massively Parallel Simulator”) is a molecular dynamics program from Sandia National Laboratories. LAMMPS makes use of MPI for parallel communication and is a free open-source code, distributed under the terms of the GNU General Public License.
LAMMPS was originally developed under a Cooperative Research and Development Agreement (CRADA) between two laboratories from United States Department of Energy and three other laboratories from private sector firms. It is currently maintained and distributed by researchers at the Sandia National Laboratories. (Taken from Wikipedia). Jun-05-2019 version.

General Information

LAMMPS is a classical molecular dynamics code that models an ensemble of particles in a liquid, solid, or gaseous state. It can model atomic, polymeric, biological, metallic, granular, and coarse-grained systems using a variety of force fields and boundary conditions.

In the most general sense, LAMMPS integrates Newton’s equations of motion for collections of atoms, molecules, or macroscopic particles that interact via short- or long-range forces with a variety of initial and/or boundary conditions. For computational efficiency LAMMPS uses neighbor lists to keep track of nearby particles. The lists are optimized for systems with particles that are repulsive at short distances, so that the local density of particles never becomes too large. On parallel machines, LAMMPS uses spatial-decomposition techniques to partition the simulation domain into small 3d sub-domains, one of which is assigned to each processor. Processors communicate and store “ghost” atom information for atoms that border their sub-domain. LAMMPS is most efficient (in a parallel sense) for systems whose particles fill a 3d rectangular box with roughly uniform density. Papers with technical details of the algorithms used in LAMMPS are listed in this section.

How to Use

send_lmp

  • To send LAMMPS to the queue system  use the send_lmp utility. When executed,
    shows the command syntax, which is summarized below:
  • send_lmp JOBNAME NODES PROCS_PER_NODE TIME [ MEM ] [``Other queue options'' ]
    JOBNAME: Is the  name of the input with extension.
    NODES: Number of nodes.
    PROCS: Number of  processors.
    TIME: Time requested to the queue system, format hh:mm:ss.
    MEM: Optional. Memory in Gb ( It will used 1GB/core if not set).
    [``Other Torque Options'' ] Optional. There is the possibility to pass more variables to the queuing system.
    See examples below.   More information about this options

Examples

We send the lammps input job1 to 1 node, 4 processors on that node, with a requested time of 4 hours:

send_lmp job1.in 1 4 04:00:00

We send job2  to 2 compuation nodes, 8 processors on each node, with a requested time of 192 hours, 8 GB of RAM and to start running after work 1234.arinab is finished:

send_lmp job2.inp 2 8 192:00:00 8 ``-W depend=afterany:1234'

We  send the input job3 to 4 nodes and 4 processors on each node, with arequested time of 200:00:00 hours, 2 GB of RAM and we request to be send an email at the beginning and end of the calculation to the direction specified.

send_lmp job.tpr 4 4 200:00:00 2 ``-m be -M mi.email@ehu.es''

send_lmp command copies the contents of the directory from which the job is sent to /scratch or / gscratch, if we use 2 or more nodes. And there is where the calculation is done.

Jobs Monitoring

To facilitate monitoring and/or control of the LAMMPS calculations, you can use remote_vi

remote_vi JOBID

It show us the *.out file  (only if it was sent using send_lmp).

More information

http://lammps.sandia.gov

DL_POLY

General information

4.02 version of the MD program for macromolecules, polymers, ionic systems, solutions and other molecular systems. Developed at the Daresbury Laboratory. In Pendulo the 2.2 version remains. There is already the DL_POLY_CLASSIC version which currently is not been developed.

How to submit to the queue

The program is installed in all the architectures, Arina and Pendulo (DL_POLY 2.2). To execute it include in the scripts:

/software/bin/DL_POLY/DL_POLY.Z

The program will exekute in GPGPUs if it starts in these kind of nodes. Besides, they can be selected by using the gpu label within [intlink id=”244″ type=”post”]the queue system[/intlink].

The GUI is also installed. To execute it use:

/software/bin/DL_POLY/gui

Some utilities has been installed in the /software/bin/DL_POLY/ directory.

Benchmark

We show a small benchmarks performed with dl_ploly_4.02. We stady the parallelization as well as the performance of the GPGPUs.

System 1 cores 4 cores 8 cores 16 cores 32 cores 64 cores
Itanium 1.6 GHz 1500 419 248 149 92 61
Opteron 1230 503 264 166 74
Xeon 2.27 GHz 807 227 126 67 37 25

We show in the firs benchamrk that DL_POLY scales very well and that the xeon nodes are the fastest ones, so we recomend them for large jobs.

System 1 cores 2 cores 4 cores 8 cores 16 cores 32 cores
Itanium 1.6 GHz 2137 303 165 93 47
Opteron 1592 482 177 134 55
Xeon 2.27 GHz 848 180 92 48 28
1 GPGPU 125 114 104 102
2 GPGPU 77 72 69
4 GPGPU 53 50
8 GPGPU 37
System 1 cores 2 cores 4 cores 8 cores 16 cores 32 cores 64 cores
Xeon 2.27 GHz 2918 774 411 223 122 71
1 GPGPU 362 333 338 337
2 GPGPU 240 222 220
4 GPGPU 145 142
8 GPGPU 97

We show that the GPGPUs speedup the calculation but each time we double the number of GPGPUs the speed up is multiplied but only 1.5. Because of this for large number of GPGPUs or cores is better to use the paralelization over cores. For example, one node has 8 cores and 2 GPGPUS. The 2 GPGPUs need 220 s while 8 cores need 411 s. Still 4 GPGPUs are faster than 16 cores but 32 cores with 71 s are faster than 8 GPGPUs that need 97 s. Therefore, the GPGPUS can speedup jobs in PCs or single nodes, but for jobs that require higher parallelization the cores parallelization is more effective.

DL_POLY is designed for big systems and the use up to thousand of cores. According to the documentation:

The DL_POLY_4 parallel performance and efficiency are considered very-good-to-excellent as long as (i) all CPU cores are loaded
with no less than 500 particles each and (ii) the major linked cells algorithm has no dimension less than 4.

More information

DL_POLY web page.

DL_POLY user guide (pdf).

DL_POLY GUI user guide (pdf).

GROMACS

General information

2018 version. GROMACS is a versatile package to perform molecular dynamics, i.e. simulate the Newtonian equations of motion for systems with hundreds to millions of particles.

It is primarily designed for biochemical molecules like proteins, lipids and nucleic acids that have a lot of complicated bonded interactions, but since GROMACS is extremely fast at calculating the nonbonded interactions (that usually dominate simulations) many groups are also using it for research on non-biological systems, e.g. polymers.

How to use

send_gmx

To send gromacs to the queue system  use the send_gmx utility. When executed, shows the command syntax, which is summarized below:

send_gmx ``JOB and Options'' NODES PROCS_PER_NODE TIME MEM [``Other queue options'']
``JOB and Options'': options for the calculation and input of GROMACS name extension. It is very important to keep the quotes.
NODES: Number of nodes.
PROCS: Number of  processors.
TIME: Time requested to the queue system, format hh:mm:ss.
MEM: Memory in Gb.
[``Otras opciones de Torque'' ] There is the possibility to pass more variables to the queuing system.
See examples below.  [intlink id=”244″ type=”post”] More information about this options[/intlink]

Examples

We send the gromacs input job1 to 1 node, 4 processors on that node, with a requested time of 4 hours and 1 GB of RAM:

send_gmx ``-s job1.tpr'' 1 4 04:00:00 1

We send job2  to 2 compuation nodes, 8 processors on each node, with a requested time of 192 hours, 8 GB of RAM and to start running after work 1234.arinab is finished:

send_gmx ``-s job2.tpr'' 2 8 192:00:00 8 ``-W depend=afterany:1234'

We  send the input job3 to 4 nodes and 4 processors on each node, with a requested time of 200:00:00 hours, 2 GB of RAM and we request to be send an email at the  beginning and end of the calculation to the direction specified.

send_gmx ``-s  job.tpr'' 4 4 200:00:00 2 ``-m be -M mi.email@ehu.es''

send_gmx command copies the contents of the directory from which the job is sent to /scratch or /gscratch, if we use 2 or more nodes. And there is where the calculation is done.

Jobs Monitoring

To facilitate monitoring and/or control of the gromacs calculations, you can use remote_vi which shows the md.log file (only if it was sent using send_gmx).

More information

http://www.gromacs.org/About_Gromacs