git-svn-id: svn://svn.icms.temple.edu/lammps-ro/trunk@14945 f3b2605a-c512-4ea7-a41b-209d697bcdaa
This commit is contained in:
sjplimp
426
doc/Manual.html
426
doc/Manual.html
@ -1,426 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>LAMMPS Documentation — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
<link rel="next" title="1. Introduction" href="Section_intro.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="#" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="#">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="#">Docs</a> »</li>
|
||||
|
||||
<li>LAMMPS Documentation</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
<div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_intro.html" class="btn btn-neutral float-right" title="1. Introduction" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<H1></H1><div class="section" id="lammps-documentation">
|
||||
<h1>LAMMPS Documentation<a class="headerlink" href="#lammps-documentation" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="may-2016-version">
|
||||
<h2>3 May 2016 version<a class="headerlink" href="#may-2016-version" title="Permalink to this headline">¶</a></h2>
|
||||
</div>
|
||||
<div class="section" id="version-info">
|
||||
<h2>Version info:<a class="headerlink" href="#version-info" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The LAMMPS “version” is the date when it was released, such as 1 May
|
||||
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
|
||||
feature, we release it immediately, and post a notice on <a class="reference external" href="http://lammps.sandia.gov/bug.html">this page of the WWW site</a>. Each dated copy of LAMMPS contains all the
|
||||
features and bug-fixes up to and including that version date. The
|
||||
version date is printed to the screen and logfile every time you run
|
||||
LAMMPS. It is also in the file src/version.h and in the LAMMPS
|
||||
directory name created when you unpack a tarball, and at the top of
|
||||
the first page of the manual (this page).</p>
|
||||
<ul class="simple">
|
||||
<li>If you browse the HTML doc pages on the LAMMPS WWW site, they always
|
||||
describe the most current version of LAMMPS.</li>
|
||||
<li>If you browse the HTML doc pages included in your tarball, they
|
||||
describe the version you have.</li>
|
||||
<li>The <a class="reference external" href="Manual.pdf">PDF file</a> on the WWW site or in the tarball is updated
|
||||
about once per month. This is because it is large, and we don’t want
|
||||
it to be part of every patch.</li>
|
||||
<li>There is also a <a class="reference external" href="Developer.pdf">Developer.pdf</a> file in the doc
|
||||
directory, which describes the internal structure and algorithms of
|
||||
LAMMPS.</li>
|
||||
</ul>
|
||||
<p>LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
|
||||
Simulator.</p>
|
||||
<p>LAMMPS is a classical molecular dynamics simulation code designed to
|
||||
run efficiently on parallel computers. It was developed at Sandia
|
||||
National Laboratories, a US Department of Energy facility, with
|
||||
funding from the DOE. It is an open-source code, distributed freely
|
||||
under the terms of the GNU Public License (GPL).</p>
|
||||
<p>The primary developers of LAMMPS are <a class="reference external" href="http://www.sandia.gov/~sjplimp">Steve Plimpton</a>, Aidan
|
||||
Thompson, and Paul Crozier who can be contacted at
|
||||
sjplimp,athomps,pscrozi at sandia.gov. The <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> at
|
||||
<a class="reference external" href="http://lammps.sandia.gov">http://lammps.sandia.gov</a> has more information about the code and its
|
||||
uses.</p>
|
||||
<hr class="docutils" />
|
||||
<p>The LAMMPS documentation is organized into the following sections. If
|
||||
you find errors or omissions in this manual or have suggestions for
|
||||
useful information to add, please send an email to the developers so
|
||||
we can improve the LAMMPS documentation.</p>
|
||||
<p>Once you are familiar with LAMMPS, you may want to bookmark <a class="reference internal" href="Section_commands.html#comm"><span>this page</span></a> at Section_commands.html#comm since
|
||||
it gives quick access to documentation for all LAMMPS commands.</p>
|
||||
<p><a class="reference external" href="Manual.pdf">PDF file</a> of the entire manual, generated by
|
||||
<a class="reference external" href="http://freecode.com/projects/htmldoc">htmldoc</a></p>
|
||||
<div class="toctree-wrapper compound">
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#what-is-lammps">1.1. What is LAMMPS</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#lammps-features">1.2. LAMMPS features</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#lammps-non-features">1.3. LAMMPS non-features</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#open-source-distribution">1.4. Open source distribution</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_intro.html#acknowledgments-and-citations">1.5. Acknowledgments and citations</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#what-s-in-the-lammps-distribution">2.1. What’s in the LAMMPS distribution</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps">2.2. Making LAMMPS</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#making-lammps-with-optional-packages">2.3. Making LAMMPS with optional packages</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-via-the-make-py-tool">2.4. Building LAMMPS via the Make.py tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#building-lammps-as-a-library">2.5. Building LAMMPS as a library</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#running-lammps">2.6. Running LAMMPS</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#command-line-options">2.7. Command-line options</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#lammps-screen-output">2.8. LAMMPS screen output</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_start.html#tips-for-users-of-previous-lammps-versions">2.9. Tips for users of previous LAMMPS versions</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#lammps-input-script">3.1. LAMMPS input script</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#parsing-rules">3.2. Parsing rules</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#input-script-structure">3.3. Input script structure</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#commands-listed-by-category">3.4. Commands listed by category</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#individual-commands">3.5. Individual commands</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#fix-styles">3.6. Fix styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#compute-styles">3.7. Compute styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#pair-style-potentials">3.8. Pair_style potentials</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#bond-style-potentials">3.9. Bond_style potentials</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#angle-style-potentials">3.10. Angle_style potentials</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#dihedral-style-potentials">3.11. Dihedral_style potentials</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#improper-style-potentials">3.12. Improper_style potentials</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_commands.html#kspace-solvers">3.13. Kspace solvers</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#standard-packages">4.1. Standard packages</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_packages.html#user-packages">4.2. User packages</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#measuring-performance">5.1. Measuring performance</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#general-strategies">5.2. General strategies</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_accelerate.html#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#restarting-a-simulation">6.1. Restarting a simulation</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#d-simulations">6.2. 2d simulations</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#charmm-amber-and-dreiding-force-fields">6.3. CHARMM, AMBER, and DREIDING force fields</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#running-multiple-simulations-from-one-input-script">6.4. Running multiple simulations from one input script</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#multi-replica-simulations">6.5. Multi-replica simulations</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#granular-models">6.6. Granular models</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip3p-water-model">6.7. TIP3P water model</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#tip4p-water-model">6.8. TIP4P water model</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#spc-water-model">6.9. SPC water model</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#coupling-lammps-to-other-codes">6.10. Coupling LAMMPS to other codes</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#visualizing-lammps-snapshots">6.11. Visualizing LAMMPS snapshots</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#triclinic-non-orthogonal-simulation-boxes">6.12. Triclinic (non-orthogonal) simulation boxes</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#nemd-simulations">6.13. NEMD simulations</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#finite-size-spherical-and-aspherical-particles">6.14. Finite-size spherical and aspherical particles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#output-from-lammps-thermo-dumps-computes-fixes-variables">6.15. Output from LAMMPS (thermo, dumps, computes, fixes, variables)</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#thermostatting-barostatting-and-computing-temperature">6.16. Thermostatting, barostatting, and computing temperature</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#walls">6.17. Walls</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#elastic-constants">6.18. Elastic constants</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#library-interface-to-lammps">6.19. Library interface to LAMMPS</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#calculating-thermal-conductivity">6.20. Calculating thermal conductivity</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#calculating-viscosity">6.21. Calculating viscosity</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#calculating-a-diffusion-coefficient">6.22. Calculating a diffusion coefficient</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#using-chunks-to-calculate-system-properties">6.23. Using chunks to calculate system properties</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#setting-parameters-for-the-kspace-style-pppm-disp-command">6.24. Setting parameters for the <code class="docutils literal"><span class="pre">kspace_style</span> <span class="pre">pppm/disp</span></code> command</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#polarizable-models">6.25. Polarizable models</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#adiabatic-core-shell-model">6.26. Adiabatic core/shell model</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_howto.html#drude-induced-dipoles">6.27. Drude induced dipoles</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_example.html#lowercase-directories">7.1. Lowercase directories</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_example.html#uppercase-directories">7.2. Uppercase directories</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#amber2lmp-tool">9.1. amber2lmp tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#binary2txt-tool">9.2. binary2txt tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#ch2lmp-tool">9.3. ch2lmp tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#chain-tool">9.4. chain tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#colvars-tools">9.5. colvars tools</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#createatoms-tool">9.6. createatoms tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#data2xmovie-tool">9.7. data2xmovie tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#eam-database-tool">9.8. eam database tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#eam-generate-tool">9.9. eam generate tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#eff-tool">9.10. eff tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#emacs-tool">9.11. emacs tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#fep-tool">9.12. fep tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#i-pi-tool">9.13. i-pi tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#ipp-tool">9.14. ipp tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#kate-tool">9.15. kate tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#lmp2arc-tool">9.16. lmp2arc tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#lmp2cfg-tool">9.17. lmp2cfg tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#lmp2vmd-tool">9.18. lmp2vmd tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#matlab-tool">9.19. matlab tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#micelle2d-tool">9.20. micelle2d tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#moltemplate-tool">9.21. moltemplate tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#msi2lmp-tool">9.22. msi2lmp tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#phonon-tool">9.23. phonon tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#polymer-bonding-tool">9.24. polymer bonding tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#pymol-asphere-tool">9.25. pymol_asphere tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#python-tool">9.26. python tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#reax-tool">9.27. reax tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#restart2data-tool">9.28. restart2data tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#vim-tool">9.29. vim tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#xmgrace-tool">9.30. xmgrace tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_tools.html#xmovie-tool">9.31. xmovie tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#atom-styles">10.1. Atom styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#bond-angle-dihedral-improper-potentials">10.2. Bond, angle, dihedral, improper potentials</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#compute-styles">10.3. Compute styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#dump-styles">10.4. Dump styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#dump-custom-output-options">10.5. Dump custom output options</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#fix-styles">10.6. Fix styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#input-script-commands">10.7. Input script commands</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#kspace-computations">10.8. Kspace computations</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#minimization-styles">10.9. Minimization styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#pairwise-potentials">10.10. Pairwise potentials</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#region-styles">10.11. Region styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#body-styles">10.12. Body styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#thermodynamic-output-options">10.13. Thermodynamic output options</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#variable-options">10.14. Variable options</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_modify.html#submitting-new-features-for-inclusion-in-lammps">10.15. Submitting new features for inclusion in LAMMPS</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-running-lammps-from-python">11.1. Overview of running LAMMPS from Python</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#overview-of-using-python-from-a-lammps-script">11.2. Overview of using Python from a LAMMPS script</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#building-lammps-as-a-shared-library">11.3. Building LAMMPS as a shared library</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#installing-the-python-wrapper-into-python">11.4. Installing the Python wrapper into Python</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#extending-python-with-mpi-to-run-in-parallel">11.5. Extending Python with MPI to run in parallel</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#testing-the-python-lammps-interface">11.6. Testing the Python-LAMMPS interface</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#using-lammps-from-python">11.7. Using LAMMPS from Python</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_python.html#example-python-scripts-that-use-lammps">11.8. Example Python scripts that use LAMMPS</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#common-problems">12.1. Common problems</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#reporting-bugs">12.2. Reporting bugs</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#error-warning-messages">12.3. Error & warning messages</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#error">12.4. Errors:</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_errors.html#warnings">12.5. Warnings:</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_history.html#coming-attractions">13.1. Coming attractions</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="Section_history.html#past-versions">13.2. Past versions</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="indices-and-tables">
|
||||
<h1>Indices and tables<a class="headerlink" href="#indices-and-tables" title="Permalink to this headline">¶</a></h1>
|
||||
<ul class="simple">
|
||||
<li><a class="reference internal" href="genindex.html"><span>Index</span></a></li>
|
||||
<li><a class="reference internal" href="search.html"><span>Search Page</span></a></li>
|
||||
</ul>
|
||||
</BODY></div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_intro.html" class="btn btn-neutral float-right" title="1. Introduction" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
304
doc/Manual.txt
304
doc/Manual.txt
@ -1,304 +0,0 @@
|
||||
<!-- HTML_ONLY -->
|
||||
<HEAD>
|
||||
<TITLE>LAMMPS Users Manual</TITLE>
|
||||
<META NAME="docnumber" CONTENT="3 May 2016 version">
|
||||
<META NAME="author" CONTENT="http://lammps.sandia.gov - Sandia National Laboratories">
|
||||
<META NAME="copyright" CONTENT="Copyright (2003) Sandia Corporation. This software and manual is distributed under the GNU General Public License.">
|
||||
</HEAD>
|
||||
|
||||
<BODY>
|
||||
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
<H1></H1>
|
||||
|
||||
LAMMPS Documentation :c,h3
|
||||
3 May 2016 version :c,h4
|
||||
|
||||
Version info: :h4
|
||||
|
||||
The LAMMPS "version" is the date when it was released, such as 1 May
|
||||
2010. LAMMPS is updated continuously. Whenever we fix a bug or add a
|
||||
feature, we release it immediately, and post a notice on "this page of
|
||||
the WWW site"_bug. Each dated copy of LAMMPS contains all the
|
||||
features and bug-fixes up to and including that version date. The
|
||||
version date is printed to the screen and logfile every time you run
|
||||
LAMMPS. It is also in the file src/version.h and in the LAMMPS
|
||||
directory name created when you unpack a tarball, and at the top of
|
||||
the first page of the manual (this page).
|
||||
|
||||
If you browse the HTML doc pages on the LAMMPS WWW site, they always
|
||||
describe the most current version of LAMMPS. :ulb,l
|
||||
|
||||
If you browse the HTML doc pages included in your tarball, they
|
||||
describe the version you have. :l
|
||||
|
||||
The "PDF file"_Manual.pdf on the WWW site or in the tarball is updated
|
||||
about once per month. This is because it is large, and we don't want
|
||||
it to be part of every patch. :l
|
||||
|
||||
There is also a "Developer.pdf"_Developer.pdf file in the doc
|
||||
directory, which describes the internal structure and algorithms of
|
||||
LAMMPS. :ule,l
|
||||
|
||||
LAMMPS stands for Large-scale Atomic/Molecular Massively Parallel
|
||||
Simulator.
|
||||
|
||||
LAMMPS is a classical molecular dynamics simulation code designed to
|
||||
run efficiently on parallel computers. It was developed at Sandia
|
||||
National Laboratories, a US Department of Energy facility, with
|
||||
funding from the DOE. It is an open-source code, distributed freely
|
||||
under the terms of the GNU Public License (GPL).
|
||||
|
||||
The primary developers of LAMMPS are "Steve Plimpton"_sjp, Aidan
|
||||
Thompson, and Paul Crozier who can be contacted at
|
||||
sjplimp,athomps,pscrozi at sandia.gov. The "LAMMPS WWW Site"_lws at
|
||||
http://lammps.sandia.gov has more information about the code and its
|
||||
uses.
|
||||
|
||||
:link(bug,http://lammps.sandia.gov/bug.html)
|
||||
:link(sjp,http://www.sandia.gov/~sjplimp)
|
||||
|
||||
:line
|
||||
|
||||
The LAMMPS documentation is organized into the following sections. If
|
||||
you find errors or omissions in this manual or have suggestions for
|
||||
useful information to add, please send an email to the developers so
|
||||
we can improve the LAMMPS documentation.
|
||||
|
||||
Once you are familiar with LAMMPS, you may want to bookmark "this
|
||||
page"_Section_commands.html#comm at Section_commands.html#comm since
|
||||
it gives quick access to documentation for all LAMMPS commands.
|
||||
|
||||
"PDF file"_Manual.pdf of the entire manual, generated by
|
||||
"htmldoc"_http://freecode.com/projects/htmldoc
|
||||
|
||||
<!-- RST
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:numbered:
|
||||
|
||||
Section_intro
|
||||
Section_start
|
||||
Section_commands
|
||||
Section_packages
|
||||
Section_accelerate
|
||||
Section_howto
|
||||
Section_example
|
||||
Section_perf
|
||||
Section_tools
|
||||
Section_modify
|
||||
Section_python
|
||||
Section_errors
|
||||
Section_history
|
||||
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
* :ref:`genindex`
|
||||
* :ref:`search`
|
||||
|
||||
END_RST -->
|
||||
|
||||
<!-- HTML_ONLY -->
|
||||
"Introduction"_Section_intro.html :olb,l
|
||||
1.1 "What is LAMMPS"_intro_1 :ulb,b
|
||||
1.2 "LAMMPS features"_intro_2 :b
|
||||
1.3 "LAMMPS non-features"_intro_3 :b
|
||||
1.4 "Open source distribution"_intro_4 :b
|
||||
1.5 "Acknowledgments and citations"_intro_5 :ule,b
|
||||
"Getting started"_Section_start.html :l
|
||||
2.1 "What's in the LAMMPS distribution"_start_1 :ulb,b
|
||||
2.2 "Making LAMMPS"_start_2 :b
|
||||
2.3 "Making LAMMPS with optional packages"_start_3 :b
|
||||
2.4 "Building LAMMPS via the Make.py script"_start_4 :b
|
||||
2.5 "Building LAMMPS as a library"_start_5 :b
|
||||
2.6 "Running LAMMPS"_start_6 :b
|
||||
2.7 "Command-line options"_start_7 :b
|
||||
2.8 "Screen output"_start_8 :b
|
||||
2.9 "Tips for users of previous versions"_start_9 :ule,b
|
||||
"Commands"_Section_commands.html :l
|
||||
3.1 "LAMMPS input script"_cmd_1 :ulb,b
|
||||
3.2 "Parsing rules"_cmd_2 :b
|
||||
3.3 "Input script structure"_cmd_3 :b
|
||||
3.4 "Commands listed by category"_cmd_4 :b
|
||||
3.5 "Commands listed alphabetically"_cmd_5 :ule,b
|
||||
"Packages"_Section_packages.html :l
|
||||
4.1 "Standard packages"_pkg_1 :ulb,b
|
||||
4.2 "User packages"_pkg_2 :ule,b
|
||||
"Accelerating LAMMPS performance"_Section_accelerate.html :l
|
||||
5.1 "Measuring performance"_acc_1 :ulb,b
|
||||
5.2 "Algorithms and code options to boost performace"_acc_2 :b
|
||||
5.3 "Accelerator packages with optimized styles"_acc_3 :b
|
||||
5.3.1 "USER-CUDA package"_accelerate_cuda.html :ulb,b
|
||||
5.3.2 "GPU package"_accelerate_gpu.html :b
|
||||
5.3.3 "USER-INTEL package"_accelerate_intel.html :b
|
||||
5.3.4 "KOKKOS package"_accelerate_kokkos.html :b
|
||||
5.3.5 "USER-OMP package"_accelerate_omp.html :b
|
||||
5.3.6 "OPT package"_accelerate_opt.html :ule,b
|
||||
5.4 "Comparison of various accelerator packages"_acc_4 :ule,b
|
||||
"How-to discussions"_Section_howto.html :l
|
||||
6.1 "Restarting a simulation"_howto_1 :ulb,b
|
||||
6.2 "2d simulations"_howto_2 :b
|
||||
6.3 "CHARMM and AMBER force fields"_howto_3 :b
|
||||
6.4 "Running multiple simulations from one input script"_howto_4 :b
|
||||
6.5 "Multi-replica simulations"_howto_5 :b
|
||||
6.6 "Granular models"_howto_6 :b
|
||||
6.7 "TIP3P water model"_howto_7 :b
|
||||
6.8 "TIP4P water model"_howto_8 :b
|
||||
6.9 "SPC water model"_howto_9 :b
|
||||
6.10 "Coupling LAMMPS to other codes"_howto_10 :b
|
||||
6.11 "Visualizing LAMMPS snapshots"_howto_11 :b
|
||||
6.12 "Triclinic (non-orthogonal) simulation boxes"_howto_12 :b
|
||||
6.13 "NEMD simulations"_howto_13 :b
|
||||
6.14 "Finite-size spherical and aspherical particles"_howto_14 :b
|
||||
6.15 "Output from LAMMPS (thermo, dumps, computes, fixes, variables)"_howto_15 :b
|
||||
6.16 "Thermostatting, barostatting, and compute temperature"_howto_16 :b
|
||||
6.17 "Walls"_howto_17 :b
|
||||
6.18 "Elastic constants"_howto_18 :b
|
||||
6.19 "Library interface to LAMMPS"_howto_19 :b
|
||||
6.20 "Calculating thermal conductivity"_howto_20 :b
|
||||
6.21 "Calculating viscosity"_howto_21 :b
|
||||
6.22 "Calculating a diffusion coefficient"_howto_22 :b
|
||||
6.23 "Using chunks to calculate system properties"_howto_23 :b
|
||||
6.24 "Setting parameters for pppm/disp"_howto_24 :b
|
||||
6.25 "Polarizable models"_howto_25 :b
|
||||
6.26 "Adiabatic core/shell model"_howto_26 :b
|
||||
6.27 "Drude induced dipoles"_howto_27 :ule,b
|
||||
"Example problems"_Section_example.html :l
|
||||
"Performance & scalability"_Section_perf.html :l
|
||||
"Additional tools"_Section_tools.html :l
|
||||
"Modifying & extending LAMMPS"_Section_modify.html :l
|
||||
10.1 "Atom styles"_mod_1 :ulb,b
|
||||
10.2 "Bond, angle, dihedral, improper potentials"_mod_2 :b
|
||||
10.3 "Compute styles"_mod_3 :b
|
||||
10.4 "Dump styles"_mod_4 :b
|
||||
10.5 "Dump custom output options"_mod_5 :b
|
||||
10.6 "Fix styles"_mod_6 :b
|
||||
10.7 "Input script commands"_mod_7 :b
|
||||
10.8 "Kspace computations"_mod_8 :b
|
||||
10.9 "Minimization styles"_mod_9 :b
|
||||
10.10 "Pairwise potentials"_mod_10 :b
|
||||
10.11 "Region styles"_mod_11 :b
|
||||
10.12 "Body styles"_mod_12 :b
|
||||
10.13 "Thermodynamic output options"_mod_13 :b
|
||||
10.14 "Variable options"_mod_14 :b
|
||||
10.15 "Submitting new features for inclusion in LAMMPS"_mod_15 :ule,b
|
||||
"Python interface"_Section_python.html :l
|
||||
11.1 "Overview of running LAMMPS from Python"_py_1 :ulb,b
|
||||
11.2 "Overview of using Python from a LAMMPS script"_py_2 :b
|
||||
11.3 "Building LAMMPS as a shared library"_py_3 :b
|
||||
11.4 "Installing the Python wrapper into Python"_py_4 :b
|
||||
11.5 "Extending Python with MPI to run in parallel"_py_5 :b
|
||||
11.6 "Testing the Python-LAMMPS interface"_py_6 :b
|
||||
11.7 "Using LAMMPS from Python"_py_7 :b
|
||||
11.8 "Example Python scripts that use LAMMPS"_py_8 :ule,b
|
||||
"Errors"_Section_errors.html :l
|
||||
12.1 "Common problems"_err_1 :ulb,b
|
||||
12.2 "Reporting bugs"_err_2 :b
|
||||
12.3 "Error & warning messages"_err_3 :ule,b
|
||||
"Future and history"_Section_history.html :l
|
||||
13.1 "Coming attractions"_hist_1 :ulb,b
|
||||
13.2 "Past versions"_hist_2 :ule,b
|
||||
:ole
|
||||
|
||||
:link(intro_1,Section_intro.html#intro_1)
|
||||
:link(intro_2,Section_intro.html#intro_2)
|
||||
:link(intro_3,Section_intro.html#intro_3)
|
||||
:link(intro_4,Section_intro.html#intro_4)
|
||||
:link(intro_5,Section_intro.html#intro_5)
|
||||
|
||||
:link(start_1,Section_start.html#start_1)
|
||||
:link(start_2,Section_start.html#start_2)
|
||||
:link(start_3,Section_start.html#start_3)
|
||||
:link(start_4,Section_start.html#start_4)
|
||||
:link(start_5,Section_start.html#start_5)
|
||||
:link(start_6,Section_start.html#start_6)
|
||||
:link(start_7,Section_start.html#start_7)
|
||||
:link(start_8,Section_start.html#start_8)
|
||||
:link(start_9,Section_start.html#start_9)
|
||||
|
||||
:link(cmd_1,Section_commands.html#cmd_1)
|
||||
:link(cmd_2,Section_commands.html#cmd_2)
|
||||
:link(cmd_3,Section_commands.html#cmd_3)
|
||||
:link(cmd_4,Section_commands.html#cmd_4)
|
||||
:link(cmd_5,Section_commands.html#cmd_5)
|
||||
|
||||
:link(pkg_1,Section_packages.html#pkg_1)
|
||||
:link(pkg_2,Section_packages.html#pkg_2)
|
||||
|
||||
:link(acc_1,Section_accelerate.html#acc_1)
|
||||
:link(acc_2,Section_accelerate.html#acc_2)
|
||||
:link(acc_3,Section_accelerate.html#acc_3)
|
||||
:link(acc_4,Section_accelerate.html#acc_4)
|
||||
|
||||
:link(howto_1,Section_howto.html#howto_1)
|
||||
:link(howto_2,Section_howto.html#howto_2)
|
||||
:link(howto_3,Section_howto.html#howto_3)
|
||||
:link(howto_4,Section_howto.html#howto_4)
|
||||
:link(howto_5,Section_howto.html#howto_5)
|
||||
:link(howto_6,Section_howto.html#howto_6)
|
||||
:link(howto_7,Section_howto.html#howto_7)
|
||||
:link(howto_8,Section_howto.html#howto_8)
|
||||
:link(howto_9,Section_howto.html#howto_9)
|
||||
:link(howto_10,Section_howto.html#howto_10)
|
||||
:link(howto_11,Section_howto.html#howto_11)
|
||||
:link(howto_12,Section_howto.html#howto_12)
|
||||
:link(howto_13,Section_howto.html#howto_13)
|
||||
:link(howto_14,Section_howto.html#howto_14)
|
||||
:link(howto_15,Section_howto.html#howto_15)
|
||||
:link(howto_16,Section_howto.html#howto_16)
|
||||
:link(howto_17,Section_howto.html#howto_17)
|
||||
:link(howto_18,Section_howto.html#howto_18)
|
||||
:link(howto_19,Section_howto.html#howto_19)
|
||||
:link(howto_20,Section_howto.html#howto_20)
|
||||
:link(howto_21,Section_howto.html#howto_21)
|
||||
:link(howto_22,Section_howto.html#howto_22)
|
||||
:link(howto_23,Section_howto.html#howto_23)
|
||||
:link(howto_24,Section_howto.html#howto_24)
|
||||
:link(howto_25,Section_howto.html#howto_25)
|
||||
:link(howto_26,Section_howto.html#howto_26)
|
||||
:link(howto_27,Section_howto.html#howto_27)
|
||||
|
||||
:link(mod_1,Section_modify.html#mod_1)
|
||||
:link(mod_2,Section_modify.html#mod_2)
|
||||
:link(mod_3,Section_modify.html#mod_3)
|
||||
:link(mod_4,Section_modify.html#mod_4)
|
||||
:link(mod_5,Section_modify.html#mod_5)
|
||||
:link(mod_6,Section_modify.html#mod_6)
|
||||
:link(mod_7,Section_modify.html#mod_7)
|
||||
:link(mod_8,Section_modify.html#mod_8)
|
||||
:link(mod_9,Section_modify.html#mod_9)
|
||||
:link(mod_10,Section_modify.html#mod_10)
|
||||
:link(mod_11,Section_modify.html#mod_11)
|
||||
:link(mod_12,Section_modify.html#mod_12)
|
||||
:link(mod_13,Section_modify.html#mod_13)
|
||||
:link(mod_14,Section_modify.html#mod_14)
|
||||
:link(mod_15,Section_modify.html#mod_15)
|
||||
|
||||
:link(py_1,Section_python.html#py_1)
|
||||
:link(py_2,Section_python.html#py_2)
|
||||
:link(py_3,Section_python.html#py_3)
|
||||
:link(py_4,Section_python.html#py_4)
|
||||
:link(py_5,Section_python.html#py_5)
|
||||
:link(py_6,Section_python.html#py_6)
|
||||
|
||||
:link(err_1,Section_errors.html#err_1)
|
||||
:link(err_2,Section_errors.html#err_2)
|
||||
:link(err_3,Section_errors.html#err_3)
|
||||
|
||||
:link(hist_1,Section_history.html#hist_1)
|
||||
:link(hist_2,Section_history.html#hist_2)
|
||||
<!-- END_HTML_ONLY -->
|
||||
|
||||
</BODY>
|
||||
@ -1,642 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>5. Accelerating LAMMPS performance — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
<link rel="next" title="6. How-to discussions" href="Section_howto.html"/>
|
||||
<link rel="prev" title="4. Packages" href="Section_packages.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">5. Accelerating LAMMPS performance</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#measuring-performance">5.1. Measuring performance</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#general-strategies">5.2. General strategies</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#packages-with-optimized-styles">5.3. Packages with optimized styles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#comparison-of-various-accelerator-packages">5.4. Comparison of various accelerator packages</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#examples">5.4.1. Examples</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>5. Accelerating LAMMPS performance</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
<div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_howto.html" class="btn btn-neutral float-right" title="6. How-to discussions" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Section_packages.html" class="btn btn-neutral" title="4. Packages" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="accelerating-lammps-performance">
|
||||
<h1>5. Accelerating LAMMPS performance<a class="headerlink" href="#accelerating-lammps-performance" title="Permalink to this headline">¶</a></h1>
|
||||
<p>This section describes various methods for improving LAMMPS
|
||||
performance for different classes of problems running on different
|
||||
kinds of machines.</p>
|
||||
<p>There are two thrusts to the discussion that follows. The
|
||||
first is using code options that implement alternate algorithms
|
||||
that can speed-up a simulation. The second is to use one
|
||||
of the several accelerator packages provided with LAMMPS that
|
||||
contain code optimized for certain kinds of hardware, including
|
||||
multi-core CPUs, GPUs, and Intel Xeon Phi coprocessors.</p>
|
||||
<ul class="simple">
|
||||
<li>5.1 <a class="reference internal" href="#acc-1"><span>Measuring performance</span></a></li>
|
||||
<li>5.2 <a class="reference internal" href="#acc-2"><span>Algorithms and code options to boost performace</span></a></li>
|
||||
<li>5.3 <a class="reference internal" href="#acc-3"><span>Accelerator packages with optimized styles</span></a></li>
|
||||
<li>5.3.1 <a class="reference internal" href="accelerate_cuda.html"><em>USER-CUDA package</em></a></li>
|
||||
<li>5.3.2 <a class="reference internal" href="accelerate_gpu.html"><em>GPU package</em></a></li>
|
||||
<li>5.3.3 <a class="reference internal" href="accelerate_intel.html"><em>USER-INTEL package</em></a></li>
|
||||
<li>5.3.4 <a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS package</em></a></li>
|
||||
<li>5.3.5 <a class="reference internal" href="accelerate_omp.html"><em>USER-OMP package</em></a></li>
|
||||
<li>5.3.6 <a class="reference internal" href="accelerate_opt.html"><em>OPT package</em></a></li>
|
||||
<li>5.4 <a class="reference internal" href="#acc-4"><span>Comparison of various accelerator packages</span></a></li>
|
||||
</ul>
|
||||
<p>The <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the LAMMPS
|
||||
web site gives performance results for the various accelerator
|
||||
packages discussed in Section 5.2, for several of the standard LAMMPS
|
||||
benchmark problems, as a function of problem size and number of
|
||||
compute nodes, on different hardware platforms.</p>
|
||||
<div class="section" id="measuring-performance">
|
||||
<span id="acc-1"></span><h2>5.1. Measuring performance<a class="headerlink" href="#measuring-performance" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Before trying to make your simulation run faster, you should
|
||||
understand how it currently performs and where the bottlenecks are.</p>
|
||||
<p>The best way to do this is run the your system (actual number of
|
||||
atoms) for a modest number of timesteps (say 100 steps) on several
|
||||
different processor counts, including a single processor if possible.
|
||||
Do this for an equilibrium version of your system, so that the
|
||||
100-step timings are representative of a much longer run. There is
|
||||
typically no need to run for 1000s of timesteps to get accurate
|
||||
timings; you can simply extrapolate from short runs.</p>
|
||||
<p>For the set of runs, look at the timing data printed to the screen and
|
||||
log file at the end of each LAMMPS run. <a class="reference internal" href="Section_start.html#start-8"><span>This section</span></a> of the manual has an overview.</p>
|
||||
<p>Running on one (or a few processors) should give a good estimate of
|
||||
the serial performance and what portions of the timestep are taking
|
||||
the most time. Running the same problem on a few different processor
|
||||
counts should give an estimate of parallel scalability. I.e. if the
|
||||
simulation runs 16x faster on 16 processors, its 100% parallel
|
||||
efficient; if it runs 8x faster on 16 processors, it’s 50% efficient.</p>
|
||||
<p>The most important data to look at in the timing info is the timing
|
||||
breakdown and relative percentages. For example, trying different
|
||||
options for speeding up the long-range solvers will have little impact
|
||||
if they only consume 10% of the run time. If the pairwise time is
|
||||
dominating, you may want to look at GPU or OMP versions of the pair
|
||||
style, as discussed below. Comparing how the percentages change as
|
||||
you increase the processor count gives you a sense of how different
|
||||
operations within the timestep are scaling. Note that if you are
|
||||
running with a Kspace solver, there is additional output on the
|
||||
breakdown of the Kspace time. For PPPM, this includes the fraction
|
||||
spent on FFTs, which can be communication intensive.</p>
|
||||
<p>Another important detail in the timing info are the histograms of
|
||||
atoms counts and neighbor counts. If these vary widely across
|
||||
processors, you have a load-imbalance issue. This often results in
|
||||
inaccurate relative timing data, because processors have to wait when
|
||||
communication occurs for other processors to catch up. Thus the
|
||||
reported times for “Communication” or “Other” may be higher than they
|
||||
really are, due to load-imbalance. If this is an issue, you can
|
||||
uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
|
||||
LAMMPS, to obtain synchronized timings.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="general-strategies">
|
||||
<span id="acc-2"></span><h2>5.2. General strategies<a class="headerlink" href="#general-strategies" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">this section 5.2 is still a work in progress</p>
|
||||
</div>
|
||||
<p>Here is a list of general ideas for improving simulation performance.
|
||||
Most of them are only applicable to certain models and certain
|
||||
bottlenecks in the current performance, so let the timing data you
|
||||
generate be your guide. It is hard, if not impossible, to predict how
|
||||
much difference these options will make, since it is a function of
|
||||
problem size, number of processors used, and your machine. There is
|
||||
no substitute for identifying performance bottlenecks, and trying out
|
||||
various options.</p>
|
||||
<ul class="simple">
|
||||
<li>rRESPA</li>
|
||||
<li>2-FFT PPPM</li>
|
||||
<li>Staggered PPPM</li>
|
||||
<li>single vs double PPPM</li>
|
||||
<li>partial charge PPPM</li>
|
||||
<li>verlet/split run style</li>
|
||||
<li>processor command for proc layout and numa layout</li>
|
||||
<li>load-balancing: balance and fix balance</li>
|
||||
</ul>
|
||||
<p>2-FFT PPPM, also called <em>analytic differentiation</em> or <em>ad</em> PPPM, uses
|
||||
2 FFTs instead of the 4 FFTs used by the default <em>ik differentiation</em>
|
||||
PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
|
||||
achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
|
||||
cost is the performance bottleneck (typically large problems running
|
||||
on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.</p>
|
||||
<p>Staggered PPPM performs calculations using two different meshes, one
|
||||
shifted slightly with respect to the other. This can reduce force
|
||||
aliasing errors and increase the accuracy of the method, but also
|
||||
doubles the amount of work required. For high relative accuracy, using
|
||||
staggered PPPM allows one to half the mesh size in each dimension as
|
||||
compared to regular PPPM, which can give around a 4x speedup in the
|
||||
kspace time. However, for low relative accuracy, using staggered PPPM
|
||||
gives little benefit and can be up to 2x slower in the kspace
|
||||
time. For example, the rhodopsin benchmark was run on a single
|
||||
processor, and results for kspace time vs. relative accuracy for the
|
||||
different methods are shown in the figure below. For this system,
|
||||
staggered PPPM (using ik differentiation) becomes useful when using a
|
||||
relative accuracy of slightly greater than 1e-5 and above.</p>
|
||||
<img alt="_images/rhodo_staggered.jpg" class="align-center" src="_images/rhodo_staggered.jpg" />
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">Using staggered PPPM may not give the same increase in accuracy
|
||||
of energy and pressure as it does in forces, so some caution must be
|
||||
used if energy and/or pressure are quantities of interest, such as
|
||||
when using a barostat.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="packages-with-optimized-styles">
|
||||
<span id="acc-3"></span><h2>5.3. Packages with optimized styles<a class="headerlink" href="#packages-with-optimized-styles" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Accelerated versions of various <a class="reference internal" href="pair_style.html"><em>pair_style</em></a>,
|
||||
<a class="reference internal" href="fix.html"><em>fixes</em></a>, <a class="reference internal" href="compute.html"><em>computes</em></a>, and other commands have
|
||||
been added to LAMMPS, which will typically run faster than the
|
||||
standard non-accelerated versions. Some require appropriate hardware
|
||||
to be present on your system, e.g. GPUs or Intel Xeon Phi
|
||||
coprocessors.</p>
|
||||
<p>All of these commands are in packages provided with LAMMPS. An
|
||||
overview of packages is give in <a class="reference internal" href="Section_packages.html"><em>Section packages</em></a>.</p>
|
||||
<p>These are the accelerator packages
|
||||
currently in LAMMPS, either as standard or user packages:</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="44%" />
|
||||
<col width="56%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr class="row-odd"><td><a class="reference internal" href="accelerate_cuda.html"><em>USER-CUDA</em></a></td>
|
||||
<td>for NVIDIA GPUs</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><a class="reference internal" href="accelerate_gpu.html"><em>GPU</em></a></td>
|
||||
<td>for NVIDIA GPUs as well as OpenCL support</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><a class="reference internal" href="accelerate_intel.html"><em>USER-INTEL</em></a></td>
|
||||
<td>for Intel CPUs and Intel Xeon Phi</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS</em></a></td>
|
||||
<td>for GPUs, Intel Xeon Phi, and OpenMP threading</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><a class="reference internal" href="accelerate_omp.html"><em>USER-OMP</em></a></td>
|
||||
<td>for OpenMP threading</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><a class="reference internal" href="accelerate_opt.html"><em>OPT</em></a></td>
|
||||
<td>generic CPU optimizations</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Inverting this list, LAMMPS currently has acceleration support for
|
||||
three kinds of hardware, via the listed packages:</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="10%" />
|
||||
<col width="90%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr class="row-odd"><td>Many-core CPUs</td>
|
||||
<td><a class="reference internal" href="accelerate_intel.html"><em>USER-INTEL</em></a>, <a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS</em></a>, <a class="reference internal" href="accelerate_omp.html"><em>USER-OMP</em></a>, <a class="reference internal" href="accelerate_opt.html"><em>OPT</em></a> packages</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>NVIDIA GPUs</td>
|
||||
<td><a class="reference internal" href="accelerate_cuda.html"><em>USER-CUDA</em></a>, <a class="reference internal" href="accelerate_gpu.html"><em>GPU</em></a>, <a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS</em></a> packages</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>Intel Phi</td>
|
||||
<td><a class="reference internal" href="accelerate_intel.html"><em>USER-INTEL</em></a>, <a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS</em></a> packages</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Which package is fastest for your hardware may depend on the size
|
||||
problem you are running and what commands (accelerated and
|
||||
non-accelerated) are invoked by your input script. While these doc
|
||||
pages include performance guidelines, there is no substitute for
|
||||
trying out the different packages appropriate to your hardware.</p>
|
||||
<p>Any accelerated style has the same name as the corresponding standard
|
||||
style, except that a suffix is appended. Otherwise, the syntax for
|
||||
the command that uses the style is identical, their functionality is
|
||||
the same, and the numerical results it produces should also be the
|
||||
same, except for precision and round-off effects.</p>
|
||||
<p>For example, all of these styles are accelerated variants of the
|
||||
Lennard-Jones <a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut</em></a>:</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/cuda</em></a></li>
|
||||
<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/gpu</em></a></li>
|
||||
<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/intel</em></a></li>
|
||||
<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/kk</em></a></li>
|
||||
<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/omp</em></a></li>
|
||||
<li><a class="reference internal" href="pair_lj.html"><em>pair_style lj/cut/opt</em></a></li>
|
||||
</ul>
|
||||
<p>To see what accelerate styles are currently available, see
|
||||
<a class="reference internal" href="Section_commands.html#cmd-5"><span>Section_commands 5</span></a> of the manual. The
|
||||
doc pages for individual commands (e.g. <a class="reference internal" href="pair_lj.html"><em>pair lj/cut</em></a> or
|
||||
<a class="reference internal" href="fix_nve.html"><em>fix nve</em></a>) also list any accelerated variants available
|
||||
for that style.</p>
|
||||
<p>To use an accelerator package in LAMMPS, and one or more of the styles
|
||||
it provides, follow these general steps. Details vary from package to
|
||||
package and are explained in the individual accelerator doc pages,
|
||||
listed above:</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="26%" />
|
||||
<col width="74%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr class="row-odd"><td>build the accelerator library</td>
|
||||
<td>only for USER-CUDA and GPU packages</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>install the accelerator package</td>
|
||||
<td>make yes-opt, make yes-user-intel, etc</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<div class="line-block">
|
||||
<div class="line">install the accelerator package | make yes-opt, make yes-user-intel, etc |</div>
|
||||
</div>
|
||||
<blockquote>
|
||||
<div>only for USER-INTEL, KOKKOS, USER-OMP, OPT packages |</div></blockquote>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="26%" />
|
||||
<col width="74%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr class="row-odd"><td>re-build LAMMPS</td>
|
||||
<td>make machine</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<div class="line-block">
|
||||
<div class="line">re-build LAMMPS | make machine |</div>
|
||||
</div>
|
||||
<blockquote>
|
||||
<div>mpirun -np 32 lmp_machine -in in.script |</div></blockquote>
|
||||
<blockquote>
|
||||
<div>only for USER-CUDA and KOKKOS packages |</div></blockquote>
|
||||
<blockquote>
|
||||
<div><a class="reference internal" href="package.html"><em>package</em></a> command, <br>
|
||||
only if defaults need to be changed |</div></blockquote>
|
||||
<blockquote>
|
||||
<div><a class="reference internal" href="suffix.html"><em>suffix</em></a> command |</div></blockquote>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Note that the first 4 steps can be done as a single command, using the
|
||||
src/Make.py tool. This tool is discussed in <a class="reference internal" href="Section_start.html#start-4"><span>Section 2.4</span></a> of the manual, and its use is
|
||||
illustrated in the individual accelerator sections. Typically these
|
||||
steps only need to be done once, to create an executable that uses one
|
||||
or more accelerator packages.</p>
|
||||
<p>The last 4 steps can all be done from the command-line when LAMMPS is
|
||||
launched, without changing your input script, as illustrated in the
|
||||
individual accelerator sections. Or you can add
|
||||
<a class="reference internal" href="package.html"><em>package</em></a> and <a class="reference internal" href="suffix.html"><em>suffix</em></a> commands to your input
|
||||
script.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">With a few exceptions, you can build a single LAMMPS executable
|
||||
with all its accelerator packages installed. Note however that the
|
||||
USER-INTEL and KOKKOS packages require you to choose one of their
|
||||
hardware options when building for a specific platform. I.e. CPU or
|
||||
Phi option for the USER-INTEL package. Or the OpenMP, Cuda, or Phi
|
||||
option for the KOKKOS package.</p>
|
||||
</div>
|
||||
<p>These are the exceptions. You cannot build a single executable with:</p>
|
||||
<ul class="simple">
|
||||
<li>both the USER-INTEL Phi and KOKKOS Phi options</li>
|
||||
<li>the USER-INTEL Phi or Kokkos Phi option, and either the USER-CUDA or GPU packages</li>
|
||||
</ul>
|
||||
<p>See the examples/accelerate/README and make.list files for sample
|
||||
Make.py commands that build LAMMPS with any or all of the accelerator
|
||||
packages. As an example, here is a command that builds with all the
|
||||
GPU related packages installed (USER-CUDA, GPU, KOKKOS with Cuda),
|
||||
including settings to build the needed auxiliary USER-CUDA and GPU
|
||||
libraries for Kepler GPUs:</p>
|
||||
<pre class="literal-block">
|
||||
Make.py -j 16 -p omp gpu cuda kokkos -cc nvcc wrap=mpi -cuda mode=double arch=35 -gpu mode=double arch=35 -kokkos cuda arch=35 lib-all file mpi
|
||||
</pre>
|
||||
<p>The examples/accelerate directory also has input scripts that can be
|
||||
used with all of the accelerator packages. See its README file for
|
||||
details.</p>
|
||||
<p>Likewise, the bench directory has FERMI and KEPLER and PHI
|
||||
sub-directories with Make.py commands and input scripts for using all
|
||||
the accelerator packages on various machines. See the README files in
|
||||
those dirs.</p>
|
||||
<p>As mentioned above, the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the LAMMPS web site gives
|
||||
performance results for the various accelerator packages for several
|
||||
of the standard LAMMPS benchmark problems, as a function of problem
|
||||
size and number of compute nodes, on different hardware platforms.</p>
|
||||
<p>Here is a brief summary of what the various packages provide. Details
|
||||
are in the individual accelerator sections.</p>
|
||||
<ul class="simple">
|
||||
<li>Styles with a “cuda” or “gpu” suffix are part of the USER-CUDA or GPU
|
||||
packages, and can be run on NVIDIA GPUs. The speed-up on a GPU
|
||||
depends on a variety of factors, discussed in the accelerator
|
||||
sections.</li>
|
||||
<li>Styles with an “intel” suffix are part of the USER-INTEL
|
||||
package. These styles support vectorized single and mixed precision
|
||||
calculations, in addition to full double precision. In extreme cases,
|
||||
this can provide speedups over 3.5x on CPUs. The package also
|
||||
supports acceleration in “offload” mode to Intel(R) Xeon Phi(TM)
|
||||
coprocessors. This can result in additional speedup over 2x depending
|
||||
on the hardware configuration.</li>
|
||||
<li>Styles with a “kk” suffix are part of the KOKKOS package, and can be
|
||||
run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
|
||||
Xeon Phi in “native” mode. The speed-up depends on a variety of
|
||||
factors, as discussed on the KOKKOS accelerator page.</li>
|
||||
<li>Styles with an “omp” suffix are part of the USER-OMP package and allow
|
||||
a pair-style to be run in multi-threaded mode using OpenMP. This can
|
||||
be useful on nodes with high-core counts when using less MPI processes
|
||||
than cores is advantageous, e.g. when running with PPPM so that FFTs
|
||||
are run on fewer MPI processors or when the many MPI tasks would
|
||||
overload the available bandwidth for communication.</li>
|
||||
<li>Styles with an “opt” suffix are part of the OPT package and typically
|
||||
speed-up the pairwise calculations of your simulation by 5-25% on a
|
||||
CPU.</li>
|
||||
</ul>
|
||||
<p>The individual accelerator package doc pages explain:</p>
|
||||
<ul class="simple">
|
||||
<li>what hardware and software the accelerated package requires</li>
|
||||
<li>how to build LAMMPS with the accelerated package</li>
|
||||
<li>how to run with the accelerated package either via command-line switches or modifying the input script</li>
|
||||
<li>speed-ups to expect</li>
|
||||
<li>guidelines for best performance</li>
|
||||
<li>restrictions</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="comparison-of-various-accelerator-packages">
|
||||
<span id="acc-4"></span><h2>5.4. Comparison of various accelerator packages<a class="headerlink" href="#comparison-of-various-accelerator-packages" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">this section still needs to be re-worked with additional KOKKOS
|
||||
and USER-INTEL information.</p>
|
||||
</div>
|
||||
<p>The next section compares and contrasts the various accelerator
|
||||
options, since there are multiple ways to perform OpenMP threading,
|
||||
run on GPUs, and run on Intel Xeon Phi coprocessors.</p>
|
||||
<p>All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
|
||||
hardware, but they do it in different ways.</p>
|
||||
<p>As a consequence, for a particular simulation on specific hardware,
|
||||
one package may be faster than the other. We give guidelines below,
|
||||
but the best way to determine which package is faster for your input
|
||||
script is to try both of them on your machine. See the benchmarking
|
||||
section below for examples where this has been done.</p>
|
||||
<p><strong>Guidelines for using each package optimally:</strong></p>
|
||||
<ul class="simple">
|
||||
<li>The GPU package allows you to assign multiple CPUs (cores) to a single
|
||||
GPU (a common configuration for “hybrid” nodes that contain multicore
|
||||
CPU(s) and GPU(s)) and works effectively in this mode. The USER-CUDA
|
||||
package does not allow this; you can only use one CPU per GPU.</li>
|
||||
<li>The GPU package moves per-atom data (coordinates, forces)
|
||||
back-and-forth between the CPU and GPU every timestep. The USER-CUDA
|
||||
package only does this on timesteps when a CPU calculation is required
|
||||
(e.g. to invoke a fix or compute that is non-GPU-ized). Hence, if you
|
||||
can formulate your input script to only use GPU-ized fixes and
|
||||
computes, and avoid doing I/O too often (thermo output, dump file
|
||||
snapshots, restart files), then the data transfer cost of the
|
||||
USER-CUDA package can be very low, causing it to run faster than the
|
||||
GPU package.</li>
|
||||
<li>The GPU package is often faster than the USER-CUDA package, if the
|
||||
number of atoms per GPU is smaller. The crossover point, in terms of
|
||||
atoms/GPU at which the USER-CUDA package becomes faster depends
|
||||
strongly on the pair style. For example, for a simple Lennard Jones
|
||||
system the crossover (in single precision) is often about 50K-100K
|
||||
atoms per GPU. When performing double precision calculations the
|
||||
crossover point can be significantly smaller.</li>
|
||||
<li>Both packages compute bonded interactions (bonds, angles, etc) on the
|
||||
CPU. This means a model with bonds will force the USER-CUDA package
|
||||
to transfer per-atom data back-and-forth between the CPU and GPU every
|
||||
timestep. If the GPU package is running with several MPI processes
|
||||
assigned to one GPU, the cost of computing the bonded interactions is
|
||||
spread across more CPUs and hence the GPU package can run faster.</li>
|
||||
<li>When using the GPU package with multiple CPUs assigned to one GPU, its
|
||||
performance depends to some extent on high bandwidth between the CPUs
|
||||
and the GPU. Hence its performance is affected if full 16 PCIe lanes
|
||||
are not available for each GPU. In HPC environments this can be the
|
||||
case if S2050/70 servers are used, where two devices generally share
|
||||
one PCIe 2.0 16x slot. Also many multi-GPU mainboards do not provide
|
||||
full 16 lanes to each of the PCIe 2.0 16x slots.</li>
|
||||
</ul>
|
||||
<p><strong>Differences between the two packages:</strong></p>
|
||||
<ul class="simple">
|
||||
<li>The GPU package accelerates only pair force, neighbor list, and PPPM
|
||||
calculations. The USER-CUDA package currently supports a wider range
|
||||
of pair styles and can also accelerate many fix styles and some
|
||||
compute styles, as well as neighbor list and PPPM calculations.</li>
|
||||
<li>The USER-CUDA package does not support acceleration for minimization.</li>
|
||||
<li>The USER-CUDA package does not support hybrid pair styles.</li>
|
||||
<li>The USER-CUDA package can order atoms in the neighbor list differently
|
||||
from run to run resulting in a different order for force accumulation.</li>
|
||||
<li>The USER-CUDA package has a limit on the number of atom types that can be
|
||||
used in a simulation.</li>
|
||||
<li>The GPU package requires neighbor lists to be built on the CPU when using
|
||||
exclusion lists or a triclinic simulation box.</li>
|
||||
<li>The GPU package uses more GPU memory than the USER-CUDA package. This
|
||||
is generally not a problem since typical runs are computation-limited
|
||||
rather than memory-limited.</li>
|
||||
</ul>
|
||||
<div class="section" id="examples">
|
||||
<h3>5.4.1. Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h3>
|
||||
<p>The LAMMPS distribution has two directories with sample input scripts
|
||||
for the GPU and USER-CUDA packages.</p>
|
||||
<ul class="simple">
|
||||
<li>lammps/examples/gpu = GPU package files</li>
|
||||
<li>lammps/examples/USER/cuda = USER-CUDA package files</li>
|
||||
</ul>
|
||||
<p>These contain input scripts for identical systems, so they can be used
|
||||
to benchmark the performance of both packages on your system.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_howto.html" class="btn btn-neutral float-right" title="6. How-to discussions" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Section_packages.html" class="btn btn-neutral" title="4. Packages" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,415 +0,0 @@
|
||||
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Section_howto.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
5. Accelerating LAMMPS performance :h3
|
||||
|
||||
This section describes various methods for improving LAMMPS
|
||||
performance for different classes of problems running on different
|
||||
kinds of machines.
|
||||
|
||||
There are two thrusts to the discussion that follows. The
|
||||
first is using code options that implement alternate algorithms
|
||||
that can speed-up a simulation. The second is to use one
|
||||
of the several accelerator packages provided with LAMMPS that
|
||||
contain code optimized for certain kinds of hardware, including
|
||||
multi-core CPUs, GPUs, and Intel Xeon Phi coprocessors.
|
||||
|
||||
5.1 "Measuring performance"_#acc_1 :ulb,l
|
||||
5.2 "Algorithms and code options to boost performace"_#acc_2 :l
|
||||
5.3 "Accelerator packages with optimized styles"_#acc_3 :l
|
||||
5.3.1 "USER-CUDA package"_accelerate_cuda.html :ulb,l
|
||||
5.3.2 "GPU package"_accelerate_gpu.html :l
|
||||
5.3.3 "USER-INTEL package"_accelerate_intel.html :l
|
||||
5.3.4 "KOKKOS package"_accelerate_kokkos.html :l
|
||||
5.3.5 "USER-OMP package"_accelerate_omp.html :l
|
||||
5.3.6 "OPT package"_accelerate_opt.html :l,ule
|
||||
5.4 "Comparison of various accelerator packages"_#acc_4 :l,ule
|
||||
|
||||
The "Benchmark page"_http://lammps.sandia.gov/bench.html of the LAMMPS
|
||||
web site gives performance results for the various accelerator
|
||||
packages discussed in Section 5.2, for several of the standard LAMMPS
|
||||
benchmark problems, as a function of problem size and number of
|
||||
compute nodes, on different hardware platforms.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
5.1 Measuring performance :h4,link(acc_1)
|
||||
|
||||
Before trying to make your simulation run faster, you should
|
||||
understand how it currently performs and where the bottlenecks are.
|
||||
|
||||
The best way to do this is run the your system (actual number of
|
||||
atoms) for a modest number of timesteps (say 100 steps) on several
|
||||
different processor counts, including a single processor if possible.
|
||||
Do this for an equilibrium version of your system, so that the
|
||||
100-step timings are representative of a much longer run. There is
|
||||
typically no need to run for 1000s of timesteps to get accurate
|
||||
timings; you can simply extrapolate from short runs.
|
||||
|
||||
For the set of runs, look at the timing data printed to the screen and
|
||||
log file at the end of each LAMMPS run. "This
|
||||
section"_Section_start.html#start_8 of the manual has an overview.
|
||||
|
||||
Running on one (or a few processors) should give a good estimate of
|
||||
the serial performance and what portions of the timestep are taking
|
||||
the most time. Running the same problem on a few different processor
|
||||
counts should give an estimate of parallel scalability. I.e. if the
|
||||
simulation runs 16x faster on 16 processors, its 100% parallel
|
||||
efficient; if it runs 8x faster on 16 processors, it's 50% efficient.
|
||||
|
||||
The most important data to look at in the timing info is the timing
|
||||
breakdown and relative percentages. For example, trying different
|
||||
options for speeding up the long-range solvers will have little impact
|
||||
if they only consume 10% of the run time. If the pairwise time is
|
||||
dominating, you may want to look at GPU or OMP versions of the pair
|
||||
style, as discussed below. Comparing how the percentages change as
|
||||
you increase the processor count gives you a sense of how different
|
||||
operations within the timestep are scaling. Note that if you are
|
||||
running with a Kspace solver, there is additional output on the
|
||||
breakdown of the Kspace time. For PPPM, this includes the fraction
|
||||
spent on FFTs, which can be communication intensive.
|
||||
|
||||
Another important detail in the timing info are the histograms of
|
||||
atoms counts and neighbor counts. If these vary widely across
|
||||
processors, you have a load-imbalance issue. This often results in
|
||||
inaccurate relative timing data, because processors have to wait when
|
||||
communication occurs for other processors to catch up. Thus the
|
||||
reported times for "Communication" or "Other" may be higher than they
|
||||
really are, due to load-imbalance. If this is an issue, you can
|
||||
uncomment the MPI_Barrier() lines in src/timer.cpp, and recompile
|
||||
LAMMPS, to obtain synchronized timings.
|
||||
|
||||
:line
|
||||
|
||||
5.2 General strategies :h4,link(acc_2)
|
||||
|
||||
NOTE: this section 5.2 is still a work in progress
|
||||
|
||||
Here is a list of general ideas for improving simulation performance.
|
||||
Most of them are only applicable to certain models and certain
|
||||
bottlenecks in the current performance, so let the timing data you
|
||||
generate be your guide. It is hard, if not impossible, to predict how
|
||||
much difference these options will make, since it is a function of
|
||||
problem size, number of processors used, and your machine. There is
|
||||
no substitute for identifying performance bottlenecks, and trying out
|
||||
various options.
|
||||
|
||||
rRESPA
|
||||
2-FFT PPPM
|
||||
Staggered PPPM
|
||||
single vs double PPPM
|
||||
partial charge PPPM
|
||||
verlet/split run style
|
||||
processor command for proc layout and numa layout
|
||||
load-balancing: balance and fix balance :ul
|
||||
|
||||
2-FFT PPPM, also called {analytic differentiation} or {ad} PPPM, uses
|
||||
2 FFTs instead of the 4 FFTs used by the default {ik differentiation}
|
||||
PPPM. However, 2-FFT PPPM also requires a slightly larger mesh size to
|
||||
achieve the same accuracy as 4-FFT PPPM. For problems where the FFT
|
||||
cost is the performance bottleneck (typically large problems running
|
||||
on many processors), 2-FFT PPPM may be faster than 4-FFT PPPM.
|
||||
|
||||
Staggered PPPM performs calculations using two different meshes, one
|
||||
shifted slightly with respect to the other. This can reduce force
|
||||
aliasing errors and increase the accuracy of the method, but also
|
||||
doubles the amount of work required. For high relative accuracy, using
|
||||
staggered PPPM allows one to half the mesh size in each dimension as
|
||||
compared to regular PPPM, which can give around a 4x speedup in the
|
||||
kspace time. However, for low relative accuracy, using staggered PPPM
|
||||
gives little benefit and can be up to 2x slower in the kspace
|
||||
time. For example, the rhodopsin benchmark was run on a single
|
||||
processor, and results for kspace time vs. relative accuracy for the
|
||||
different methods are shown in the figure below. For this system,
|
||||
staggered PPPM (using ik differentiation) becomes useful when using a
|
||||
relative accuracy of slightly greater than 1e-5 and above.
|
||||
|
||||
:c,image(JPG/rhodo_staggered.jpg)
|
||||
|
||||
NOTE: Using staggered PPPM may not give the same increase in accuracy
|
||||
of energy and pressure as it does in forces, so some caution must be
|
||||
used if energy and/or pressure are quantities of interest, such as
|
||||
when using a barostat.
|
||||
|
||||
:line
|
||||
|
||||
5.3 Packages with optimized styles :h4,link(acc_3)
|
||||
|
||||
Accelerated versions of various "pair_style"_pair_style.html,
|
||||
"fixes"_fix.html, "computes"_compute.html, and other commands have
|
||||
been added to LAMMPS, which will typically run faster than the
|
||||
standard non-accelerated versions. Some require appropriate hardware
|
||||
to be present on your system, e.g. GPUs or Intel Xeon Phi
|
||||
coprocessors.
|
||||
|
||||
All of these commands are in packages provided with LAMMPS. An
|
||||
overview of packages is give in "Section
|
||||
packages"_Section_packages.html.
|
||||
|
||||
These are the accelerator packages
|
||||
currently in LAMMPS, either as standard or user packages:
|
||||
|
||||
"USER-CUDA"_accelerate_cuda.html : for NVIDIA GPUs
|
||||
"GPU"_accelerate_gpu.html : for NVIDIA GPUs as well as OpenCL support
|
||||
"USER-INTEL"_accelerate_intel.html : for Intel CPUs and Intel Xeon Phi
|
||||
"KOKKOS"_accelerate_kokkos.html : for GPUs, Intel Xeon Phi, and OpenMP threading
|
||||
"USER-OMP"_accelerate_omp.html : for OpenMP threading
|
||||
"OPT"_accelerate_opt.html : generic CPU optimizations :tb(s=:)
|
||||
|
||||
Inverting this list, LAMMPS currently has acceleration support for
|
||||
three kinds of hardware, via the listed packages:
|
||||
|
||||
Many-core CPUs : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html, "USER-OMP"_accelerate_omp.html, "OPT"_accelerate_opt.html packages
|
||||
NVIDIA GPUs : "USER-CUDA"_accelerate_cuda.html, "GPU"_accelerate_gpu.html, "KOKKOS"_accelerate_kokkos.html packages
|
||||
Intel Phi : "USER-INTEL"_accelerate_intel.html, "KOKKOS"_accelerate_kokkos.html packages :tb(s=:)
|
||||
|
||||
Which package is fastest for your hardware may depend on the size
|
||||
problem you are running and what commands (accelerated and
|
||||
non-accelerated) are invoked by your input script. While these doc
|
||||
pages include performance guidelines, there is no substitute for
|
||||
trying out the different packages appropriate to your hardware.
|
||||
|
||||
Any accelerated style has the same name as the corresponding standard
|
||||
style, except that a suffix is appended. Otherwise, the syntax for
|
||||
the command that uses the style is identical, their functionality is
|
||||
the same, and the numerical results it produces should also be the
|
||||
same, except for precision and round-off effects.
|
||||
|
||||
For example, all of these styles are accelerated variants of the
|
||||
Lennard-Jones "pair_style lj/cut"_pair_lj.html:
|
||||
|
||||
"pair_style lj/cut/cuda"_pair_lj.html
|
||||
"pair_style lj/cut/gpu"_pair_lj.html
|
||||
"pair_style lj/cut/intel"_pair_lj.html
|
||||
"pair_style lj/cut/kk"_pair_lj.html
|
||||
"pair_style lj/cut/omp"_pair_lj.html
|
||||
"pair_style lj/cut/opt"_pair_lj.html :ul
|
||||
|
||||
To see what accelerate styles are currently available, see
|
||||
"Section_commands 5"_Section_commands.html#cmd_5 of the manual. The
|
||||
doc pages for individual commands (e.g. "pair lj/cut"_pair_lj.html or
|
||||
"fix nve"_fix_nve.html) also list any accelerated variants available
|
||||
for that style.
|
||||
|
||||
To use an accelerator package in LAMMPS, and one or more of the styles
|
||||
it provides, follow these general steps. Details vary from package to
|
||||
package and are explained in the individual accelerator doc pages,
|
||||
listed above:
|
||||
|
||||
build the accelerator library |
|
||||
only for USER-CUDA and GPU packages |
|
||||
install the accelerator package |
|
||||
make yes-opt, make yes-user-intel, etc |
|
||||
add compile/link flags to Makefile.machine |
|
||||
in src/MAKE, <br>
|
||||
only for USER-INTEL, KOKKOS, USER-OMP, OPT packages |
|
||||
re-build LAMMPS |
|
||||
make machine |
|
||||
run a LAMMPS simulation |
|
||||
lmp_machine < in.script <br>
|
||||
mpirun -np 32 lmp_machine -in in.script |
|
||||
enable the accelerator package |
|
||||
via "-c on" and "-k on" "command-line switches"_Section_start.html#start_7, <br>
|
||||
only for USER-CUDA and KOKKOS packages |
|
||||
set any needed options for the package |
|
||||
via "-pk" "command-line switch"_Section_start.html#start_7 or
|
||||
"package"_package.html command, <br>
|
||||
only if defaults need to be changed |
|
||||
use accelerated styles in your input script |
|
||||
via "-sf" "command-line switch"_Section_start.html#start_7 or
|
||||
"suffix"_suffix.html command :tb(c=2,s=|)
|
||||
|
||||
Note that the first 4 steps can be done as a single command, using the
|
||||
src/Make.py tool. This tool is discussed in "Section
|
||||
2.4"_Section_start.html#start_4 of the manual, and its use is
|
||||
illustrated in the individual accelerator sections. Typically these
|
||||
steps only need to be done once, to create an executable that uses one
|
||||
or more accelerator packages.
|
||||
|
||||
The last 4 steps can all be done from the command-line when LAMMPS is
|
||||
launched, without changing your input script, as illustrated in the
|
||||
individual accelerator sections. Or you can add
|
||||
"package"_package.html and "suffix"_suffix.html commands to your input
|
||||
script.
|
||||
|
||||
NOTE: With a few exceptions, you can build a single LAMMPS executable
|
||||
with all its accelerator packages installed. Note however that the
|
||||
USER-INTEL and KOKKOS packages require you to choose one of their
|
||||
hardware options when building for a specific platform. I.e. CPU or
|
||||
Phi option for the USER-INTEL package. Or the OpenMP, Cuda, or Phi
|
||||
option for the KOKKOS package.
|
||||
|
||||
These are the exceptions. You cannot build a single executable with:
|
||||
|
||||
both the USER-INTEL Phi and KOKKOS Phi options
|
||||
the USER-INTEL Phi or Kokkos Phi option, and either the USER-CUDA or GPU packages :ul
|
||||
|
||||
See the examples/accelerate/README and make.list files for sample
|
||||
Make.py commands that build LAMMPS with any or all of the accelerator
|
||||
packages. As an example, here is a command that builds with all the
|
||||
GPU related packages installed (USER-CUDA, GPU, KOKKOS with Cuda),
|
||||
including settings to build the needed auxiliary USER-CUDA and GPU
|
||||
libraries for Kepler GPUs:
|
||||
|
||||
Make.py -j 16 -p omp gpu cuda kokkos -cc nvcc wrap=mpi \
|
||||
-cuda mode=double arch=35 -gpu mode=double arch=35 \\
|
||||
-kokkos cuda arch=35 lib-all file mpi :pre
|
||||
|
||||
The examples/accelerate directory also has input scripts that can be
|
||||
used with all of the accelerator packages. See its README file for
|
||||
details.
|
||||
|
||||
Likewise, the bench directory has FERMI and KEPLER and PHI
|
||||
sub-directories with Make.py commands and input scripts for using all
|
||||
the accelerator packages on various machines. See the README files in
|
||||
those dirs.
|
||||
|
||||
As mentioned above, the "Benchmark
|
||||
page"_http://lammps.sandia.gov/bench.html of the LAMMPS web site gives
|
||||
performance results for the various accelerator packages for several
|
||||
of the standard LAMMPS benchmark problems, as a function of problem
|
||||
size and number of compute nodes, on different hardware platforms.
|
||||
|
||||
Here is a brief summary of what the various packages provide. Details
|
||||
are in the individual accelerator sections.
|
||||
|
||||
Styles with a "cuda" or "gpu" suffix are part of the USER-CUDA or GPU
|
||||
packages, and can be run on NVIDIA GPUs. The speed-up on a GPU
|
||||
depends on a variety of factors, discussed in the accelerator
|
||||
sections. :ulb,l
|
||||
|
||||
Styles with an "intel" suffix are part of the USER-INTEL
|
||||
package. These styles support vectorized single and mixed precision
|
||||
calculations, in addition to full double precision. In extreme cases,
|
||||
this can provide speedups over 3.5x on CPUs. The package also
|
||||
supports acceleration in "offload" mode to Intel(R) Xeon Phi(TM)
|
||||
coprocessors. This can result in additional speedup over 2x depending
|
||||
on the hardware configuration. :l
|
||||
|
||||
Styles with a "kk" suffix are part of the KOKKOS package, and can be
|
||||
run using OpenMP on multicore CPUs, on an NVIDIA GPU, or on an Intel
|
||||
Xeon Phi in "native" mode. The speed-up depends on a variety of
|
||||
factors, as discussed on the KOKKOS accelerator page. :l
|
||||
|
||||
Styles with an "omp" suffix are part of the USER-OMP package and allow
|
||||
a pair-style to be run in multi-threaded mode using OpenMP. This can
|
||||
be useful on nodes with high-core counts when using less MPI processes
|
||||
than cores is advantageous, e.g. when running with PPPM so that FFTs
|
||||
are run on fewer MPI processors or when the many MPI tasks would
|
||||
overload the available bandwidth for communication. :l
|
||||
|
||||
Styles with an "opt" suffix are part of the OPT package and typically
|
||||
speed-up the pairwise calculations of your simulation by 5-25% on a
|
||||
CPU. :l,ule
|
||||
|
||||
The individual accelerator package doc pages explain:
|
||||
|
||||
what hardware and software the accelerated package requires
|
||||
how to build LAMMPS with the accelerated package
|
||||
how to run with the accelerated package either via command-line switches or modifying the input script
|
||||
speed-ups to expect
|
||||
guidelines for best performance
|
||||
restrictions :ul
|
||||
|
||||
:line
|
||||
|
||||
5.4 Comparison of various accelerator packages :h4,link(acc_4)
|
||||
|
||||
NOTE: this section still needs to be re-worked with additional KOKKOS
|
||||
and USER-INTEL information.
|
||||
|
||||
The next section compares and contrasts the various accelerator
|
||||
options, since there are multiple ways to perform OpenMP threading,
|
||||
run on GPUs, and run on Intel Xeon Phi coprocessors.
|
||||
|
||||
All 3 of these packages accelerate a LAMMPS calculation using NVIDIA
|
||||
hardware, but they do it in different ways.
|
||||
|
||||
As a consequence, for a particular simulation on specific hardware,
|
||||
one package may be faster than the other. We give guidelines below,
|
||||
but the best way to determine which package is faster for your input
|
||||
script is to try both of them on your machine. See the benchmarking
|
||||
section below for examples where this has been done.
|
||||
|
||||
[Guidelines for using each package optimally:]
|
||||
|
||||
The GPU package allows you to assign multiple CPUs (cores) to a single
|
||||
GPU (a common configuration for "hybrid" nodes that contain multicore
|
||||
CPU(s) and GPU(s)) and works effectively in this mode. The USER-CUDA
|
||||
package does not allow this; you can only use one CPU per GPU. :ulb,l
|
||||
|
||||
The GPU package moves per-atom data (coordinates, forces)
|
||||
back-and-forth between the CPU and GPU every timestep. The USER-CUDA
|
||||
package only does this on timesteps when a CPU calculation is required
|
||||
(e.g. to invoke a fix or compute that is non-GPU-ized). Hence, if you
|
||||
can formulate your input script to only use GPU-ized fixes and
|
||||
computes, and avoid doing I/O too often (thermo output, dump file
|
||||
snapshots, restart files), then the data transfer cost of the
|
||||
USER-CUDA package can be very low, causing it to run faster than the
|
||||
GPU package. :l
|
||||
|
||||
The GPU package is often faster than the USER-CUDA package, if the
|
||||
number of atoms per GPU is smaller. The crossover point, in terms of
|
||||
atoms/GPU at which the USER-CUDA package becomes faster depends
|
||||
strongly on the pair style. For example, for a simple Lennard Jones
|
||||
system the crossover (in single precision) is often about 50K-100K
|
||||
atoms per GPU. When performing double precision calculations the
|
||||
crossover point can be significantly smaller. :l
|
||||
|
||||
Both packages compute bonded interactions (bonds, angles, etc) on the
|
||||
CPU. This means a model with bonds will force the USER-CUDA package
|
||||
to transfer per-atom data back-and-forth between the CPU and GPU every
|
||||
timestep. If the GPU package is running with several MPI processes
|
||||
assigned to one GPU, the cost of computing the bonded interactions is
|
||||
spread across more CPUs and hence the GPU package can run faster. :l
|
||||
|
||||
When using the GPU package with multiple CPUs assigned to one GPU, its
|
||||
performance depends to some extent on high bandwidth between the CPUs
|
||||
and the GPU. Hence its performance is affected if full 16 PCIe lanes
|
||||
are not available for each GPU. In HPC environments this can be the
|
||||
case if S2050/70 servers are used, where two devices generally share
|
||||
one PCIe 2.0 16x slot. Also many multi-GPU mainboards do not provide
|
||||
full 16 lanes to each of the PCIe 2.0 16x slots. :l,ule
|
||||
|
||||
[Differences between the two packages:]
|
||||
|
||||
The GPU package accelerates only pair force, neighbor list, and PPPM
|
||||
calculations. The USER-CUDA package currently supports a wider range
|
||||
of pair styles and can also accelerate many fix styles and some
|
||||
compute styles, as well as neighbor list and PPPM calculations. :ulb,l
|
||||
|
||||
The USER-CUDA package does not support acceleration for minimization. :l
|
||||
|
||||
The USER-CUDA package does not support hybrid pair styles. :l
|
||||
|
||||
The USER-CUDA package can order atoms in the neighbor list differently
|
||||
from run to run resulting in a different order for force accumulation. :l
|
||||
|
||||
The USER-CUDA package has a limit on the number of atom types that can be
|
||||
used in a simulation. :l
|
||||
|
||||
The GPU package requires neighbor lists to be built on the CPU when using
|
||||
exclusion lists or a triclinic simulation box. :l
|
||||
|
||||
The GPU package uses more GPU memory than the USER-CUDA package. This
|
||||
is generally not a problem since typical runs are computation-limited
|
||||
rather than memory-limited. :l,ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
The LAMMPS distribution has two directories with sample input scripts
|
||||
for the GPU and USER-CUDA packages.
|
||||
|
||||
lammps/examples/gpu = GPU package files
|
||||
lammps/examples/USER/cuda = USER-CUDA package files :ul
|
||||
|
||||
These contain input scripts for identical systems, so they can be used
|
||||
to benchmark the performance of both packages on your system.
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
11910
doc/Section_errors.txt
11910
doc/Section_errors.txt
File diff suppressed because it is too large
Load Diff
@ -1,451 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>7. Example problems — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
<link rel="next" title="8. Performance & scalability" href="Section_perf.html"/>
|
||||
<link rel="prev" title="6. How-to discussions" href="Section_howto.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">7. Example problems</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#lowercase-directories">7.1. Lowercase directories</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#uppercase-directories">7.2. Uppercase directories</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>7. Example problems</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
<div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_perf.html" class="btn btn-neutral float-right" title="8. Performance & scalability" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Section_howto.html" class="btn btn-neutral" title="6. How-to discussions" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="example-problems">
|
||||
<h1>7. Example problems<a class="headerlink" href="#example-problems" title="Permalink to this headline">¶</a></h1>
|
||||
<p>The LAMMPS distribution includes an examples sub-directory with many
|
||||
sample problems. Many are 2d models that run quickly are are
|
||||
straightforward to visualize, requiring at most a couple of minutes to
|
||||
run on a desktop machine. Each problem has an input script (in.*) and
|
||||
produces a log file (log.*) when it runs. Some use a data file
|
||||
(data.*) of initial coordinates as additional input. A few sample log
|
||||
file run on different machines and different numbers of processors are
|
||||
included in the directories to compare your answers to. E.g. a log
|
||||
file like log.date.crack.foo.P means the “crack” example was run on P
|
||||
processors of machine “foo” on that date (i.e. with that version of
|
||||
LAMMPS).</p>
|
||||
<p>Many of the input files have commented-out lines for creating dump
|
||||
files and image files.</p>
|
||||
<p>If you uncomment the <a class="reference internal" href="dump.html"><em>dump</em></a> command in the input script, a
|
||||
text dump file will be produced, which can be animated by various
|
||||
<a class="reference external" href="http://lammps.sandia.gov/viz.html">visualization programs</a>. It can
|
||||
also be animated using the xmovie tool described in the <a class="reference internal" href="Section_tools.html"><em>Additional Tools</em></a> section of the LAMMPS documentation.</p>
|
||||
<p>If you uncomment the <a class="reference internal" href="dump.html"><em>dump image</em></a> command in the input
|
||||
script, and assuming you have built LAMMPS with a JPG library, JPG
|
||||
snapshot images will be produced when the simulation runs. They can
|
||||
be quickly post-processed into a movie using commands described on the
|
||||
<a class="reference internal" href="dump_image.html"><em>dump image</em></a> doc page.</p>
|
||||
<p>Animations of many of the examples can be viewed on the Movies section
|
||||
of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS web site</a>.</p>
|
||||
<p>There are two kinds of sub-directories in the examples dir. Lowercase
|
||||
dirs contain one or a few simple, quick-to-run problems. Uppercase
|
||||
dirs contain up to several complex scripts that illustrate a
|
||||
particular kind of simulation method or model. Some of these run for
|
||||
longer times, e.g. to measure a particular quantity.</p>
|
||||
<p>Lists of both kinds of directories are given below.</p>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="lowercase-directories">
|
||||
<h2>7.1. Lowercase directories<a class="headerlink" href="#lowercase-directories" title="Permalink to this headline">¶</a></h2>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="16%" />
|
||||
<col width="84%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr class="row-odd"><td>accelerate</td>
|
||||
<td>run with various acceleration options (OpenMP, GPU, Phi)</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>balance</td>
|
||||
<td>dynamic load balancing, 2d system</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>body</td>
|
||||
<td>body particles, 2d system</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>colloid</td>
|
||||
<td>big colloid particles in a small particle solvent, 2d system</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>comb</td>
|
||||
<td>models using the COMB potential</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>coreshell</td>
|
||||
<td>core/shell model using CORESHELL package</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>crack</td>
|
||||
<td>crack propagation in a 2d solid</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>cuda</td>
|
||||
<td>use of the USER-CUDA package for GPU acceleration</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>deposit</td>
|
||||
<td>deposit atoms and molecules on a surface</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>dipole</td>
|
||||
<td>point dipolar particles, 2d system</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>dreiding</td>
|
||||
<td>methanol via Dreiding FF</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>eim</td>
|
||||
<td>NaCl using the EIM potential</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>ellipse</td>
|
||||
<td>ellipsoidal particles in spherical solvent, 2d system</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>flow</td>
|
||||
<td>Couette and Poiseuille flow in a 2d channel</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>friction</td>
|
||||
<td>frictional contact of spherical asperities between 2d surfaces</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>hugoniostat</td>
|
||||
<td>Hugoniostat shock dynamics</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>indent</td>
|
||||
<td>spherical indenter into a 2d solid</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>kim</td>
|
||||
<td>use of potentials in Knowledge Base for Interatomic Models (KIM)</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>meam</td>
|
||||
<td>MEAM test for SiC and shear (same as shear examples)</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>melt</td>
|
||||
<td>rapid melt of 3d LJ system</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>micelle</td>
|
||||
<td>self-assembly of small lipid-like molecules into 2d bilayers</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>min</td>
|
||||
<td>energy minimization of 2d LJ melt</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>msst</td>
|
||||
<td>MSST shock dynamics</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>nb3b</td>
|
||||
<td>use of nonbonded 3-body harmonic pair style</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>neb</td>
|
||||
<td>nudged elastic band (NEB) calculation for barrier finding</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>nemd</td>
|
||||
<td>non-equilibrium MD of 2d sheared system</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>obstacle</td>
|
||||
<td>flow around two voids in a 2d channel</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>peptide</td>
|
||||
<td>dynamics of a small solvated peptide chain (5-mer)</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>peri</td>
|
||||
<td>Peridynamic model of cylinder impacted by indenter</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>pour</td>
|
||||
<td>pouring of granular particles into a 3d box, then chute flow</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>prd</td>
|
||||
<td>parallel replica dynamics of vacancy diffusion in bulk Si</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>python</td>
|
||||
<td>using embedded Python in a LAMMPS input script</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>qeq</td>
|
||||
<td>use of the QEQ package for charge equilibration</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>reax</td>
|
||||
<td>RDX and TATB models using the ReaxFF</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>rigid</td>
|
||||
<td>rigid bodies modeled as independent or coupled</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>shear</td>
|
||||
<td>sideways shear applied to 2d solid, with and without a void</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>snap</td>
|
||||
<td>NVE dynamics for BCC tantalum crystal using SNAP potential</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>srd</td>
|
||||
<td>stochastic rotation dynamics (SRD) particles as solvent</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>streitz</td>
|
||||
<td>use of Streitz/Mintmire potential with charge equilibration</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>tad</td>
|
||||
<td>temperature-accelerated dynamics of vacancy diffusion in bulk Si</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>vashishta</td>
|
||||
<td>use of the Vashishta potential</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Here is how you can run and visualize one of the sample problems:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>cd indent
|
||||
cp ../../src/lmp_linux . # copy LAMMPS executable to this dir
|
||||
lmp_linux -in in.indent # run the problem
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Running the simulation produces the files <em>dump.indent</em> and
|
||||
<em>log.lammps</em>. You can visualize the dump file of snapshots with a
|
||||
variety of 3rd-party tools highlighted on the
|
||||
<a class="reference external" href="http://lammps.sandia.gov/viz.html">Visualization</a> page of the LAMMPS
|
||||
web site.</p>
|
||||
<p>If you uncomment the <a class="reference internal" href="dump_image.html"><em>dump image</em></a> line(s) in the input
|
||||
script a series of JPG images will be produced by the run (assuming
|
||||
you built LAMMPS with JPG support; see <a class="reference internal" href="Section_start.html"><em>Section start 2.2</em></a> for details). These can be viewed
|
||||
individually or turned into a movie or animated by tools like
|
||||
ImageMagick or QuickTime or various Windows-based tools. See the
|
||||
<a class="reference internal" href="dump_image.html"><em>dump image</em></a> doc page for more details. E.g. this
|
||||
Imagemagick command would create a GIF file suitable for viewing in a
|
||||
browser.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>% convert -loop 1 *.jpg foo.gif
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="uppercase-directories">
|
||||
<h2>7.2. Uppercase directories<a class="headerlink" href="#uppercase-directories" title="Permalink to this headline">¶</a></h2>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="10%" />
|
||||
<col width="90%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr class="row-odd"><td>ASPHERE</td>
|
||||
<td>various aspherical particle models, using ellipsoids, rigid bodies, line/triangle particles, etc</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>COUPLE</td>
|
||||
<td>examples of how to use LAMMPS as a library</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>DIFFUSE</td>
|
||||
<td>compute diffusion coefficients via several methods</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>ELASTIC</td>
|
||||
<td>compute elastic constants at zero temperature</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>ELASTIC_T</td>
|
||||
<td>compute elastic constants at finite temperature</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>KAPPA</td>
|
||||
<td>compute thermal conductivity via several methods</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>MC</td>
|
||||
<td>using LAMMPS in a Monte Carlo mode to relax the energy of a system</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td>USER</td>
|
||||
<td>examples for USER packages and USER-contributed commands</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td>VISCOSITY</td>
|
||||
<td>compute viscosity via several methods</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>Nearly all of these directories have README files which give more
|
||||
details on how to understand and use their contents.</p>
|
||||
<p>The USER directory has a large number of sub-directories which
|
||||
correspond by name to a USER package. They contain scripts that
|
||||
illustrate how to use the command(s) provided in that package. Many
|
||||
of the sub-directories have their own README files which give further
|
||||
instructions. See the <a class="reference internal" href="Section_packages.html"><em>Section packages</em></a> doc
|
||||
page for more info on specific USER packages.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_perf.html" class="btn btn-neutral float-right" title="8. Performance & scalability" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Section_howto.html" class="btn btn-neutral" title="6. How-to discussions" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,141 +0,0 @@
|
||||
"Previous Section"_Section_howto.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_perf.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
7. Example problems :h3
|
||||
|
||||
The LAMMPS distribution includes an examples sub-directory with many
|
||||
sample problems. Many are 2d models that run quickly are are
|
||||
straightforward to visualize, requiring at most a couple of minutes to
|
||||
run on a desktop machine. Each problem has an input script (in.*) and
|
||||
produces a log file (log.*) when it runs. Some use a data file
|
||||
(data.*) of initial coordinates as additional input. A few sample log
|
||||
file run on different machines and different numbers of processors are
|
||||
included in the directories to compare your answers to. E.g. a log
|
||||
file like log.date.crack.foo.P means the "crack" example was run on P
|
||||
processors of machine "foo" on that date (i.e. with that version of
|
||||
LAMMPS).
|
||||
|
||||
Many of the input files have commented-out lines for creating dump
|
||||
files and image files.
|
||||
|
||||
If you uncomment the "dump"_dump.html command in the input script, a
|
||||
text dump file will be produced, which can be animated by various
|
||||
"visualization programs"_http://lammps.sandia.gov/viz.html. It can
|
||||
also be animated using the xmovie tool described in the "Additional
|
||||
Tools"_Section_tools.html section of the LAMMPS documentation.
|
||||
|
||||
If you uncomment the "dump image"_dump.html command in the input
|
||||
script, and assuming you have built LAMMPS with a JPG library, JPG
|
||||
snapshot images will be produced when the simulation runs. They can
|
||||
be quickly post-processed into a movie using commands described on the
|
||||
"dump image"_dump_image.html doc page.
|
||||
|
||||
Animations of many of the examples can be viewed on the Movies section
|
||||
of the "LAMMPS web site"_lws.
|
||||
|
||||
There are two kinds of sub-directories in the examples dir. Lowercase
|
||||
dirs contain one or a few simple, quick-to-run problems. Uppercase
|
||||
dirs contain up to several complex scripts that illustrate a
|
||||
particular kind of simulation method or model. Some of these run for
|
||||
longer times, e.g. to measure a particular quantity.
|
||||
|
||||
Lists of both kinds of directories are given below.
|
||||
|
||||
:line
|
||||
|
||||
Lowercase directories :h4
|
||||
|
||||
accelerate: run with various acceleration options (OpenMP, GPU, Phi)
|
||||
balance: dynamic load balancing, 2d system
|
||||
body: body particles, 2d system
|
||||
colloid: big colloid particles in a small particle solvent, 2d system
|
||||
comb: models using the COMB potential
|
||||
coreshell: core/shell model using CORESHELL package
|
||||
crack: crack propagation in a 2d solid
|
||||
cuda: use of the USER-CUDA package for GPU acceleration
|
||||
deposit: deposit atoms and molecules on a surface
|
||||
dipole: point dipolar particles, 2d system
|
||||
dreiding: methanol via Dreiding FF
|
||||
eim: NaCl using the EIM potential
|
||||
ellipse: ellipsoidal particles in spherical solvent, 2d system
|
||||
flow: Couette and Poiseuille flow in a 2d channel
|
||||
friction: frictional contact of spherical asperities between 2d surfaces
|
||||
hugoniostat: Hugoniostat shock dynamics
|
||||
indent: spherical indenter into a 2d solid
|
||||
kim: use of potentials in Knowledge Base for Interatomic Models (KIM)
|
||||
meam: MEAM test for SiC and shear (same as shear examples)
|
||||
melt: rapid melt of 3d LJ system
|
||||
micelle: self-assembly of small lipid-like molecules into 2d bilayers
|
||||
min: energy minimization of 2d LJ melt
|
||||
msst: MSST shock dynamics
|
||||
nb3b: use of nonbonded 3-body harmonic pair style
|
||||
neb: nudged elastic band (NEB) calculation for barrier finding
|
||||
nemd: non-equilibrium MD of 2d sheared system
|
||||
obstacle: flow around two voids in a 2d channel
|
||||
peptide: dynamics of a small solvated peptide chain (5-mer)
|
||||
peri: Peridynamic model of cylinder impacted by indenter
|
||||
pour: pouring of granular particles into a 3d box, then chute flow
|
||||
prd: parallel replica dynamics of vacancy diffusion in bulk Si
|
||||
python: using embedded Python in a LAMMPS input script
|
||||
qeq: use of the QEQ package for charge equilibration
|
||||
reax: RDX and TATB models using the ReaxFF
|
||||
rigid: rigid bodies modeled as independent or coupled
|
||||
shear: sideways shear applied to 2d solid, with and without a void
|
||||
snap: NVE dynamics for BCC tantalum crystal using SNAP potential
|
||||
srd: stochastic rotation dynamics (SRD) particles as solvent
|
||||
streitz: use of Streitz/Mintmire potential with charge equilibration
|
||||
tad: temperature-accelerated dynamics of vacancy diffusion in bulk Si
|
||||
vashishta: use of the Vashishta potential :tb(s=:)
|
||||
|
||||
Here is how you can run and visualize one of the sample problems:
|
||||
|
||||
cd indent
|
||||
cp ../../src/lmp_linux . # copy LAMMPS executable to this dir
|
||||
lmp_linux -in in.indent # run the problem :pre
|
||||
|
||||
Running the simulation produces the files {dump.indent} and
|
||||
{log.lammps}. You can visualize the dump file of snapshots with a
|
||||
variety of 3rd-party tools highlighted on the
|
||||
"Visualization"_http://lammps.sandia.gov/viz.html page of the LAMMPS
|
||||
web site.
|
||||
|
||||
If you uncomment the "dump image"_dump_image.html line(s) in the input
|
||||
script a series of JPG images will be produced by the run (assuming
|
||||
you built LAMMPS with JPG support; see "Section start
|
||||
2.2"_Section_start.html for details). These can be viewed
|
||||
individually or turned into a movie or animated by tools like
|
||||
ImageMagick or QuickTime or various Windows-based tools. See the
|
||||
"dump image"_dump_image.html doc page for more details. E.g. this
|
||||
Imagemagick command would create a GIF file suitable for viewing in a
|
||||
browser.
|
||||
|
||||
% convert -loop 1 *.jpg foo.gif :pre
|
||||
|
||||
:line
|
||||
|
||||
Uppercase directories :h4
|
||||
|
||||
ASPHERE: various aspherical particle models, using ellipsoids, rigid bodies, line/triangle particles, etc
|
||||
COUPLE: examples of how to use LAMMPS as a library
|
||||
DIFFUSE: compute diffusion coefficients via several methods
|
||||
ELASTIC: compute elastic constants at zero temperature
|
||||
ELASTIC_T: compute elastic constants at finite temperature
|
||||
KAPPA: compute thermal conductivity via several methods
|
||||
MC: using LAMMPS in a Monte Carlo mode to relax the energy of a system
|
||||
USER: examples for USER packages and USER-contributed commands
|
||||
VISCOSITY: compute viscosity via several methods :tb(s=:)
|
||||
|
||||
Nearly all of these directories have README files which give more
|
||||
details on how to understand and use their contents.
|
||||
|
||||
The USER directory has a large number of sub-directories which
|
||||
correspond by name to a USER package. They contain scripts that
|
||||
illustrate how to use the command(s) provided in that package. Many
|
||||
of the sub-directories have their own README files which give further
|
||||
instructions. See the "Section packages"_Section_packages.html doc
|
||||
page for more info on specific USER packages.
|
||||
@ -1,313 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>13. Future and history — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
<link rel="prev" title="12. Errors" href="Section_errors.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">13. Future and history</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#coming-attractions">13.1. Coming attractions</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#past-versions">13.2. Past versions</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>13. Future and history</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
<div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
|
||||
|
||||
|
||||
<a href="Section_errors.html" class="btn btn-neutral" title="12. Errors" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="future-and-history">
|
||||
<h1>13. Future and history<a class="headerlink" href="#future-and-history" title="Permalink to this headline">¶</a></h1>
|
||||
<p>This section lists features we plan to add to LAMMPS, features of
|
||||
previous versions of LAMMPS, and features of other parallel molecular
|
||||
dynamics codes our group has distributed.</p>
|
||||
<div class="line-block">
|
||||
<div class="line">13.1 <a class="reference internal" href="#hist-1"><span>Coming attractions</span></a></div>
|
||||
<div class="line">13.2 <a class="reference internal" href="#hist-2"><span>Past versions</span></a></div>
|
||||
<div class="line"><br /></div>
|
||||
</div>
|
||||
<div class="section" id="coming-attractions">
|
||||
<span id="hist-1"></span><h2>13.1. Coming attractions<a class="headerlink" href="#coming-attractions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <a class="reference external" href="http://lammps.sandia.gov/future.html">Wish list link</a> on the
|
||||
LAMMPS WWW page gives a list of features we are hoping to add to
|
||||
LAMMPS in the future, including contact names of individuals you can
|
||||
email if you are interested in contributing to the developement or
|
||||
would be a future user of that feature.</p>
|
||||
<p>You can also send <a class="reference external" href="http://lammps.sandia.gov/authors.html">email to the developers</a> if you want to add
|
||||
your wish to the list.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="past-versions">
|
||||
<span id="hist-2"></span><h2>13.2. Past versions<a class="headerlink" href="#past-versions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>LAMMPS development began in the mid 1990s under a cooperative research
|
||||
& development agreement (CRADA) between two DOE labs (Sandia and LLNL)
|
||||
and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was
|
||||
to develop a large-scale parallel classical MD code; the coding effort
|
||||
was led by Steve Plimpton at Sandia.</p>
|
||||
<p>After the CRADA ended, a final F77 version, LAMMPS 99, was
|
||||
released. As development of LAMMPS continued at Sandia, its memory
|
||||
management was converted to F90; a final F90 version was released as
|
||||
LAMMPS 2001.</p>
|
||||
<p>The current LAMMPS is a rewrite in C++ and was first publicly released
|
||||
as an open source code in 2004. It includes many new features beyond
|
||||
those in LAMMPS 99 or 2001. It also includes features from older
|
||||
parallel MD codes written at Sandia, namely ParaDyn, Warp, and
|
||||
GranFlow (see below).</p>
|
||||
<p>In late 2006 we began merging new capabilities into LAMMPS that were
|
||||
developed by Aidan Thompson at Sandia for his MD code GRASP, which has
|
||||
a parallel framework similar to LAMMPS. Most notably, these have
|
||||
included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF -
|
||||
and the associated charge-equilibration routines needed for ReaxFF.</p>
|
||||
<p>The <a class="reference external" href="http://lammps.sandia.gov/history.html">History link</a> on the
|
||||
LAMMPS WWW page gives a timeline of features added to the
|
||||
C++ open-source version of LAMMPS over the last several years.</p>
|
||||
<p>These older codes are available for download from the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a>, except for Warp & GranFlow which were primarily used
|
||||
internally. A brief listing of their features is given here.</p>
|
||||
<p>LAMMPS 2001</p>
|
||||
<ul class="simple">
|
||||
<li>F90 + MPI</li>
|
||||
<li>dynamic memory</li>
|
||||
<li>spatial-decomposition parallelism</li>
|
||||
<li>NVE, NVT, NPT, NPH, rRESPA integrators</li>
|
||||
<li>LJ and Coulombic pairwise force fields</li>
|
||||
<li>all-atom, united-atom, bead-spring polymer force fields</li>
|
||||
<li>CHARMM-compatible force fields</li>
|
||||
<li>class 2 force fields</li>
|
||||
<li>3d/2d Ewald & PPPM</li>
|
||||
<li>various force and temperature constraints</li>
|
||||
<li>SHAKE</li>
|
||||
<li>Hessian-free truncated-Newton minimizer</li>
|
||||
<li>user-defined diagnostics</li>
|
||||
</ul>
|
||||
<p>LAMMPS 99</p>
|
||||
<ul class="simple">
|
||||
<li>F77 + MPI</li>
|
||||
<li>static memory allocation</li>
|
||||
<li>spatial-decomposition parallelism</li>
|
||||
<li>most of the LAMMPS 2001 features with a few exceptions</li>
|
||||
<li>no 2d Ewald & PPPM</li>
|
||||
<li>molecular force fields are missing a few CHARMM terms</li>
|
||||
<li>no SHAKE</li>
|
||||
</ul>
|
||||
<p>Warp</p>
|
||||
<ul class="simple">
|
||||
<li>F90 + MPI</li>
|
||||
<li>spatial-decomposition parallelism</li>
|
||||
<li>embedded atom method (EAM) metal potentials + LJ</li>
|
||||
<li>lattice and grain-boundary atom creation</li>
|
||||
<li>NVE, NVT integrators</li>
|
||||
<li>boundary conditions for applying shear stresses</li>
|
||||
<li>temperature controls for actively sheared systems</li>
|
||||
<li>per-atom energy and centro-symmetry computation and output</li>
|
||||
</ul>
|
||||
<p>ParaDyn</p>
|
||||
<ul class="simple">
|
||||
<li>F77 + MPI</li>
|
||||
<li>atom- and force-decomposition parallelism</li>
|
||||
<li>embedded atom method (EAM) metal potentials</li>
|
||||
<li>lattice atom creation</li>
|
||||
<li>NVE, NVT, NPT integrators</li>
|
||||
<li>all serial DYNAMO features for controls and constraints</li>
|
||||
</ul>
|
||||
<p>GranFlow</p>
|
||||
<ul class="simple">
|
||||
<li>F90 + MPI</li>
|
||||
<li>spatial-decomposition parallelism</li>
|
||||
<li>frictional granular potentials</li>
|
||||
<li>NVE integrator</li>
|
||||
<li>boundary conditions for granular flow and packing and walls</li>
|
||||
<li>particle insertion</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
|
||||
|
||||
|
||||
<a href="Section_errors.html" class="btn btn-neutral" title="12. Errors" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,123 +0,0 @@
|
||||
"Previous Section"_Section_errors.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Manual.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
13. Future and history :h3
|
||||
|
||||
This section lists features we plan to add to LAMMPS, features of
|
||||
previous versions of LAMMPS, and features of other parallel molecular
|
||||
dynamics codes our group has distributed.
|
||||
|
||||
13.1 "Coming attractions"_#hist_1
|
||||
13.2 "Past versions"_#hist_2 :all(b)
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
13.1 Coming attractions :h4,link(hist_1)
|
||||
|
||||
The "Wish list link"_http://lammps.sandia.gov/future.html on the
|
||||
LAMMPS WWW page gives a list of features we are hoping to add to
|
||||
LAMMPS in the future, including contact names of individuals you can
|
||||
email if you are interested in contributing to the developement or
|
||||
would be a future user of that feature.
|
||||
|
||||
You can also send "email to the
|
||||
developers"_http://lammps.sandia.gov/authors.html if you want to add
|
||||
your wish to the list.
|
||||
|
||||
:line
|
||||
|
||||
13.2 Past versions :h4,link(hist_2)
|
||||
|
||||
LAMMPS development began in the mid 1990s under a cooperative research
|
||||
& development agreement (CRADA) between two DOE labs (Sandia and LLNL)
|
||||
and 3 companies (Cray, Bristol Myers Squibb, and Dupont). The goal was
|
||||
to develop a large-scale parallel classical MD code; the coding effort
|
||||
was led by Steve Plimpton at Sandia.
|
||||
|
||||
After the CRADA ended, a final F77 version, LAMMPS 99, was
|
||||
released. As development of LAMMPS continued at Sandia, its memory
|
||||
management was converted to F90; a final F90 version was released as
|
||||
LAMMPS 2001.
|
||||
|
||||
The current LAMMPS is a rewrite in C++ and was first publicly released
|
||||
as an open source code in 2004. It includes many new features beyond
|
||||
those in LAMMPS 99 or 2001. It also includes features from older
|
||||
parallel MD codes written at Sandia, namely ParaDyn, Warp, and
|
||||
GranFlow (see below).
|
||||
|
||||
In late 2006 we began merging new capabilities into LAMMPS that were
|
||||
developed by Aidan Thompson at Sandia for his MD code GRASP, which has
|
||||
a parallel framework similar to LAMMPS. Most notably, these have
|
||||
included many-body potentials - Stillinger-Weber, Tersoff, ReaxFF -
|
||||
and the associated charge-equilibration routines needed for ReaxFF.
|
||||
|
||||
The "History link"_http://lammps.sandia.gov/history.html on the
|
||||
LAMMPS WWW page gives a timeline of features added to the
|
||||
C++ open-source version of LAMMPS over the last several years.
|
||||
|
||||
These older codes are available for download from the "LAMMPS WWW
|
||||
site"_lws, except for Warp & GranFlow which were primarily used
|
||||
internally. A brief listing of their features is given here.
|
||||
|
||||
LAMMPS 2001
|
||||
|
||||
F90 + MPI
|
||||
dynamic memory
|
||||
spatial-decomposition parallelism
|
||||
NVE, NVT, NPT, NPH, rRESPA integrators
|
||||
LJ and Coulombic pairwise force fields
|
||||
all-atom, united-atom, bead-spring polymer force fields
|
||||
CHARMM-compatible force fields
|
||||
class 2 force fields
|
||||
3d/2d Ewald & PPPM
|
||||
various force and temperature constraints
|
||||
SHAKE
|
||||
Hessian-free truncated-Newton minimizer
|
||||
user-defined diagnostics :ul
|
||||
|
||||
LAMMPS 99
|
||||
|
||||
F77 + MPI
|
||||
static memory allocation
|
||||
spatial-decomposition parallelism
|
||||
most of the LAMMPS 2001 features with a few exceptions
|
||||
no 2d Ewald & PPPM
|
||||
molecular force fields are missing a few CHARMM terms
|
||||
no SHAKE :ul
|
||||
|
||||
Warp
|
||||
|
||||
F90 + MPI
|
||||
spatial-decomposition parallelism
|
||||
embedded atom method (EAM) metal potentials + LJ
|
||||
lattice and grain-boundary atom creation
|
||||
NVE, NVT integrators
|
||||
boundary conditions for applying shear stresses
|
||||
temperature controls for actively sheared systems
|
||||
per-atom energy and centro-symmetry computation and output :ul
|
||||
|
||||
ParaDyn
|
||||
|
||||
F77 + MPI
|
||||
atom- and force-decomposition parallelism
|
||||
embedded atom method (EAM) metal potentials
|
||||
lattice atom creation
|
||||
NVE, NVT, NPT integrators
|
||||
all serial DYNAMO features for controls and constraints :ul
|
||||
|
||||
GranFlow
|
||||
|
||||
F90 + MPI
|
||||
spatial-decomposition parallelism
|
||||
frictional granular potentials
|
||||
NVE integrator
|
||||
boundary conditions for granular flow and packing and walls
|
||||
particle insertion :ul
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,695 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>1. Introduction — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
<link rel="next" title="2. Getting Started" href="Section_start.html"/>
|
||||
<link rel="prev" title="LAMMPS Documentation" href="Manual.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul class="current">
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">1. Introduction</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#what-is-lammps">1.1. What is LAMMPS</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#lammps-features">1.2. LAMMPS features</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#general-features">1.2.1. General features</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#particle-and-model-types">1.2.2. Particle and model types</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#force-fields">1.2.3. Force fields</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#atom-creation">1.2.4. Atom creation</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#ensembles-constraints-and-boundary-conditions">1.2.5. Ensembles, constraints, and boundary conditions</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#integrators">1.2.6. Integrators</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#diagnostics">1.2.7. Diagnostics</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#output">1.2.8. Output</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#multi-replica-models">1.2.9. Multi-replica models</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#pre-and-post-processing">1.2.10. Pre- and post-processing</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="#specialized-features">1.2.11. Specialized features</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#lammps-non-features">1.3. LAMMPS non-features</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#open-source-distribution">1.4. Open source distribution</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#acknowledgments-and-citations">1.5. Acknowledgments and citations</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>1. Introduction</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
<div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_start.html" class="btn btn-neutral float-right" title="2. Getting Started" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Manual.html" class="btn btn-neutral" title="LAMMPS Documentation" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="introduction">
|
||||
<h1>1. Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h1>
|
||||
<p>This section provides an overview of what LAMMPS can and can’t do,
|
||||
describes what it means for LAMMPS to be an open-source code, and
|
||||
acknowledges the funding and people who have contributed to LAMMPS
|
||||
over the years.</p>
|
||||
<div class="line-block">
|
||||
<div class="line">1.1 <a class="reference internal" href="#intro-1"><span>What is LAMMPS</span></a></div>
|
||||
<div class="line">1.2 <a class="reference internal" href="#intro-2"><span>LAMMPS features</span></a></div>
|
||||
<div class="line">1.3 <a class="reference internal" href="#intro-3"><span>LAMMPS non-features</span></a></div>
|
||||
<div class="line">1.4 <a class="reference internal" href="#intro-4"><span>Open source distribution</span></a></div>
|
||||
<div class="line">1.5 <a class="reference internal" href="#intro-5"><span>Acknowledgments and citations</span></a></div>
|
||||
<div class="line"><br /></div>
|
||||
</div>
|
||||
<div class="section" id="what-is-lammps">
|
||||
<span id="intro-1"></span><h2>1.1. What is LAMMPS<a class="headerlink" href="#what-is-lammps" title="Permalink to this headline">¶</a></h2>
|
||||
<p>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.</p>
|
||||
<p>For examples of LAMMPS simulations, see the Publications page of the
|
||||
<a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
|
||||
<p>LAMMPS runs efficiently on single-processor desktop or laptop
|
||||
machines, but is designed for parallel computers. It will run on any
|
||||
parallel machine that compiles C++ and supports the <a class="reference external" href="http://www-unix.mcs.anl.gov/mpi">MPI</a>
|
||||
message-passing library. This includes distributed- or shared-memory
|
||||
parallel machines and Beowulf-style clusters.</p>
|
||||
<p>LAMMPS can model systems with only a few particles up to millions or
|
||||
billions. See <a class="reference internal" href="Section_perf.html"><em>Section_perf</em></a> for information on
|
||||
LAMMPS performance and scalability, or the Benchmarks section of the
|
||||
<a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
|
||||
<p>LAMMPS is a freely-available open-source code, distributed under the
|
||||
terms of the <a class="reference external" href="http://www.gnu.org/copyleft/gpl.html">GNU Public License</a>, which means you can use or
|
||||
modify the code however you wish. See <a class="reference internal" href="#intro-4"><span>this section</span></a> for a
|
||||
brief discussion of the open-source philosophy.</p>
|
||||
<p>LAMMPS is designed to be easy to modify or extend with new
|
||||
capabilities, such as new force fields, atom types, boundary
|
||||
conditions, or diagnostics. See <a class="reference internal" href="Section_modify.html"><em>Section_modify</em></a>
|
||||
for more details.</p>
|
||||
<p>The current version of LAMMPS is written in C++. Earlier versions
|
||||
were written in F77 and F90. See
|
||||
<a class="reference internal" href="Section_history.html"><em>Section_history</em></a> for more information on
|
||||
different versions. All versions can be downloaded from the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>.</p>
|
||||
<p>LAMMPS was originally developed under a US Department of Energy CRADA
|
||||
(Cooperative Research and Development Agreement) between two DOE labs
|
||||
and 3 companies. It is distributed by <a class="reference external" href="http://www.sandia.gov">Sandia National Labs</a>.
|
||||
See <a class="reference internal" href="#intro-5"><span>this section</span></a> for more information on LAMMPS funding and
|
||||
individuals who have contributed to LAMMPS.</p>
|
||||
<p>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 <a class="reference internal" href="#intro-5"><span>this section</span></a>.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="lammps-features">
|
||||
<span id="intro-2"></span><h2>1.2. LAMMPS features<a class="headerlink" href="#lammps-features" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This section highlights LAMMPS features, with pointers to specific
|
||||
commands which give more details. If LAMMPS doesn’t have your
|
||||
favorite interatomic potential, boundary condition, or atom type, see
|
||||
<a class="reference internal" href="Section_modify.html"><em>Section_modify</em></a>, which describes how you can add
|
||||
it to LAMMPS.</p>
|
||||
<div class="section" id="general-features">
|
||||
<h3>1.2.1. General features<a class="headerlink" href="#general-features" title="Permalink to this headline">¶</a></h3>
|
||||
<ul class="simple">
|
||||
<li>runs on a single processor or in parallel</li>
|
||||
<li>distributed-memory message-passing parallelism (MPI)</li>
|
||||
<li>spatial-decomposition of simulation domain for parallelism</li>
|
||||
<li>open-source distribution</li>
|
||||
<li>highly portable C++</li>
|
||||
<li>optional libraries used: MPI and single-processor FFT</li>
|
||||
<li>GPU (CUDA and OpenCL), Intel(R) Xeon Phi(TM) coprocessors, and OpenMP support for many code features</li>
|
||||
<li>easy to extend with new features and functionality</li>
|
||||
<li>runs from an input script</li>
|
||||
<li>syntax for defining and using variables and formulas</li>
|
||||
<li>syntax for looping over runs and breaking out of loops</li>
|
||||
<li>run one or multiple simulations simultaneously (in parallel) from one script</li>
|
||||
<li>build as library, invoke LAMMPS thru library interface or provided Python wrapper</li>
|
||||
<li>couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="particle-and-model-types">
|
||||
<h3>1.2.2. Particle and model types<a class="headerlink" href="#particle-and-model-types" title="Permalink to this headline">¶</a></h3>
|
||||
<p>(<a class="reference internal" href="atom_style.html"><em>atom style</em></a> command)</p>
|
||||
<ul class="simple">
|
||||
<li>atoms</li>
|
||||
<li>coarse-grained particles (e.g. bead-spring polymers)</li>
|
||||
<li>united-atom polymers or organic molecules</li>
|
||||
<li>all-atom polymers, organic molecules, proteins, DNA</li>
|
||||
<li>metals</li>
|
||||
<li>granular materials</li>
|
||||
<li>coarse-grained mesoscale models</li>
|
||||
<li>finite-size spherical and ellipsoidal particles</li>
|
||||
<li>finite-size line segment (2d) and triangle (3d) particles</li>
|
||||
<li>point dipole particles</li>
|
||||
<li>rigid collections of particles</li>
|
||||
<li>hybrid combinations of these</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="force-fields">
|
||||
<h3>1.2.3. Force fields<a class="headerlink" href="#force-fields" title="Permalink to this headline">¶</a></h3>
|
||||
<p>(<a class="reference internal" href="pair_style.html"><em>pair style</em></a>, <a class="reference internal" href="bond_style.html"><em>bond style</em></a>,
|
||||
<a class="reference internal" href="angle_style.html"><em>angle style</em></a>, <a class="reference internal" href="dihedral_style.html"><em>dihedral style</em></a>,
|
||||
<a class="reference internal" href="improper_style.html"><em>improper style</em></a>, <a class="reference internal" href="kspace_style.html"><em>kspace style</em></a>
|
||||
commands)</p>
|
||||
<ul class="simple">
|
||||
<li>pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated</li>
|
||||
<li>charged pairwise potentials: Coulombic, point-dipole</li>
|
||||
<li>manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic</li>
|
||||
<li>long-range interactions for charge, point-dipoles, and LJ dispersion: Ewald, Wolf, PPPM (similar to particle-mesh Ewald)</li>
|
||||
<li>polarization models: <a class="reference internal" href="fix_qeq.html"><em>QEq</em></a>, <a class="reference internal" href="Section_howto.html#howto-26"><span>core/shell model</span></a>, <a class="reference internal" href="Section_howto.html#howto-27"><span>Drude dipole model</span></a></li>
|
||||
<li>charge equilibration (QEq via dynamic, point, shielded, Slater methods)</li>
|
||||
<li>coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO</li>
|
||||
<li>mesoscopic potentials: granular, Peridynamics, SPH</li>
|
||||
<li>electron force field (eFF, AWPMD)</li>
|
||||
<li>bond potentials: harmonic, FENE, Morse, nonlinear, class 2, quartic (breakable)</li>
|
||||
<li>angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, class 2 (COMPASS)</li>
|
||||
<li>dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, class 2 (COMPASS), OPLS</li>
|
||||
<li>improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)</li>
|
||||
<li>polymer potentials: all-atom, united-atom, bead-spring, breakable</li>
|
||||
<li>water potentials: TIP3P, TIP4P, SPC</li>
|
||||
<li>implicit solvent potentials: hydrodynamic lubrication, Debye</li>
|
||||
<li>force-field compatibility with common CHARMM, AMBER, DREIDING, OPLS, GROMACS, COMPASS options</li>
|
||||
<li>access to <a class="reference external" href="http://openkim.org">KIM archive</a> of potentials via <a class="reference internal" href="pair_kim.html"><em>pair kim</em></a></li>
|
||||
<li>hybrid potentials: multiple pair, bond, angle, dihedral, improper potentials can be used in one simulation</li>
|
||||
<li>overlaid potentials: superposition of multiple pair potentials</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="atom-creation">
|
||||
<h3>1.2.4. Atom creation<a class="headerlink" href="#atom-creation" title="Permalink to this headline">¶</a></h3>
|
||||
<p>(<a class="reference internal" href="read_data.html"><em>read_data</em></a>, <a class="reference internal" href="lattice.html"><em>lattice</em></a>,
|
||||
<a class="reference internal" href="create_atoms.html"><em>create_atoms</em></a>, <a class="reference internal" href="delete_atoms.html"><em>delete_atoms</em></a>,
|
||||
<a class="reference internal" href="displace_atoms.html"><em>displace_atoms</em></a>, <a class="reference internal" href="replicate.html"><em>replicate</em></a> commands)</p>
|
||||
<ul class="simple">
|
||||
<li>read in atom coords from files</li>
|
||||
<li>create atoms on one or more lattices (e.g. grain boundaries)</li>
|
||||
<li>delete geometric or logical groups of atoms (e.g. voids)</li>
|
||||
<li>replicate existing atoms multiple times</li>
|
||||
<li>displace atoms</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="ensembles-constraints-and-boundary-conditions">
|
||||
<h3>1.2.5. Ensembles, constraints, and boundary conditions<a class="headerlink" href="#ensembles-constraints-and-boundary-conditions" title="Permalink to this headline">¶</a></h3>
|
||||
<p>(<a class="reference internal" href="fix.html"><em>fix</em></a> command)</p>
|
||||
<ul class="simple">
|
||||
<li>2d or 3d systems</li>
|
||||
<li>orthogonal or non-orthogonal (triclinic symmetry) simulation domains</li>
|
||||
<li>constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators</li>
|
||||
<li>thermostatting options for groups and geometric regions of atoms</li>
|
||||
<li>pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions</li>
|
||||
<li>simulation box deformation (tensile and shear)</li>
|
||||
<li>harmonic (umbrella) constraint forces</li>
|
||||
<li>rigid body constraints</li>
|
||||
<li>SHAKE bond and angle constraints</li>
|
||||
<li>Monte Carlo bond breaking, formation, swapping</li>
|
||||
<li>atom/molecule insertion and deletion</li>
|
||||
<li>walls of various kinds</li>
|
||||
<li>non-equilibrium molecular dynamics (NEMD)</li>
|
||||
<li>variety of additional boundary conditions and constraints</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="integrators">
|
||||
<h3>1.2.6. Integrators<a class="headerlink" href="#integrators" title="Permalink to this headline">¶</a></h3>
|
||||
<p>(<a class="reference internal" href="run.html"><em>run</em></a>, <a class="reference internal" href="run_style.html"><em>run_style</em></a>, <a class="reference internal" href="minimize.html"><em>minimize</em></a> commands)</p>
|
||||
<ul class="simple">
|
||||
<li>velocity-Verlet integrator</li>
|
||||
<li>Brownian dynamics</li>
|
||||
<li>rigid body integration</li>
|
||||
<li>energy minimization via conjugate gradient or steepest descent relaxation</li>
|
||||
<li>rRESPA hierarchical timestepping</li>
|
||||
<li>rerun command for post-processing of dump files</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="diagnostics">
|
||||
<h3>1.2.7. Diagnostics<a class="headerlink" href="#diagnostics" title="Permalink to this headline">¶</a></h3>
|
||||
<ul class="simple">
|
||||
<li>see the various flavors of the <a class="reference internal" href="fix.html"><em>fix</em></a> and <a class="reference internal" href="compute.html"><em>compute</em></a> commands</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="output">
|
||||
<h3>1.2.8. Output<a class="headerlink" href="#output" title="Permalink to this headline">¶</a></h3>
|
||||
<p>(<a class="reference internal" href="dump.html"><em>dump</em></a>, <a class="reference internal" href="restart.html"><em>restart</em></a> commands)</p>
|
||||
<ul class="simple">
|
||||
<li>log file of thermodynamic info</li>
|
||||
<li>text dump files of atom coords, velocities, other per-atom quantities</li>
|
||||
<li>binary restart files</li>
|
||||
<li>parallel I/O of dump and restart files</li>
|
||||
<li>per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)</li>
|
||||
<li>user-defined system-wide (log file) or per-atom (dump file) calculations</li>
|
||||
<li>spatial and time averaging of per-atom quantities</li>
|
||||
<li>time averaging of system-wide quantities</li>
|
||||
<li>atom snapshots in native, XYZ, XTC, DCD, CFG formats</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="multi-replica-models">
|
||||
<h3>1.2.9. Multi-replica models<a class="headerlink" href="#multi-replica-models" title="Permalink to this headline">¶</a></h3>
|
||||
<p><a class="reference internal" href="neb.html"><em>nudged elastic band</em></a>
|
||||
<a class="reference internal" href="prd.html"><em>parallel replica dynamics</em></a>
|
||||
<a class="reference internal" href="tad.html"><em>temperature accelerated dynamics</em></a>
|
||||
<a class="reference internal" href="temper.html"><em>parallel tempering</em></a></p>
|
||||
</div>
|
||||
<div class="section" id="pre-and-post-processing">
|
||||
<h3>1.2.10. Pre- and post-processing<a class="headerlink" href="#pre-and-post-processing" title="Permalink to this headline">¶</a></h3>
|
||||
<ul class="simple">
|
||||
<li>Various pre- and post-processing serial tools are packaged
|
||||
with LAMMPS; see these <a class="reference internal" href="Section_tools.html"><em>doc pages</em></a>.</li>
|
||||
<li>Our group has also written and released a separate toolkit called
|
||||
<a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> which provides tools for doing setup, analysis,
|
||||
plotting, and visualization for LAMMPS simulations. Pizza.py is
|
||||
written in <a class="reference external" href="http://www.python.org">Python</a> and is available for download from <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW site</a>.</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="specialized-features">
|
||||
<h3>1.2.11. Specialized features<a class="headerlink" href="#specialized-features" title="Permalink to this headline">¶</a></h3>
|
||||
<p>These are LAMMPS capabilities which you may not think of as typical
|
||||
molecular dynamics options:</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference internal" href="balance.html"><em>static</em></a> and <a class="reference internal" href="fix_balance.html"><em>dynamic load-balancing</em></a></li>
|
||||
<li><a class="reference internal" href="body.html"><em>generalized aspherical particles</em></a></li>
|
||||
<li><a class="reference internal" href="fix_srd.html"><em>stochastic rotation dynamics (SRD)</em></a></li>
|
||||
<li><a class="reference internal" href="fix_imd.html"><em>real-time visualization and interactive MD</em></a></li>
|
||||
<li>calculate <a class="reference internal" href="compute_xrd.html"><em>virtual diffraction patterns</em></a></li>
|
||||
<li><a class="reference internal" href="fix_atc.html"><em>atom-to-continuum coupling</em></a> with finite elements</li>
|
||||
<li>coupled rigid body integration via the <a class="reference internal" href="fix_poems.html"><em>POEMS</em></a> library</li>
|
||||
<li><a class="reference internal" href="fix_qmmm.html"><em>QM/MM coupling</em></a></li>
|
||||
<li><a class="reference internal" href="fix_ipi.html"><em>path-integral molecular dynamics (PIMD)</em></a> and <a class="reference internal" href="fix_pimd.html"><em>this as well</em></a></li>
|
||||
<li>Monte Carlo via <a class="reference internal" href="fix_gcmc.html"><em>GCMC</em></a> and <a class="reference internal" href="fix_tfmc.html"><em>tfMC</em></a> and <code class="xref doc docutils literal"><span class="pre">atom</span> <span class="pre">swapping</span></code></li>
|
||||
<li><a class="reference internal" href="pair_dsmc.html"><em>Direct Simulation Monte Carlo</em></a> for low-density fluids</li>
|
||||
<li><a class="reference internal" href="pair_peri.html"><em>Peridynamics mesoscale modeling</em></a></li>
|
||||
<li><a class="reference internal" href="fix_lb_fluid.html"><em>Lattice Boltzmann fluid</em></a></li>
|
||||
<li><a class="reference internal" href="fix_tmd.html"><em>targeted</em></a> and <a class="reference internal" href="fix_smd.html"><em>steered</em></a> molecular dynamics</li>
|
||||
<li><a class="reference internal" href="fix_ttm.html"><em>two-temperature electron model</em></a></li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="lammps-non-features">
|
||||
<span id="intro-3"></span><h2>1.3. LAMMPS non-features<a class="headerlink" href="#lammps-non-features" title="Permalink to this headline">¶</a></h2>
|
||||
<p>LAMMPS is designed to efficiently compute Newton’s equations of motion
|
||||
for a system of interacting particles. Many of the tools needed to
|
||||
pre- and post-process the data for such simulations are not included
|
||||
in the LAMMPS kernel for several reasons:</p>
|
||||
<ul class="simple">
|
||||
<li>the desire to keep LAMMPS simple</li>
|
||||
<li>they are not parallel operations</li>
|
||||
<li>other codes already do them</li>
|
||||
<li>limited development resources</li>
|
||||
</ul>
|
||||
<p>Specifically, LAMMPS itself does not:</p>
|
||||
<ul class="simple">
|
||||
<li>run thru a GUI</li>
|
||||
<li>build molecular systems</li>
|
||||
<li>assign force-field coefficients automagically</li>
|
||||
<li>perform sophisticated analyses of your MD simulation</li>
|
||||
<li>visualize your MD simulation</li>
|
||||
<li>plot your output data</li>
|
||||
</ul>
|
||||
<p>A few tools for pre- and post-processing tasks are provided as part of
|
||||
the LAMMPS package; they are described in <a class="reference internal" href="Section_tools.html"><em>this section</em></a>. However, many people use other codes or
|
||||
write their own tools for these tasks.</p>
|
||||
<p>As noted above, our group has also written and released a separate
|
||||
toolkit called <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> which addresses some of the listed
|
||||
bullets. It provides tools for doing setup, analysis, plotting, and
|
||||
visualization for LAMMPS simulations. Pizza.py is written in
|
||||
<a class="reference external" href="http://www.python.org">Python</a> and is available for download from <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW site</a>.</p>
|
||||
<p>LAMMPS requires as input a list of initial atom coordinates and types,
|
||||
molecular topology information, and force-field coefficients assigned
|
||||
to all atoms and bonds. LAMMPS will not build molecular systems and
|
||||
assign force-field parameters for you.</p>
|
||||
<p>For atomic systems LAMMPS provides a <a class="reference internal" href="create_atoms.html"><em>create_atoms</em></a>
|
||||
command which places atoms on solid-state lattices (fcc, bcc,
|
||||
user-defined, etc). Assigning small numbers of force field
|
||||
coefficients can be done via the <a class="reference internal" href="pair_coeff.html"><em>pair coeff</em></a>, <a class="reference internal" href="bond_coeff.html"><em>bond coeff</em></a>, <a class="reference internal" href="angle_coeff.html"><em>angle coeff</em></a>, etc commands.
|
||||
For molecular systems or more complicated simulation geometries, users
|
||||
typically use another code as a builder and convert its output to
|
||||
LAMMPS input format, or write their own code to generate atom
|
||||
coordinate and molecular topology for LAMMPS to read in.</p>
|
||||
<p>For complicated molecular systems (e.g. a protein), a multitude of
|
||||
topology information and hundreds of force-field coefficients must
|
||||
typically be specified. We suggest you use a program like
|
||||
<a class="reference external" href="http://www.scripps.edu/brooks">CHARMM</a> or <a class="reference external" href="http://amber.scripps.edu">AMBER</a> or other molecular builders to setup
|
||||
such problems and dump its information to a file. You can then
|
||||
reformat the file as LAMMPS input. Some of the tools in <a class="reference internal" href="Section_tools.html"><em>this section</em></a> can assist in this process.</p>
|
||||
<p>Similarly, LAMMPS creates output files in a simple format. Most users
|
||||
post-process these files with their own analysis tools or re-format
|
||||
them for input into other programs, including visualization packages.
|
||||
If you are convinced you need to compute something on-the-fly as
|
||||
LAMMPS runs, see <a class="reference internal" href="Section_modify.html"><em>Section_modify</em></a> for a discussion
|
||||
of how you can use the <a class="reference internal" href="dump.html"><em>dump</em></a> and <a class="reference internal" href="compute.html"><em>compute</em></a> and
|
||||
<a class="reference internal" href="fix.html"><em>fix</em></a> commands to print out data of your choosing. Keep in
|
||||
mind that complicated computations can slow down the molecular
|
||||
dynamics timestepping, particularly if the computations are not
|
||||
parallel, so it is often better to leave such analysis to
|
||||
post-processing codes.</p>
|
||||
<p>A very simple (yet fast) visualizer is provided with the LAMMPS
|
||||
package - see the <a class="reference internal" href="Section_tools.html#xmovie"><span>xmovie</span></a> tool in <a class="reference internal" href="Section_tools.html"><em>this section</em></a>. It creates xyz projection views of
|
||||
atomic coordinates and animates them. We find it very useful for
|
||||
debugging purposes. For high-quality visualization we recommend the
|
||||
following packages:</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD</a></li>
|
||||
<li><a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a></li>
|
||||
<li><a class="reference external" href="http://pymol.sourceforge.net">PyMol</a></li>
|
||||
<li><a class="reference external" href="http://www.bmsc.washington.edu/raster3d/raster3d.html">Raster3d</a></li>
|
||||
<li><a class="reference external" href="http://www.openrasmol.org">RasMol</a></li>
|
||||
</ul>
|
||||
<p>Other features that LAMMPS does not yet (and may never) support are
|
||||
discussed in <a class="reference internal" href="Section_history.html"><em>Section_history</em></a>.</p>
|
||||
<p>Finally, these are freely-available molecular dynamics codes, most of
|
||||
them parallel, which may be well-suited to the problems you want to
|
||||
model. They can also be used in conjunction with LAMMPS to perform
|
||||
complementary modeling tasks.</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference external" href="http://www.scripps.edu/brooks">CHARMM</a></li>
|
||||
<li><a class="reference external" href="http://amber.scripps.edu">AMBER</a></li>
|
||||
<li><a class="reference external" href="http://www.ks.uiuc.edu/Research/namd/">NAMD</a></li>
|
||||
<li><a class="reference external" href="http://www.emsl.pnl.gov/docs/nwchem/nwchem.html">NWCHEM</a></li>
|
||||
<li><a class="reference external" href="http://www.cse.clrc.ac.uk/msi/software/DL_POLY">DL_POLY</a></li>
|
||||
<li><a class="reference external" href="http://dasher.wustl.edu/tinker">Tinker</a></li>
|
||||
</ul>
|
||||
<p>CHARMM, AMBER, NAMD, NWCHEM, and Tinker are designed primarily for
|
||||
modeling biological molecules. CHARMM and AMBER use
|
||||
atom-decomposition (replicated-data) strategies for parallelism; NAMD
|
||||
and NWCHEM use spatial-decomposition approaches, similar to LAMMPS.
|
||||
Tinker is a serial code. DL_POLY includes potentials for a variety of
|
||||
biological and non-biological materials; both a replicated-data and
|
||||
spatial-decomposition version exist.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="open-source-distribution">
|
||||
<span id="intro-4"></span><h2>1.4. Open source distribution<a class="headerlink" href="#open-source-distribution" title="Permalink to this headline">¶</a></h2>
|
||||
<p>LAMMPS comes with no warranty of any kind. As each source file states
|
||||
in its header, it is a copyrighted code that is distributed free-of-
|
||||
charge, under the terms of the <a class="reference external" href="http://www.gnu.org/copyleft/gpl.html">GNU Public License</a> (GPL). This
|
||||
is often referred to as open-source distribution - see
|
||||
<a class="reference external" href="http://www.gnu.org">www.gnu.org</a> or <a class="reference external" href="http://www.opensource.org">www.opensource.org</a> for more
|
||||
details. The legal text of the GPL is in the LICENSE file that is
|
||||
included in the LAMMPS distribution.</p>
|
||||
<p>Here is a summary of what the GPL means for LAMMPS users:</p>
|
||||
<p>(1) Anyone is free to use, modify, or extend LAMMPS in any way they
|
||||
choose, including for commercial purposes.</p>
|
||||
<p>(2) If you distribute a modified version of LAMMPS, it must remain
|
||||
open-source, meaning you distribute it under the terms of the GPL.
|
||||
You should clearly annotate such a code as a derivative version of
|
||||
LAMMPS.</p>
|
||||
<p>(3) If you release any code that includes LAMMPS source code, then it
|
||||
must also be open-sourced, meaning you distribute it under the terms
|
||||
of the GPL.</p>
|
||||
<p>(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
|
||||
source file headers (including the copyright and GPL notices) should
|
||||
remain part of the code.</p>
|
||||
<p>In the spirit of an open-source code, these are various ways you can
|
||||
contribute to making LAMMPS better. You can send email to the
|
||||
<a class="reference external" href="http://lammps.sandia.gov/authors.html">developers</a> on any of these
|
||||
items.</p>
|
||||
<ul class="simple">
|
||||
<li>Point prospective users to the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>. Mention it in
|
||||
talks or link to it from your WWW site.</li>
|
||||
<li>If you find an error or omission in this manual or on the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>, or have a suggestion for something to clarify or include,
|
||||
send an email to the
|
||||
<a class="reference external" href="http://lammps.sandia.gov/authors.html">developers</a>.</li>
|
||||
<li>If you find a bug, <a class="reference internal" href="Section_errors.html#err-2"><span>Section_errors 2</span></a>
|
||||
describes how to report it.</li>
|
||||
<li>If you publish a paper using LAMMPS results, send the citation (and
|
||||
any cool pictures or movies if you like) to add to the Publications,
|
||||
Pictures, and Movies pages of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>, with links
|
||||
and attributions back to you.</li>
|
||||
<li>Create a new Makefile.machine that can be added to the src/MAKE
|
||||
directory.</li>
|
||||
<li>The tools sub-directory of the LAMMPS distribution has various
|
||||
stand-alone codes for pre- and post-processing of LAMMPS data. More
|
||||
details are given in <a class="reference internal" href="Section_tools.html"><em>Section_tools</em></a>. If you write
|
||||
a new tool that users will find useful, it can be added to the LAMMPS
|
||||
distribution.</li>
|
||||
<li>LAMMPS is designed to be easy to extend with new code for features
|
||||
like potentials, boundary conditions, diagnostic computations, etc.
|
||||
<a class="reference internal" href="Section_modify.html"><em>This section</em></a> gives details. If you add a
|
||||
feature of general interest, it can be added to the LAMMPS
|
||||
distribution.</li>
|
||||
<li>The Benchmark page of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> lists LAMMPS
|
||||
performance on various platforms. The files needed to run the
|
||||
benchmarks are part of the LAMMPS distribution. If your machine is
|
||||
sufficiently different from those listed, your timing data can be
|
||||
added to the page.</li>
|
||||
<li>You can send feedback for the User Comments page of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>. It might be added to the page. No promises.</li>
|
||||
<li>Cash. Small denominations, unmarked bills preferred. Paper sack OK.
|
||||
Leave on desk. VISA also accepted. Chocolate chip cookies
|
||||
encouraged.</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="acknowledgments-and-citations">
|
||||
<span id="intro-5"></span><h2>1.5. Acknowledgments and citations<a class="headerlink" href="#acknowledgments-and-citations" title="Permalink to this headline">¶</a></h2>
|
||||
<p>LAMMPS development has been funded by the <a class="reference external" href="http://www.doe.gov">US Department of Energy</a> (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life
|
||||
programs and its <a class="reference external" href="http://www.sc.doe.gov/ascr/home.html">OASCR</a> and <a class="reference external" href="http://www.er.doe.gov/production/ober/ober_top.html">OBER</a> offices.</p>
|
||||
<p>Specifically, work on the latest version was funded in part by the US
|
||||
Department of Energy’s Genomics:GTL program
|
||||
(<a class="reference external" href="http://www.doegenomestolife.org">www.doegenomestolife.org</a>) under the <a class="reference external" href="http://www.genomes2life.org">project</a>, “Carbon
|
||||
Sequestration in Synechococcus Sp.: From Molecular Machines to
|
||||
Hierarchical Modeling”.</p>
|
||||
<p>The following paper describe the basic parallel algorithms used in
|
||||
LAMMPS. If you use LAMMPS results in your published work, please cite
|
||||
this paper and include a pointer to the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a>
|
||||
(<a class="reference external" href="http://lammps.sandia.gov">http://lammps.sandia.gov</a>):</p>
|
||||
<p>S. J. Plimpton, <strong>Fast Parallel Algorithms for Short-Range Molecular
|
||||
Dynamics</strong>, J Comp Phys, 117, 1-19 (1995).</p>
|
||||
<p>Other papers describing specific algorithms used in LAMMPS are listed
|
||||
under the <a class="reference external" href="http://lammps.sandia.gov/cite.html">Citing LAMMPS link</a> of
|
||||
the LAMMPS WWW page.</p>
|
||||
<p>The <a class="reference external" href="http://lammps.sandia.gov/papers.html">Publications link</a> on the
|
||||
LAMMPS WWW page lists papers that have cited LAMMPS. If your paper is
|
||||
not listed there for some reason, feel free to send us the info. If
|
||||
the simulations in your paper produced cool pictures or animations,
|
||||
we’ll be pleased to add them to the
|
||||
<a class="reference external" href="http://lammps.sandia.gov/pictures.html">Pictures</a> or
|
||||
<a class="reference external" href="http://lammps.sandia.gov/movies.html">Movies</a> pages of the LAMMPS WWW
|
||||
site.</p>
|
||||
<p>The core group of LAMMPS developers is at Sandia National Labs:</p>
|
||||
<ul class="simple">
|
||||
<li>Steve Plimpton, sjplimp at sandia.gov</li>
|
||||
<li>Aidan Thompson, athomps at sandia.gov</li>
|
||||
<li>Paul Crozier, pscrozi at sandia.gov</li>
|
||||
</ul>
|
||||
<p>The following folks are responsible for significant contributions to
|
||||
the code, or other aspects of the LAMMPS development effort. Many of
|
||||
the packages they have written are somewhat unique to LAMMPS and the
|
||||
code would not be as general-purpose as it is without their expertise
|
||||
and efforts.</p>
|
||||
<ul class="simple">
|
||||
<li>Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages</li>
|
||||
<li>Roy Pollock (LLNL), Ewald and PPPM solvers</li>
|
||||
<li>Mike Brown (ORNL), brownw at ornl.gov, GPU package</li>
|
||||
<li>Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential</li>
|
||||
<li>Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics</li>
|
||||
<li>Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion</li>
|
||||
<li>Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling</li>
|
||||
<li>Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD</li>
|
||||
<li>Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA package</li>
|
||||
<li>Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field</li>
|
||||
<li>Christoph Kloss (JKU), Christoph.Kloss at jku.at, USER-LIGGGHTS package for granular models and granular/fluid coupling</li>
|
||||
<li>Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF</li>
|
||||
<li>Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SPH package</li>
|
||||
</ul>
|
||||
<p>As discussed in <a class="reference internal" href="Section_history.html"><em>Section_history</em></a>, LAMMPS
|
||||
originated as a cooperative project between DOE labs and industrial
|
||||
partners. Folks involved in the design and testing of the original
|
||||
version of LAMMPS were the following:</p>
|
||||
<ul class="simple">
|
||||
<li>John Carpenter (Mayo Clinic, formerly at Cray Research)</li>
|
||||
<li>Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)</li>
|
||||
<li>Steve Lustig (Dupont)</li>
|
||||
<li>Jim Belak (LLNL)</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_start.html" class="btn btn-neutral float-right" title="2. Getting Started" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Manual.html" class="btn btn-neutral" title="LAMMPS Documentation" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,540 +0,0 @@
|
||||
"Previous Section"_Manual.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_start.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
1. Introduction :h3
|
||||
|
||||
This section provides an overview of what LAMMPS can and can't do,
|
||||
describes what it means for LAMMPS to be an open-source code, and
|
||||
acknowledges the funding and people who have contributed to LAMMPS
|
||||
over the years.
|
||||
|
||||
1.1 "What is LAMMPS"_#intro_1
|
||||
1.2 "LAMMPS features"_#intro_2
|
||||
1.3 "LAMMPS non-features"_#intro_3
|
||||
1.4 "Open source distribution"_#intro_4
|
||||
1.5 "Acknowledgments and citations"_#intro_5 :all(b)
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
1.1 What is LAMMPS :link(intro_1),h4
|
||||
|
||||
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.
|
||||
|
||||
For examples of LAMMPS simulations, see the Publications page of the
|
||||
"LAMMPS WWW Site"_lws.
|
||||
|
||||
LAMMPS runs efficiently on single-processor desktop or laptop
|
||||
machines, but is designed for parallel computers. It will run on any
|
||||
parallel machine that compiles C++ and supports the "MPI"_mpi
|
||||
message-passing library. This includes distributed- or shared-memory
|
||||
parallel machines and Beowulf-style clusters.
|
||||
|
||||
:link(mpi,http://www-unix.mcs.anl.gov/mpi)
|
||||
|
||||
LAMMPS can model systems with only a few particles up to millions or
|
||||
billions. See "Section_perf"_Section_perf.html for information on
|
||||
LAMMPS performance and scalability, or the Benchmarks section of the
|
||||
"LAMMPS WWW Site"_lws.
|
||||
|
||||
LAMMPS is a freely-available open-source code, distributed under the
|
||||
terms of the "GNU Public License"_gnu, which means you can use or
|
||||
modify the code however you wish. See "this section"_#intro_4 for a
|
||||
brief discussion of the open-source philosophy.
|
||||
|
||||
:link(gnu,http://www.gnu.org/copyleft/gpl.html)
|
||||
|
||||
LAMMPS is designed to be easy to modify or extend with new
|
||||
capabilities, such as new force fields, atom types, boundary
|
||||
conditions, or diagnostics. See "Section_modify"_Section_modify.html
|
||||
for more details.
|
||||
|
||||
The current version of LAMMPS is written in C++. Earlier versions
|
||||
were written in F77 and F90. See
|
||||
"Section_history"_Section_history.html for more information on
|
||||
different versions. All versions can be downloaded from the "LAMMPS
|
||||
WWW Site"_lws.
|
||||
|
||||
LAMMPS was originally developed under a US Department of Energy CRADA
|
||||
(Cooperative Research and Development Agreement) between two DOE labs
|
||||
and 3 companies. It is distributed by "Sandia National Labs"_snl.
|
||||
See "this section"_#intro_5 for more information on LAMMPS funding and
|
||||
individuals who have contributed to LAMMPS.
|
||||
|
||||
:link(snl,http://www.sandia.gov)
|
||||
|
||||
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"_#intro_5.
|
||||
|
||||
:line
|
||||
|
||||
1.2 LAMMPS features :link(intro_2),h4
|
||||
|
||||
This section highlights LAMMPS features, with pointers to specific
|
||||
commands which give more details. If LAMMPS doesn't have your
|
||||
favorite interatomic potential, boundary condition, or atom type, see
|
||||
"Section_modify"_Section_modify.html, which describes how you can add
|
||||
it to LAMMPS.
|
||||
|
||||
General features :h5
|
||||
|
||||
runs on a single processor or in parallel
|
||||
distributed-memory message-passing parallelism (MPI)
|
||||
spatial-decomposition of simulation domain for parallelism
|
||||
open-source distribution
|
||||
highly portable C++
|
||||
optional libraries used: MPI and single-processor FFT
|
||||
GPU (CUDA and OpenCL), Intel(R) Xeon Phi(TM) coprocessors, and OpenMP support for many code features
|
||||
easy to extend with new features and functionality
|
||||
runs from an input script
|
||||
syntax for defining and using variables and formulas
|
||||
syntax for looping over runs and breaking out of loops
|
||||
run one or multiple simulations simultaneously (in parallel) from one script
|
||||
build as library, invoke LAMMPS thru library interface or provided Python wrapper
|
||||
couple with other codes: LAMMPS calls other code, other code calls LAMMPS, umbrella code calls both :ul
|
||||
|
||||
Particle and model types :h5
|
||||
("atom style"_atom_style.html command)
|
||||
|
||||
atoms
|
||||
coarse-grained particles (e.g. bead-spring polymers)
|
||||
united-atom polymers or organic molecules
|
||||
all-atom polymers, organic molecules, proteins, DNA
|
||||
metals
|
||||
granular materials
|
||||
coarse-grained mesoscale models
|
||||
finite-size spherical and ellipsoidal particles
|
||||
finite-size line segment (2d) and triangle (3d) particles
|
||||
point dipole particles
|
||||
rigid collections of particles
|
||||
hybrid combinations of these :ul
|
||||
|
||||
Force fields :h5
|
||||
("pair style"_pair_style.html, "bond style"_bond_style.html,
|
||||
"angle style"_angle_style.html, "dihedral style"_dihedral_style.html,
|
||||
"improper style"_improper_style.html, "kspace style"_kspace_style.html
|
||||
commands)
|
||||
|
||||
pairwise potentials: Lennard-Jones, Buckingham, Morse, Born-Mayer-Huggins, \
|
||||
Yukawa, soft, class 2 (COMPASS), hydrogen bond, tabulated
|
||||
charged pairwise potentials: Coulombic, point-dipole
|
||||
manybody potentials: EAM, Finnis/Sinclair EAM, modified EAM (MEAM), \
|
||||
embedded ion method (EIM), EDIP, ADP, Stillinger-Weber, Tersoff, \
|
||||
REBO, AIREBO, ReaxFF, COMB, SNAP, Streitz-Mintmire, 3-body polymorphic
|
||||
long-range interactions for charge, point-dipoles, and LJ dispersion: \
|
||||
Ewald, Wolf, PPPM (similar to particle-mesh Ewald)
|
||||
polarization models: "QEq"_fix_qeq.html, \
|
||||
"core/shell model"_Section_howto.html#howto_26, \
|
||||
"Drude dipole model"_Section_howto.html#howto_27
|
||||
charge equilibration (QEq via dynamic, point, shielded, Slater methods)
|
||||
coarse-grained potentials: DPD, GayBerne, REsquared, colloidal, DLVO
|
||||
mesoscopic potentials: granular, Peridynamics, SPH
|
||||
electron force field (eFF, AWPMD)
|
||||
bond potentials: harmonic, FENE, Morse, nonlinear, class 2, \
|
||||
quartic (breakable)
|
||||
angle potentials: harmonic, CHARMM, cosine, cosine/squared, cosine/periodic, \
|
||||
class 2 (COMPASS)
|
||||
dihedral potentials: harmonic, CHARMM, multi-harmonic, helix, \
|
||||
class 2 (COMPASS), OPLS
|
||||
improper potentials: harmonic, cvff, umbrella, class 2 (COMPASS)
|
||||
polymer potentials: all-atom, united-atom, bead-spring, breakable
|
||||
water potentials: TIP3P, TIP4P, SPC
|
||||
implicit solvent potentials: hydrodynamic lubrication, Debye
|
||||
force-field compatibility with common CHARMM, AMBER, DREIDING, \
|
||||
OPLS, GROMACS, COMPASS options
|
||||
access to "KIM archive"_http://openkim.org of potentials via \
|
||||
"pair kim"_pair_kim.html
|
||||
hybrid potentials: multiple pair, bond, angle, dihedral, improper \
|
||||
potentials can be used in one simulation
|
||||
overlaid potentials: superposition of multiple pair potentials :ul
|
||||
|
||||
Atom creation :h5
|
||||
("read_data"_read_data.html, "lattice"_lattice.html,
|
||||
"create_atoms"_create_atoms.html, "delete_atoms"_delete_atoms.html,
|
||||
"displace_atoms"_displace_atoms.html, "replicate"_replicate.html commands)
|
||||
|
||||
read in atom coords from files
|
||||
create atoms on one or more lattices (e.g. grain boundaries)
|
||||
delete geometric or logical groups of atoms (e.g. voids)
|
||||
replicate existing atoms multiple times
|
||||
displace atoms :ul
|
||||
|
||||
Ensembles, constraints, and boundary conditions :h5
|
||||
("fix"_fix.html command)
|
||||
|
||||
2d or 3d systems
|
||||
orthogonal or non-orthogonal (triclinic symmetry) simulation domains
|
||||
constant NVE, NVT, NPT, NPH, Parinello/Rahman integrators
|
||||
thermostatting options for groups and geometric regions of atoms
|
||||
pressure control via Nose/Hoover or Berendsen barostatting in 1 to 3 dimensions
|
||||
simulation box deformation (tensile and shear)
|
||||
harmonic (umbrella) constraint forces
|
||||
rigid body constraints
|
||||
SHAKE bond and angle constraints
|
||||
Monte Carlo bond breaking, formation, swapping
|
||||
atom/molecule insertion and deletion
|
||||
walls of various kinds
|
||||
non-equilibrium molecular dynamics (NEMD)
|
||||
variety of additional boundary conditions and constraints :ul
|
||||
|
||||
Integrators :h5
|
||||
("run"_run.html, "run_style"_run_style.html, "minimize"_minimize.html commands)
|
||||
|
||||
velocity-Verlet integrator
|
||||
Brownian dynamics
|
||||
rigid body integration
|
||||
energy minimization via conjugate gradient or steepest descent relaxation
|
||||
rRESPA hierarchical timestepping
|
||||
rerun command for post-processing of dump files :ul
|
||||
|
||||
Diagnostics :h5
|
||||
|
||||
see the various flavors of the "fix"_fix.html and "compute"_compute.html commands :ul
|
||||
|
||||
Output :h5
|
||||
("dump"_dump.html, "restart"_restart.html commands)
|
||||
|
||||
log file of thermodynamic info
|
||||
text dump files of atom coords, velocities, other per-atom quantities
|
||||
binary restart files
|
||||
parallel I/O of dump and restart files
|
||||
per-atom quantities (energy, stress, centro-symmetry parameter, CNA, etc)
|
||||
user-defined system-wide (log file) or per-atom (dump file) calculations
|
||||
spatial and time averaging of per-atom quantities
|
||||
time averaging of system-wide quantities
|
||||
atom snapshots in native, XYZ, XTC, DCD, CFG formats :ul
|
||||
|
||||
Multi-replica models :h5
|
||||
|
||||
"nudged elastic band"_neb.html
|
||||
"parallel replica dynamics"_prd.html
|
||||
"temperature accelerated dynamics"_tad.html
|
||||
"parallel tempering"_temper.html
|
||||
|
||||
Pre- and post-processing :h5
|
||||
|
||||
Various pre- and post-processing serial tools are packaged
|
||||
with LAMMPS; see these "doc pages"_Section_tools.html. :ulb,l
|
||||
|
||||
Our group has also written and released a separate toolkit called
|
||||
"Pizza.py"_pizza which provides tools for doing setup, analysis,
|
||||
plotting, and visualization for LAMMPS simulations. Pizza.py is
|
||||
written in "Python"_python and is available for download from "the
|
||||
Pizza.py WWW site"_pizza. :l,ule
|
||||
|
||||
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
|
||||
:link(python,http://www.python.org)
|
||||
|
||||
Specialized features :h5
|
||||
|
||||
These are LAMMPS capabilities which you may not think of as typical
|
||||
molecular dynamics options:
|
||||
|
||||
"static"_balance.html and "dynamic load-balancing"_fix_balance.html
|
||||
"generalized aspherical particles"_body.html
|
||||
"stochastic rotation dynamics (SRD)"_fix_srd.html
|
||||
"real-time visualization and interactive MD"_fix_imd.html
|
||||
calculate "virtual diffraction patterns"_compute_xrd.html
|
||||
"atom-to-continuum coupling"_fix_atc.html with finite elements
|
||||
coupled rigid body integration via the "POEMS"_fix_poems.html library
|
||||
"QM/MM coupling"_fix_qmmm.html
|
||||
"path-integral molecular dynamics (PIMD)"_fix_ipi.html and "this as well"_fix_pimd.html
|
||||
Monte Carlo via "GCMC"_fix_gcmc.html and "tfMC"_fix_tfmc.html and "atom swapping"_fix_swap.html
|
||||
"Direct Simulation Monte Carlo"_pair_dsmc.html for low-density fluids
|
||||
"Peridynamics mesoscale modeling"_pair_peri.html
|
||||
"Lattice Boltzmann fluid"_fix_lb_fluid.html
|
||||
"targeted"_fix_tmd.html and "steered"_fix_smd.html molecular dynamics
|
||||
"two-temperature electron model"_fix_ttm.html :ul
|
||||
|
||||
:line
|
||||
|
||||
1.3 LAMMPS non-features :link(intro_3),h4
|
||||
|
||||
LAMMPS is designed to efficiently compute Newton's equations of motion
|
||||
for a system of interacting particles. Many of the tools needed to
|
||||
pre- and post-process the data for such simulations are not included
|
||||
in the LAMMPS kernel for several reasons:
|
||||
|
||||
the desire to keep LAMMPS simple
|
||||
they are not parallel operations
|
||||
other codes already do them
|
||||
limited development resources :ul
|
||||
|
||||
Specifically, LAMMPS itself does not:
|
||||
|
||||
run thru a GUI
|
||||
build molecular systems
|
||||
assign force-field coefficients automagically
|
||||
perform sophisticated analyses of your MD simulation
|
||||
visualize your MD simulation
|
||||
plot your output data :ul
|
||||
|
||||
A few tools for pre- and post-processing tasks are provided as part of
|
||||
the LAMMPS package; they are described in "this
|
||||
section"_Section_tools.html. However, many people use other codes or
|
||||
write their own tools for these tasks.
|
||||
|
||||
As noted above, our group has also written and released a separate
|
||||
toolkit called "Pizza.py"_pizza which addresses some of the listed
|
||||
bullets. It provides tools for doing setup, analysis, plotting, and
|
||||
visualization for LAMMPS simulations. Pizza.py is written in
|
||||
"Python"_python and is available for download from "the Pizza.py WWW
|
||||
site"_pizza.
|
||||
|
||||
LAMMPS requires as input a list of initial atom coordinates and types,
|
||||
molecular topology information, and force-field coefficients assigned
|
||||
to all atoms and bonds. LAMMPS will not build molecular systems and
|
||||
assign force-field parameters for you.
|
||||
|
||||
For atomic systems LAMMPS provides a "create_atoms"_create_atoms.html
|
||||
command which places atoms on solid-state lattices (fcc, bcc,
|
||||
user-defined, etc). Assigning small numbers of force field
|
||||
coefficients can be done via the "pair coeff"_pair_coeff.html, "bond
|
||||
coeff"_bond_coeff.html, "angle coeff"_angle_coeff.html, etc commands.
|
||||
For molecular systems or more complicated simulation geometries, users
|
||||
typically use another code as a builder and convert its output to
|
||||
LAMMPS input format, or write their own code to generate atom
|
||||
coordinate and molecular topology for LAMMPS to read in.
|
||||
|
||||
For complicated molecular systems (e.g. a protein), a multitude of
|
||||
topology information and hundreds of force-field coefficients must
|
||||
typically be specified. We suggest you use a program like
|
||||
"CHARMM"_charmm or "AMBER"_amber or other molecular builders to setup
|
||||
such problems and dump its information to a file. You can then
|
||||
reformat the file as LAMMPS input. Some of the tools in "this
|
||||
section"_Section_tools.html can assist in this process.
|
||||
|
||||
Similarly, LAMMPS creates output files in a simple format. Most users
|
||||
post-process these files with their own analysis tools or re-format
|
||||
them for input into other programs, including visualization packages.
|
||||
If you are convinced you need to compute something on-the-fly as
|
||||
LAMMPS runs, see "Section_modify"_Section_modify.html for a discussion
|
||||
of how you can use the "dump"_dump.html and "compute"_compute.html and
|
||||
"fix"_fix.html commands to print out data of your choosing. Keep in
|
||||
mind that complicated computations can slow down the molecular
|
||||
dynamics timestepping, particularly if the computations are not
|
||||
parallel, so it is often better to leave such analysis to
|
||||
post-processing codes.
|
||||
|
||||
A very simple (yet fast) visualizer is provided with the LAMMPS
|
||||
package - see the "xmovie"_Section_tools.html#xmovie tool in "this
|
||||
section"_Section_tools.html. It creates xyz projection views of
|
||||
atomic coordinates and animates them. We find it very useful for
|
||||
debugging purposes. For high-quality visualization we recommend the
|
||||
following packages:
|
||||
|
||||
"VMD"_http://www.ks.uiuc.edu/Research/vmd
|
||||
"AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
|
||||
"PyMol"_http://pymol.sourceforge.net
|
||||
"Raster3d"_http://www.bmsc.washington.edu/raster3d/raster3d.html
|
||||
"RasMol"_http://www.openrasmol.org :ul
|
||||
|
||||
Other features that LAMMPS does not yet (and may never) support are
|
||||
discussed in "Section_history"_Section_history.html.
|
||||
|
||||
Finally, these are freely-available molecular dynamics codes, most of
|
||||
them parallel, which may be well-suited to the problems you want to
|
||||
model. They can also be used in conjunction with LAMMPS to perform
|
||||
complementary modeling tasks.
|
||||
|
||||
"CHARMM"_charmm
|
||||
"AMBER"_amber
|
||||
"NAMD"_namd
|
||||
"NWCHEM"_nwchem
|
||||
"DL_POLY"_dlpoly
|
||||
"Tinker"_tinker :ul
|
||||
|
||||
:link(charmm,http://www.scripps.edu/brooks)
|
||||
:link(amber,http://amber.scripps.edu)
|
||||
:link(namd,http://www.ks.uiuc.edu/Research/namd/)
|
||||
:link(nwchem,http://www.emsl.pnl.gov/docs/nwchem/nwchem.html)
|
||||
:link(dlpoly,http://www.cse.clrc.ac.uk/msi/software/DL_POLY)
|
||||
:link(tinker,http://dasher.wustl.edu/tinker)
|
||||
|
||||
CHARMM, AMBER, NAMD, NWCHEM, and Tinker are designed primarily for
|
||||
modeling biological molecules. CHARMM and AMBER use
|
||||
atom-decomposition (replicated-data) strategies for parallelism; NAMD
|
||||
and NWCHEM use spatial-decomposition approaches, similar to LAMMPS.
|
||||
Tinker is a serial code. DL_POLY includes potentials for a variety of
|
||||
biological and non-biological materials; both a replicated-data and
|
||||
spatial-decomposition version exist.
|
||||
|
||||
:line
|
||||
|
||||
1.4 Open source distribution :link(intro_4),h4
|
||||
|
||||
LAMMPS comes with no warranty of any kind. As each source file states
|
||||
in its header, it is a copyrighted code that is distributed free-of-
|
||||
charge, under the terms of the "GNU Public License"_gnu (GPL). This
|
||||
is often referred to as open-source distribution - see
|
||||
"www.gnu.org"_gnuorg or "www.opensource.org"_opensource for more
|
||||
details. The legal text of the GPL is in the LICENSE file that is
|
||||
included in the LAMMPS distribution.
|
||||
|
||||
:link(gnuorg,http://www.gnu.org)
|
||||
:link(opensource,http://www.opensource.org)
|
||||
|
||||
Here is a summary of what the GPL means for LAMMPS users:
|
||||
|
||||
(1) Anyone is free to use, modify, or extend LAMMPS in any way they
|
||||
choose, including for commercial purposes.
|
||||
|
||||
(2) If you distribute a modified version of LAMMPS, it must remain
|
||||
open-source, meaning you distribute it under the terms of the GPL.
|
||||
You should clearly annotate such a code as a derivative version of
|
||||
LAMMPS.
|
||||
|
||||
(3) If you release any code that includes LAMMPS source code, then it
|
||||
must also be open-sourced, meaning you distribute it under the terms
|
||||
of the GPL.
|
||||
|
||||
(4) If you give LAMMPS files to someone else, the GPL LICENSE file and
|
||||
source file headers (including the copyright and GPL notices) should
|
||||
remain part of the code.
|
||||
|
||||
In the spirit of an open-source code, these are various ways you can
|
||||
contribute to making LAMMPS better. You can send email to the
|
||||
"developers"_http://lammps.sandia.gov/authors.html on any of these
|
||||
items.
|
||||
|
||||
Point prospective users to the "LAMMPS WWW Site"_lws. Mention it in
|
||||
talks or link to it from your WWW site. :ulb,l
|
||||
|
||||
If you find an error or omission in this manual or on the "LAMMPS WWW
|
||||
Site"_lws, or have a suggestion for something to clarify or include,
|
||||
send an email to the
|
||||
"developers"_http://lammps.sandia.gov/authors.html. :l
|
||||
|
||||
If you find a bug, "Section_errors 2"_Section_errors.html#err_2
|
||||
describes how to report it. :l
|
||||
|
||||
If you publish a paper using LAMMPS results, send the citation (and
|
||||
any cool pictures or movies if you like) to add to the Publications,
|
||||
Pictures, and Movies pages of the "LAMMPS WWW Site"_lws, with links
|
||||
and attributions back to you. :l
|
||||
|
||||
Create a new Makefile.machine that can be added to the src/MAKE
|
||||
directory. :l
|
||||
|
||||
The tools sub-directory of the LAMMPS distribution has various
|
||||
stand-alone codes for pre- and post-processing of LAMMPS data. More
|
||||
details are given in "Section_tools"_Section_tools.html. If you write
|
||||
a new tool that users will find useful, it can be added to the LAMMPS
|
||||
distribution. :l
|
||||
|
||||
LAMMPS is designed to be easy to extend with new code for features
|
||||
like potentials, boundary conditions, diagnostic computations, etc.
|
||||
"This section"_Section_modify.html gives details. If you add a
|
||||
feature of general interest, it can be added to the LAMMPS
|
||||
distribution. :l
|
||||
|
||||
The Benchmark page of the "LAMMPS WWW Site"_lws lists LAMMPS
|
||||
performance on various platforms. The files needed to run the
|
||||
benchmarks are part of the LAMMPS distribution. If your machine is
|
||||
sufficiently different from those listed, your timing data can be
|
||||
added to the page. :l
|
||||
|
||||
You can send feedback for the User Comments page of the "LAMMPS WWW
|
||||
Site"_lws. It might be added to the page. No promises. :l
|
||||
|
||||
Cash. Small denominations, unmarked bills preferred. Paper sack OK.
|
||||
Leave on desk. VISA also accepted. Chocolate chip cookies
|
||||
encouraged. :ule,l
|
||||
|
||||
:line
|
||||
|
||||
1.5 Acknowledgments and citations :h4,link(intro_5)
|
||||
|
||||
LAMMPS development has been funded by the "US Department of
|
||||
Energy"_doe (DOE), through its CRADA, LDRD, ASCI, and Genomes-to-Life
|
||||
programs and its "OASCR"_oascr and "OBER"_ober offices.
|
||||
|
||||
Specifically, work on the latest version was funded in part by the US
|
||||
Department of Energy's Genomics:GTL program
|
||||
("www.doegenomestolife.org"_gtl) under the "project"_ourgtl, "Carbon
|
||||
Sequestration in Synechococcus Sp.: From Molecular Machines to
|
||||
Hierarchical Modeling".
|
||||
|
||||
:link(doe,http://www.doe.gov)
|
||||
:link(gtl,http://www.doegenomestolife.org)
|
||||
:link(ourgtl,http://www.genomes2life.org)
|
||||
:link(oascr,http://www.sc.doe.gov/ascr/home.html)
|
||||
:link(ober,http://www.er.doe.gov/production/ober/ober_top.html)
|
||||
|
||||
The following paper describe the basic parallel algorithms used in
|
||||
LAMMPS. If you use LAMMPS results in your published work, please cite
|
||||
this paper and include a pointer to the "LAMMPS WWW Site"_lws
|
||||
(http://lammps.sandia.gov):
|
||||
|
||||
S. J. Plimpton, [Fast Parallel Algorithms for Short-Range Molecular
|
||||
Dynamics], J Comp Phys, 117, 1-19 (1995).
|
||||
|
||||
Other papers describing specific algorithms used in LAMMPS are listed
|
||||
under the "Citing LAMMPS link"_http://lammps.sandia.gov/cite.html of
|
||||
the LAMMPS WWW page.
|
||||
|
||||
The "Publications link"_http://lammps.sandia.gov/papers.html on the
|
||||
LAMMPS WWW page lists papers that have cited LAMMPS. If your paper is
|
||||
not listed there for some reason, feel free to send us the info. If
|
||||
the simulations in your paper produced cool pictures or animations,
|
||||
we'll be pleased to add them to the
|
||||
"Pictures"_http://lammps.sandia.gov/pictures.html or
|
||||
"Movies"_http://lammps.sandia.gov/movies.html pages of the LAMMPS WWW
|
||||
site.
|
||||
|
||||
The core group of LAMMPS developers is at Sandia National Labs:
|
||||
|
||||
Steve Plimpton, sjplimp at sandia.gov
|
||||
Aidan Thompson, athomps at sandia.gov
|
||||
Paul Crozier, pscrozi at sandia.gov :ul
|
||||
|
||||
The following folks are responsible for significant contributions to
|
||||
the code, or other aspects of the LAMMPS development effort. Many of
|
||||
the packages they have written are somewhat unique to LAMMPS and the
|
||||
code would not be as general-purpose as it is without their expertise
|
||||
and efforts.
|
||||
|
||||
Axel Kohlmeyer (Temple U), akohlmey at gmail.com, SVN and Git repositories, indefatigable mail list responder, USER-CG-CMM and USER-OMP packages
|
||||
Roy Pollock (LLNL), Ewald and PPPM solvers
|
||||
Mike Brown (ORNL), brownw at ornl.gov, GPU package
|
||||
Greg Wagner (Sandia), gjwagne at sandia.gov, MEAM package for MEAM potential
|
||||
Mike Parks (Sandia), mlparks at sandia.gov, PERI package for Peridynamics
|
||||
Rudra Mukherjee (JPL), Rudranarayan.M.Mukherjee at jpl.nasa.gov, POEMS package for articulated rigid body motion
|
||||
Reese Jones (Sandia) and collaborators, rjones at sandia.gov, USER-ATC package for atom/continuum coupling
|
||||
Ilya Valuev (JIHT), valuev at physik.hu-berlin.de, USER-AWPMD package for wave-packet MD
|
||||
Christian Trott (U Tech Ilmenau), christian.trott at tu-ilmenau.de, USER-CUDA package
|
||||
Andres Jaramillo-Botero (Caltech), ajaramil at wag.caltech.edu, USER-EFF package for electron force field
|
||||
Christoph Kloss (JKU), Christoph.Kloss at jku.at, USER-LIGGGHTS package for granular models and granular/fluid coupling
|
||||
Metin Aktulga (LBL), hmaktulga at lbl.gov, USER-REAXC package for C version of ReaxFF
|
||||
Georg Gunzenmuller (EMI), georg.ganzenmueller at emi.fhg.de, USER-SPH package :ul
|
||||
|
||||
As discussed in "Section_history"_Section_history.html, LAMMPS
|
||||
originated as a cooperative project between DOE labs and industrial
|
||||
partners. Folks involved in the design and testing of the original
|
||||
version of LAMMPS were the following:
|
||||
|
||||
John Carpenter (Mayo Clinic, formerly at Cray Research)
|
||||
Terry Stouch (Lexicon Pharmaceuticals, formerly at Bristol Myers Squibb)
|
||||
Steve Lustig (Dupont)
|
||||
Jim Belak (LLNL) :ul
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,776 +0,0 @@
|
||||
"Previous Section"_Section_tools.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Section_python.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
10. Modifying & extending LAMMPS :h3
|
||||
|
||||
This section describes how to customize LAMMPS by modifying
|
||||
and extending its source code.
|
||||
|
||||
10.1 "Atom styles"_#mod_1
|
||||
10.2 "Bond, angle, dihedral, improper potentials"_#mod_2
|
||||
10.3 "Compute styles"_#mod_3
|
||||
10.4 "Dump styles"_#mod_4
|
||||
10.5 "Dump custom output options"_#mod_5
|
||||
10.6 "Fix styles"_#mod_6 which include integrators, \
|
||||
temperature and pressure control, force constraints, \
|
||||
boundary conditions, diagnostic output, etc
|
||||
10.7 "Input script commands"_mod_7
|
||||
10.8 "Kspace computations"_#mod_8
|
||||
10.9 "Minimization styles"_#mod_9
|
||||
10.10 "Pairwise potentials"_#mod_10
|
||||
10.11 "Region styles"_#mod_11
|
||||
10.12 "Body styles"_#mod_12
|
||||
10.13 "Thermodynamic output options"_#mod_13
|
||||
10.14 "Variable options"_#mod_14
|
||||
10.15 "Submitting new features for inclusion in LAMMPS"_#mod_15 :all(b)
|
||||
|
||||
LAMMPS is designed in a modular fashion so as to be easy to modify and
|
||||
extend with new functionality. In fact, about 75% of its source code
|
||||
is files added in this fashion.
|
||||
|
||||
In this section, changes and additions users can make are listed along
|
||||
with minimal instructions. If you add a new feature to LAMMPS and
|
||||
think it will be of interest to general users, we encourage you to
|
||||
submit it to the developers for inclusion in the released version of
|
||||
LAMMPS. Information about how to do this is provided
|
||||
"below"_#mod_14.
|
||||
|
||||
The best way to add a new feature is to find a similar feature in
|
||||
LAMMPS and look at the corresponding source and header files to figure
|
||||
out what it does. You will need some knowledge of C++ to be able to
|
||||
understand the hi-level structure of LAMMPS and its class
|
||||
organization, but functions (class methods) that do actual
|
||||
computations are written in vanilla C-style code and operate on simple
|
||||
C-style data structures (vectors and arrays).
|
||||
|
||||
Most of the new features described in this section require you to
|
||||
write a new C++ derived class (except for exceptions described below,
|
||||
where you can make small edits to existing files). Creating a new
|
||||
class requires 2 files, a source code file (*.cpp) and a header file
|
||||
(*.h). The derived class must provide certain methods to work as a
|
||||
new option. Depending on how different your new feature is compared
|
||||
to existing features, you can either derive from the base class
|
||||
itself, or from a derived class that already exists. Enabling LAMMPS
|
||||
to invoke the new class is as simple as putting the two source
|
||||
files in the src dir and re-building LAMMPS.
|
||||
|
||||
The advantage of C++ and its object-orientation is that all the code
|
||||
and variables needed to define the new feature are in the 2 files you
|
||||
write, and thus shouldn't make the rest of LAMMPS more complex or
|
||||
cause side-effect bugs.
|
||||
|
||||
Here is a concrete example. Suppose you write 2 files pair_foo.cpp
|
||||
and pair_foo.h that define a new class PairFoo that computes pairwise
|
||||
potentials described in the classic 1997 "paper"_#Foo by Foo, et al.
|
||||
If you wish to invoke those potentials in a LAMMPS input script with a
|
||||
command like
|
||||
|
||||
pair_style foo 0.1 3.5 :pre
|
||||
|
||||
then your pair_foo.h file should be structured as follows:
|
||||
|
||||
#ifdef PAIR_CLASS
|
||||
PairStyle(foo,PairFoo)
|
||||
#else
|
||||
...
|
||||
(class definition for PairFoo)
|
||||
...
|
||||
#endif :pre
|
||||
|
||||
where "foo" is the style keyword in the pair_style command, and
|
||||
PairFoo is the class name defined in your pair_foo.cpp and pair_foo.h
|
||||
files.
|
||||
|
||||
When you re-build LAMMPS, your new pairwise potential becomes part of
|
||||
the executable and can be invoked with a pair_style command like the
|
||||
example above. Arguments like 0.1 and 3.5 can be defined and
|
||||
processed by your new class.
|
||||
|
||||
As illustrated by this pairwise example, many kinds of options are
|
||||
referred to in the LAMMPS documentation as the "style" of a particular
|
||||
command.
|
||||
|
||||
The instructions below give the header file for the base class that
|
||||
these styles are derived from. Public variables in that file are ones
|
||||
used and set by the derived classes which are also used by the base
|
||||
class. Sometimes they are also used by the rest of LAMMPS. Virtual
|
||||
functions in the base class header file which are set = 0 are ones you
|
||||
must define in your new derived class to give it the functionality
|
||||
LAMMPS expects. Virtual functions that are not set to 0 are functions
|
||||
you can optionally define.
|
||||
|
||||
Additionally, new output options can be added directly to the
|
||||
thermo.cpp, dump_custom.cpp, and variable.cpp files as explained
|
||||
below.
|
||||
|
||||
Here are additional guidelines for modifying LAMMPS and adding new
|
||||
functionality:
|
||||
|
||||
Think about whether what you want to do would be better as a pre- or
|
||||
post-processing step. Many computations are more easily and more
|
||||
quickly done that way. :ulb,l
|
||||
|
||||
Don't do anything within the timestepping of a run that isn't
|
||||
parallel. E.g. don't accumulate a bunch of data on a single processor
|
||||
and analyze it. You run the risk of seriously degrading the parallel
|
||||
efficiency. :l
|
||||
|
||||
If your new feature reads arguments or writes output, make sure you
|
||||
follow the unit conventions discussed by the "units"_units.html
|
||||
command. :l
|
||||
|
||||
If you add something you think is truly useful and doesn't impact
|
||||
LAMMPS performance when it isn't used, send an email to the
|
||||
"developers"_http://lammps.sandia.gov/authors.html. We might be
|
||||
interested in adding it to the LAMMPS distribution. See further
|
||||
details on this at the bottom of this page. :l,ule
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
10.1 Atom styles :link(mod_1),h4
|
||||
|
||||
Classes that define an "atom style"_atom_style.html are derived from
|
||||
the AtomVec class and managed by the Atom class. The atom style
|
||||
determines what attributes are associated with an atom. A new atom
|
||||
style can be created if one of the existing atom styles does not
|
||||
define all the attributes you need to store and communicate with
|
||||
atoms.
|
||||
|
||||
Atom_vec_atomic.cpp is a simple example of an atom style.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See atom_vec.h for details.
|
||||
|
||||
init: one time setup (optional)
|
||||
grow: re-allocate atom arrays to longer lengths (required)
|
||||
grow_reset: make array pointers in Atom and AtomVec classes consistent (required)
|
||||
copy: copy info for one atom to another atom's array locations (required)
|
||||
pack_comm: store an atom's info in a buffer communicated every timestep (required)
|
||||
pack_comm_vel: add velocity info to communication buffer (required)
|
||||
pack_comm_hybrid: store extra info unique to this atom style (optional)
|
||||
unpack_comm: retrieve an atom's info from the buffer (required)
|
||||
unpack_comm_vel: also retrieve velocity info (required)
|
||||
unpack_comm_hybrid: retreive extra info unique to this atom style (optional)
|
||||
pack_reverse: store an atom's info in a buffer communicating partial forces (required)
|
||||
pack_reverse_hybrid: store extra info unique to this atom style (optional)
|
||||
unpack_reverse: retrieve an atom's info from the buffer (required)
|
||||
unpack_reverse_hybrid: retreive extra info unique to this atom style (optional)
|
||||
pack_border: store an atom's info in a buffer communicated on neighbor re-builds (required)
|
||||
pack_border_vel: add velocity info to buffer (required)
|
||||
pack_border_hybrid: store extra info unique to this atom style (optional)
|
||||
unpack_border: retrieve an atom's info from the buffer (required)
|
||||
unpack_border_vel: also retrieve velocity info (required)
|
||||
unpack_border_hybrid: retreive extra info unique to this atom style (optional)
|
||||
pack_exchange: store all an atom's info to migrate to another processor (required)
|
||||
unpack_exchange: retrieve an atom's info from the buffer (required)
|
||||
size_restart: number of restart quantities associated with proc's atoms (required)
|
||||
pack_restart: pack atom quantities into a buffer (required)
|
||||
unpack_restart: unpack atom quantities from a buffer (required)
|
||||
create_atom: create an individual atom of this style (required)
|
||||
data_atom: parse an atom line from the data file (required)
|
||||
data_atom_hybrid: parse additional atom info unique to this atom style (optional)
|
||||
data_vel: parse one line of velocity information from data file (optional)
|
||||
data_vel_hybrid: parse additional velocity data unique to this atom style (optional)
|
||||
memory_usage: tally memory allocated by atom arrays (required) :tb(s=:)
|
||||
|
||||
The constructor of the derived class sets values for several variables
|
||||
that you must set when defining a new atom style, which are documented
|
||||
in atom_vec.h. New atom arrays are defined in atom.cpp. Search for
|
||||
the word "customize" and you will find locations you will need to
|
||||
modify.
|
||||
|
||||
NOTE: It is possible to add some attributes, such as a molecule ID, to
|
||||
atom styles that do not have them via the "fix
|
||||
property/atom"_fix_property_atom.html command. This command also
|
||||
allows new custom attributes consisting of extra integer or
|
||||
floating-point values to be added to atoms. See the "fix
|
||||
property/atom"_fix_property_atom.html doc page for examples of cases
|
||||
where this is useful and details on how to initialize, access, and
|
||||
output the custom values.
|
||||
|
||||
New "pair styles"_pair_style.html, "fixes"_fix.html, or
|
||||
"computes"_compute.html can be added to LAMMPS, as discussed below.
|
||||
The code for these classes can use the per-atom properties defined by
|
||||
fix property/atom. The Atom class has a find_custom() method that is
|
||||
useful in this context:
|
||||
|
||||
int index = atom->find_custom(char *name, int &flag); :pre
|
||||
|
||||
The "name" of a custom attribute, as specified in the "fix
|
||||
property/atom"_fix_property_atom.html command, is checked to verify
|
||||
that it exists and its index is returned. The method also sets flag =
|
||||
0/1 depending on whether it is an integer or floating-point attribute.
|
||||
The vector of values associated with the attribute can then be
|
||||
accessed using the returned index as
|
||||
|
||||
int *ivector = atom->ivector\[index\];
|
||||
double *dvector = atom->dvector\[index\]; :pre
|
||||
|
||||
Ivector or dvector are vectors of length Nlocal = # of owned atoms,
|
||||
which store the attributes of individual atoms.
|
||||
|
||||
:line
|
||||
|
||||
10.2 Bond, angle, dihedral, improper potentials :link(mod_2),h4
|
||||
|
||||
Classes that compute molecular interactions are derived from the Bond,
|
||||
Angle, Dihedral, and Improper classes. New styles can be created to
|
||||
add new potentials to LAMMPS.
|
||||
|
||||
Bond_harmonic.cpp is the simplest example of a bond style. Ditto for
|
||||
the harmonic forms of the angle, dihedral, and improper style
|
||||
commands.
|
||||
|
||||
Here is a brief description of common methods you define in your
|
||||
new derived class. See bond.h, angle.h, dihedral.h, and improper.h
|
||||
for details and specific additional methods.
|
||||
|
||||
init: check if all coefficients are set, calls {init_style} (optional)
|
||||
init_style: check if style specific conditions are met (optional)
|
||||
compute: compute the molecular interactions (required)
|
||||
settings: apply global settings for all types (optional)
|
||||
coeff: set coefficients for one type (required)
|
||||
equilibrium_distance: length of bond, used by SHAKE (required, bond only)
|
||||
equilibrium_angle: opening of angle, used by SHAKE (required, angle only)
|
||||
write & read_restart: writes/reads coeffs to restart files (required)
|
||||
single: force and energy of a single bond or angle (required, bond or angle only)
|
||||
memory_usage: tally memory allocated by the style (optional) :tb(s=:)
|
||||
|
||||
:line
|
||||
|
||||
10.3 Compute styles :link(mod_3),h4
|
||||
|
||||
Classes that compute scalar and vector quantities like temperature
|
||||
and the pressure tensor, as well as classes that compute per-atom
|
||||
quantities like kinetic energy and the centro-symmetry parameter
|
||||
are derived from the Compute class. New styles can be created
|
||||
to add new calculations to LAMMPS.
|
||||
|
||||
Compute_temp.cpp is a simple example of computing a scalar
|
||||
temperature. Compute_ke_atom.cpp is a simple example of computing
|
||||
per-atom kinetic energy.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See compute.h for details.
|
||||
|
||||
init: perform one time setup (required)
|
||||
init_list: neighbor list setup, if needed (optional)
|
||||
compute_scalar: compute a scalar quantity (optional)
|
||||
compute_vector: compute a vector of quantities (optional)
|
||||
compute_peratom: compute one or more quantities per atom (optional)
|
||||
compute_local: compute one or more quantities per processor (optional)
|
||||
pack_comm: pack a buffer with items to communicate (optional)
|
||||
unpack_comm: unpack the buffer (optional)
|
||||
pack_reverse: pack a buffer with items to reverse communicate (optional)
|
||||
unpack_reverse: unpack the buffer (optional)
|
||||
remove_bias: remove velocity bias from one atom (optional)
|
||||
remove_bias_all: remove velocity bias from all atoms in group (optional)
|
||||
restore_bias: restore velocity bias for one atom after remove_bias (optional)
|
||||
restore_bias_all: same as before, but for all atoms in group (optional)
|
||||
pair_tally_callback: callback function for {tally}-style computes (optional).
|
||||
memory_usage: tally memory usage (optional) :tb(s=:)
|
||||
|
||||
Tally-style computes are a special case, as their computation is done
|
||||
in two stages: the callback function is registered with the pair style
|
||||
and then called from the Pair::ev_tally() function, which is called for
|
||||
each pair after force and energy has been computed for this pair. Then
|
||||
the tallied values are retrieved with the standard compute_scalar or
|
||||
compute_vector or compute_peratom methods. The USER-TALLY package
|
||||
provides {examples}_compute_tally.html for utilizing this mechanism.
|
||||
|
||||
:line
|
||||
|
||||
10.4 Dump styles :link(mod_4),h4
|
||||
10.5 Dump custom output options :link(mod_5),h4
|
||||
|
||||
Classes that dump per-atom info to files are derived from the Dump
|
||||
class. To dump new quantities or in a new format, a new derived dump
|
||||
class can be added, but it is typically simpler to modify the
|
||||
DumpCustom class contained in the dump_custom.cpp file.
|
||||
|
||||
Dump_atom.cpp is a simple example of a derived dump class.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See dump.h for details.
|
||||
|
||||
write_header: write the header section of a snapshot of atoms
|
||||
count: count the number of lines a processor will output
|
||||
pack: pack a proc's output data into a buffer
|
||||
write_data: write a proc's data to a file :tb(s=:)
|
||||
|
||||
See the "dump"_dump.html command and its {custom} style for a list of
|
||||
keywords for atom information that can already be dumped by
|
||||
DumpCustom. It includes options to dump per-atom info from Compute
|
||||
classes, so adding a new derived Compute class is one way to calculate
|
||||
new quantities to dump.
|
||||
|
||||
Alternatively, you can add new keywords to the dump custom command.
|
||||
Search for the word "customize" in dump_custom.cpp to see the
|
||||
half-dozen or so locations where code will need to be added.
|
||||
|
||||
:line
|
||||
|
||||
10.6 Fix styles :link(mod_6),h4
|
||||
|
||||
In LAMMPS, a "fix" is any operation that is computed during
|
||||
timestepping that alters some property of the system. Essentially
|
||||
everything that happens during a simulation besides force computation,
|
||||
neighbor list construction, and output, is a "fix". This includes
|
||||
time integration (update of coordinates and velocities), force
|
||||
constraints or boundary conditions (SHAKE or walls), and diagnostics
|
||||
(compute a diffusion coefficient). New styles can be created to add
|
||||
new options to LAMMPS.
|
||||
|
||||
Fix_setforce.cpp is a simple example of setting forces on atoms to
|
||||
prescribed values. There are dozens of fix options already in LAMMPS;
|
||||
choose one as a template that is similar to what you want to
|
||||
implement.
|
||||
|
||||
Here is a brief description of methods you can define in your new
|
||||
derived class. See fix.h for details.
|
||||
|
||||
setmask: determines when the fix is called during the timestep (required)
|
||||
init: initialization before a run (optional)
|
||||
setup_pre_exchange: called before atom exchange in setup (optional)
|
||||
setup_pre_force: called before force computation in setup (optional)
|
||||
setup: called immediately before the 1st timestep and after forces are computed (optional)
|
||||
min_setup_pre_force: like setup_pre_force, but for minimizations instead of MD runs (optional)
|
||||
min_setup: like setup, but for minimizations instead of MD runs (optional)
|
||||
initial_integrate: called at very beginning of each timestep (optional)
|
||||
pre_exchange: called before atom exchange on re-neighboring steps (optional)
|
||||
pre_neighbor: called before neighbor list build (optional)
|
||||
pre_force: called before pair & molecular forces are computed (optional)
|
||||
post_force: called after pair & molecular forces are computed and communicated (optional)
|
||||
final_integrate: called at end of each timestep (optional)
|
||||
end_of_step: called at very end of timestep (optional)
|
||||
write_restart: dumps fix info to restart file (optional)
|
||||
restart: uses info from restart file to re-initialize the fix (optional)
|
||||
grow_arrays: allocate memory for atom-based arrays used by fix (optional)
|
||||
copy_arrays: copy atom info when an atom migrates to a new processor (optional)
|
||||
pack_exchange: store atom's data in a buffer (optional)
|
||||
unpack_exchange: retrieve atom's data from a buffer (optional)
|
||||
pack_restart: store atom's data for writing to restart file (optional)
|
||||
unpack_restart: retrieve atom's data from a restart file buffer (optional)
|
||||
size_restart: size of atom's data (optional)
|
||||
maxsize_restart: max size of atom's data (optional)
|
||||
setup_pre_force_respa: same as setup_pre_force, but for rRESPA (optional)
|
||||
initial_integrate_respa: same as initial_integrate, but for rRESPA (optional)
|
||||
post_integrate_respa: called after the first half integration step is done in rRESPA (optional)
|
||||
pre_force_respa: same as pre_force, but for rRESPA (optional)
|
||||
post_force_respa: same as post_force, but for rRESPA (optional)
|
||||
final_integrate_respa: same as final_integrate, but for rRESPA (optional)
|
||||
min_pre_force: called after pair & molecular forces are computed in minimizer (optional)
|
||||
min_post_force: called after pair & molecular forces are computed and communicated in minmizer (optional)
|
||||
min_store: store extra data for linesearch based minimization on a LIFO stack (optional)
|
||||
min_pushstore: push the minimization LIFO stack one element down (optional)
|
||||
min_popstore: pop the minimization LIFO stack one element up (optional)
|
||||
min_clearstore: clear minimization LIFO stack (optional)
|
||||
min_step: reset or move forward on line search minimization (optional)
|
||||
min_dof: report number of degrees of freedom {added} by this fix in minimization (optional)
|
||||
max_alpha: report maximum allowed step size during linesearch minimization (optional)
|
||||
pack_comm: pack a buffer to communicate a per-atom quantity (optional)
|
||||
unpack_comm: unpack a buffer to communicate a per-atom quantity (optional)
|
||||
pack_reverse_comm: pack a buffer to reverse communicate a per-atom quantity (optional)
|
||||
unpack_reverse_comm: unpack a buffer to reverse communicate a per-atom quantity (optional)
|
||||
dof: report number of degrees of freedom {removed} by this fix during MD (optional)
|
||||
compute_scalar: return a global scalar property that the fix computes (optional)
|
||||
compute_vector: return a component of a vector property that the fix computes (optional)
|
||||
compute_array: return a component of an array property that the fix computes (optional)
|
||||
deform: called when the box size is changed (optional)
|
||||
reset_target: called when a change of the target temperature is requested during a run (optional)
|
||||
reset_dt: is called when a change of the time step is requested during a run (optional)
|
||||
modify_param: called when a fix_modify request is executed (optional)
|
||||
memory_usage: report memory used by fix (optional)
|
||||
thermo: compute quantities for thermodynamic output (optional) :tb(s=:)
|
||||
|
||||
Typically, only a small fraction of these methods are defined for a
|
||||
particular fix. Setmask is mandatory, as it determines when the fix
|
||||
will be invoked during the timestep. Fixes that perform time
|
||||
integration ({nve}, {nvt}, {npt}) implement initial_integrate() and
|
||||
final_integrate() to perform velocity Verlet updates. Fixes that
|
||||
constrain forces implement post_force().
|
||||
|
||||
Fixes that perform diagnostics typically implement end_of_step(). For
|
||||
an end_of_step fix, one of your fix arguments must be the variable
|
||||
"nevery" which is used to determine when to call the fix and you must
|
||||
set this variable in the constructor of your fix. By convention, this
|
||||
is the first argument the fix defines (after the ID, group-ID, style).
|
||||
|
||||
If the fix needs to store information for each atom that persists from
|
||||
timestep to timestep, it can manage that memory and migrate the info
|
||||
with the atoms as they move from processors to processor by
|
||||
implementing the grow_arrays, copy_arrays, pack_exchange, and
|
||||
unpack_exchange methods. Similarly, the pack_restart and
|
||||
unpack_restart methods can be implemented to store information about
|
||||
the fix in restart files. If you wish an integrator or force
|
||||
constraint fix to work with rRESPA (see the "run_style"_run_style.html
|
||||
command), the initial_integrate, post_force_integrate, and
|
||||
final_integrate_respa methods can be implemented. The thermo method
|
||||
enables a fix to contribute values to thermodynamic output, as printed
|
||||
quantities and/or to be summed to the potential energy of the system.
|
||||
|
||||
:line
|
||||
|
||||
10.7 Input script commands :link(mod_7),h4
|
||||
|
||||
New commands can be added to LAMMPS input scripts by adding new
|
||||
classes that have a "command" method. For example, the create_atoms,
|
||||
read_data, velocity, and run commands are all implemented in this
|
||||
fashion. When such a command is encountered in the LAMMPS input
|
||||
script, LAMMPS simply creates a class with the corresponding name,
|
||||
invokes the "command" method of the class, and passes it the arguments
|
||||
from the input script. The command method can perform whatever
|
||||
operations it wishes on LAMMPS data structures.
|
||||
|
||||
The single method your new class must define is as follows:
|
||||
|
||||
command: operations performed by the new command :tb(s=:)
|
||||
|
||||
Of course, the new class can define other methods and variables as
|
||||
needed.
|
||||
|
||||
:line
|
||||
|
||||
10.8 Kspace computations :link(mod_8),h4
|
||||
|
||||
Classes that compute long-range Coulombic interactions via K-space
|
||||
representations (Ewald, PPPM) are derived from the KSpace class. New
|
||||
styles can be created to add new K-space options to LAMMPS.
|
||||
|
||||
Ewald.cpp is an example of computing K-space interactions.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See kspace.h for details.
|
||||
|
||||
init: initialize the calculation before a run
|
||||
setup: computation before the 1st timestep of a run
|
||||
compute: every-timestep computation
|
||||
memory_usage: tally of memory usage :tb(s=:)
|
||||
|
||||
:line
|
||||
|
||||
10.9 Minimization styles :link(mod_9),h4
|
||||
|
||||
Classes that perform energy minimization derived from the Min class.
|
||||
New styles can be created to add new minimization algorithms to
|
||||
LAMMPS.
|
||||
|
||||
Min_cg.cpp is an example of conjugate gradient minimization.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See min.h for details.
|
||||
|
||||
init: initialize the minimization before a run
|
||||
run: perform the minimization
|
||||
memory_usage: tally of memory usage :tb(s=:)
|
||||
|
||||
:line
|
||||
|
||||
10.10 Pairwise potentials :link(mod_10),h4
|
||||
|
||||
Classes that compute pairwise interactions are derived from the Pair
|
||||
class. In LAMMPS, pairwise calculation include manybody potentials
|
||||
such as EAM or Tersoff where particles interact without a static bond
|
||||
topology. New styles can be created to add new pair potentials to
|
||||
LAMMPS.
|
||||
|
||||
Pair_lj_cut.cpp is a simple example of a Pair class, though it
|
||||
includes some optional methods to enable its use with rRESPA.
|
||||
|
||||
Here is a brief description of the class methods in pair.h:
|
||||
|
||||
compute: workhorse routine that computes pairwise interactions
|
||||
settings: reads the input script line with arguments you define
|
||||
coeff: set coefficients for one i,j type pair
|
||||
init_one: perform initialization for one i,j type pair
|
||||
init_style: initialization specific to this pair style
|
||||
write & read_restart: write/read i,j pair coeffs to restart files
|
||||
write & read_restart_settings: write/read global settings to restart files
|
||||
single: force and energy of a single pairwise interaction between 2 atoms
|
||||
compute_inner/middle/outer: versions of compute used by rRESPA :tb(s=:)
|
||||
|
||||
The inner/middle/outer routines are optional.
|
||||
|
||||
:line
|
||||
|
||||
10.11 Region styles :link(mod_11),h4
|
||||
|
||||
Classes that define geometric regions are derived from the Region
|
||||
class. Regions are used elsewhere in LAMMPS to group atoms, delete
|
||||
atoms to create a void, insert atoms in a specified region, etc. New
|
||||
styles can be created to add new region shapes to LAMMPS.
|
||||
|
||||
Region_sphere.cpp is an example of a spherical region.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See region.h for details.
|
||||
|
||||
inside: determine whether a point is in the region
|
||||
surface_interior: determine if a point is within a cutoff distance inside of surc
|
||||
surface_exterior: determine if a point is within a cutoff distance outside of surf
|
||||
shape_update : change region shape if set by time-depedent variable :tb(s=:)
|
||||
|
||||
:line
|
||||
|
||||
10.12 Body styles :link(mod_12),h4
|
||||
|
||||
Classes that define body particles are derived from the Body class.
|
||||
Body particles can represent complex entities, such as surface meshes
|
||||
of discrete points, collections of sub-particles, deformable objects,
|
||||
etc.
|
||||
|
||||
See "Section_howto 14"_Section_howto.html#howto_14 of the manual for
|
||||
an overview of using body particles and the "body"_body.html doc page
|
||||
for details on the various body styles LAMMPS supports. New styles
|
||||
can be created to add new kinds of body particles to LAMMPS.
|
||||
|
||||
Body_nparticle.cpp is an example of a body particle that is treated as
|
||||
a rigid body containing N sub-particles.
|
||||
|
||||
Here is a brief description of methods you define in your new derived
|
||||
class. See body.h for details.
|
||||
|
||||
data_body: process a line from the Bodies section of a data file
|
||||
noutrow: number of sub-particles output is generated for
|
||||
noutcol: number of values per-sub-particle output is generated for
|
||||
output: output values for the Mth sub-particle
|
||||
pack_comm_body: body attributes to communicate every timestep
|
||||
unpack_comm_body: unpacking of those attributes
|
||||
pack_border_body: body attributes to communicate when reneighboring is done
|
||||
unpack_border_body: unpacking of those attributes :tb(s=:)
|
||||
|
||||
:line
|
||||
|
||||
10.13 Thermodynamic output options :link(mod_13),h4
|
||||
|
||||
There is one class that computes and prints thermodynamic information
|
||||
to the screen and log file; see the file thermo.cpp.
|
||||
|
||||
There are two styles defined in thermo.cpp: "one" and "multi". There
|
||||
is also a flexible "custom" style which allows the user to explicitly
|
||||
list keywords for quantities to print when thermodynamic info is
|
||||
output. See the "thermo_style"_thermo_style.html command for a list
|
||||
of defined quantities.
|
||||
|
||||
The thermo styles (one, multi, etc) are simply lists of keywords.
|
||||
Adding a new style thus only requires defining a new list of keywords.
|
||||
Search for the word "customize" with references to "thermo style" in
|
||||
thermo.cpp to see the two locations where code will need to be added.
|
||||
|
||||
New keywords can also be added to thermo.cpp to compute new quantities
|
||||
for output. Search for the word "customize" with references to
|
||||
"keyword" in thermo.cpp to see the several locations where code will
|
||||
need to be added.
|
||||
|
||||
Note that the "thermo_style custom"_thermo.html command already allows
|
||||
for thermo output of quantities calculated by "fixes"_fix.html,
|
||||
"computes"_compute.html, and "variables"_variable.html. Thus, it may
|
||||
be simpler to compute what you wish via one of those constructs, than
|
||||
by adding a new keyword to the thermo command.
|
||||
|
||||
:line
|
||||
|
||||
10.14 Variable options :link(mod_14),h4
|
||||
|
||||
There is one class that computes and stores "variable"_variable.html
|
||||
information in LAMMPS; see the file variable.cpp. The value
|
||||
associated with a variable can be periodically printed to the screen
|
||||
via the "print"_print.html, "fix print"_fix_print.html, or
|
||||
"thermo_style custom"_thermo_style.html commands. Variables of style
|
||||
"equal" can compute complex equations that involve the following types
|
||||
of arguments:
|
||||
|
||||
thermo keywords = ke, vol, atoms, ...
|
||||
other variables = v_a, v_myvar, ...
|
||||
math functions = div(x,y), mult(x,y), add(x,y), ...
|
||||
group functions = mass(group), xcm(group,x), ...
|
||||
atom values = x\[123\], y\[3\], vx\[34\], ...
|
||||
compute values = c_mytemp\[0\], c_thermo_press\[3\], ... :pre
|
||||
|
||||
Adding keywords for the "thermo_style custom"_thermo_style.html command
|
||||
(which can then be accessed by variables) was discussed
|
||||
"here"_Section_modify.html#thermo on this page.
|
||||
|
||||
Adding a new math function of one or two arguments can be done by
|
||||
editing one section of the Variable::evaulate() method. Search for
|
||||
the word "customize" to find the appropriate location.
|
||||
|
||||
Adding a new group function can be done by editing one section of the
|
||||
Variable::evaulate() method. Search for the word "customize" to find
|
||||
the appropriate location. You may need to add a new method to the
|
||||
Group class as well (see the group.cpp file).
|
||||
|
||||
Accessing a new atom-based vector can be done by editing one section
|
||||
of the Variable::evaulate() method. Search for the word "customize"
|
||||
to find the appropriate location.
|
||||
|
||||
Adding new "compute styles"_compute.html (whose calculated values can
|
||||
then be accessed by variables) was discussed
|
||||
"here"_Section_modify.html#compute on this page.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
10.15 Submitting new features for inclusion in LAMMPS :link(mod_15),h4
|
||||
|
||||
We encourage users to submit new features to "the
|
||||
developers"_http://lammps.sandia.gov/authors.html that they add to
|
||||
LAMMPS, especially if you think they will be of interest to other
|
||||
users. The preferred way to do this is via GitHub. Once you have
|
||||
prepared the content described below, see "this
|
||||
tutorial"_tutorial_github.html for instructions on how to submit
|
||||
your changes or new files.
|
||||
|
||||
If the new features/files are broadly useful we may add them as core
|
||||
files to LAMMPS or as part of a "standard
|
||||
package"_Section_start.html#start_3. Else we will add them as a
|
||||
user-contributed file or package. Examples of user packages are in
|
||||
src sub-directories that start with USER. The USER-MISC package is
|
||||
simply a collection of (mostly) unrelated single files, which is the
|
||||
simplest way to have your contribution quickly added to the LAMMPS
|
||||
distribution. You can see a list of the both standard and user
|
||||
packages by typing "make package" in the LAMMPS src directory.
|
||||
|
||||
Note that by providing us files to release, you are agreeing to make
|
||||
them open-source, i.e. we can release them under the terms of the GPL,
|
||||
used as a license for the rest of LAMMPS. See "Section
|
||||
1.4"_Section_intro.html#intro_4 for details.
|
||||
|
||||
With user packages and files, all we are really providing (aside from
|
||||
the fame and fortune that accompanies having your name in the source
|
||||
code and on the "Authors page"_http://lammps.sandia.gov/authors.html
|
||||
of the "LAMMPS WWW site"_lws), is a means for you to distribute your
|
||||
work to the LAMMPS user community, and a mechanism for others to
|
||||
easily try out your new feature. This may help you find bugs or make
|
||||
contact with new collaborators. Note that you're also implicitly
|
||||
agreeing to support your code which means answer questions, fix bugs,
|
||||
and maintain it if LAMMPS changes in some way that breaks it (an
|
||||
unusual event).
|
||||
|
||||
NOTE: If you prefer to actively develop and support your add-on
|
||||
feature yourself, then you may wish to make it available for download
|
||||
from your own website, as a user package that LAMMPS users can add to
|
||||
their copy of LAMMPS. See the "Offsite LAMMPS packages and
|
||||
tools"_http://lammps.sandia.gov/offsite.html page of the LAMMPS web
|
||||
site for examples of groups that do this. We are happy to advertise
|
||||
your package and web site from that page. Simply email the
|
||||
"developers"_http://lammps.sandia.gov/authors.html with info about
|
||||
your package and we will post it there.
|
||||
|
||||
The previous sections of this doc page describe how to add new "style"
|
||||
files of various kinds to LAMMPS. Packages are simply collections of
|
||||
one or more new class files which are invoked as a new style within a
|
||||
LAMMPS input script. If designed correctly, these additions typically
|
||||
do not require changes to the main core of LAMMPS; they are simply
|
||||
add-on files. If you think your new feature requires non-trivial
|
||||
changes in core LAMMPS files, you'll need to "communicate with the
|
||||
developers"_http://lammps.sandia.gov/authors.html, since we may or may
|
||||
not want to make those changes. An example of a trivial change is
|
||||
making a parent-class method "virtual" when you derive a new child
|
||||
class from it.
|
||||
|
||||
Here are the steps you need to follow to submit a single file or user
|
||||
package for our consideration. Following these steps will save both
|
||||
you and us time. See existing files in packages in the src dir for
|
||||
examples.
|
||||
|
||||
All source files you provide must compile with the most current
|
||||
version of LAMMPS. :ulb,l
|
||||
|
||||
If you want your file(s) to be added to main LAMMPS or one of its
|
||||
standard packages, then it needs to be written in a style compatible
|
||||
with other LAMMPS source files. This is so the developers can
|
||||
understand it and hopefully maintain it. This basically means that
|
||||
the code accesses data structures, performs its operations, and is
|
||||
formatted similar to other LAMMPS source files, including the use of
|
||||
the error class for error and warning messages. :l
|
||||
|
||||
If you want your contribution to be added as a user-contributed
|
||||
feature, and it's a single file (actually a *.cpp and *.h file) it can
|
||||
rapidly be added to the USER-MISC directory. Send us the one-line
|
||||
entry to add to the USER-MISC/README file in that dir, along with the
|
||||
2 source files. You can do this multiple times if you wish to
|
||||
contribute several individual features. :l
|
||||
|
||||
If you want your contribution to be added as a user-contribution and
|
||||
it is several related featues, it is probably best to make it a user
|
||||
package directory with a name like USER-FOO. In addition to your new
|
||||
files, the directory should contain a README text file. The README
|
||||
should contain your name and contact information and a brief
|
||||
description of what your new package does. If your files depend on
|
||||
other LAMMPS style files also being installed (e.g. because your file
|
||||
is a derived class from the other LAMMPS class), then an Install.sh
|
||||
file is also needed to check for those dependencies. See other README
|
||||
and Install.sh files in other USER directories as examples. Send us a
|
||||
tarball of this USER-FOO directory. :l
|
||||
|
||||
Your new source files need to have the LAMMPS copyright, GPL notice,
|
||||
and your name and email address at the top, like other
|
||||
user-contributed LAMMPS source files. They need to create a class
|
||||
that is inside the LAMMPS namespace. If the file is for one of the
|
||||
USER packages, including USER-MISC, then we are not as picky about the
|
||||
coding style (see above). I.e. the files do not need to be in the
|
||||
same stylistic format and syntax as other LAMMPS files, though that
|
||||
would be nice for developers as well as users who try to read your
|
||||
code. :l
|
||||
|
||||
You must also create a documentation file for each new command or
|
||||
style you are adding to LAMMPS. This will be one file for a
|
||||
single-file feature. For a package, it might be several files. These
|
||||
are simple text files which we auto-convert to HTML. Thus they must
|
||||
be in the same format as other *.txt files in the lammps/doc directory
|
||||
for similar commands and styles; use one or more of them as a starting
|
||||
point. As appropriate, the text files can include links to equations
|
||||
(see doc/Eqs/*.tex for examples, we auto-create the associated JPG
|
||||
files), or figures (see doc/JPG for examples), or even additional PDF
|
||||
files with further details (see doc/PDF for examples). The doc page
|
||||
should also include literature citations as appropriate; see the
|
||||
bottom of doc/fix_nh.txt for examples and the earlier part of the same
|
||||
file for how to format the cite itself. The "Restrictions" section of
|
||||
the doc page should indicate that your command is only available if
|
||||
LAMMPS is built with the appropriate USER-MISC or USER-FOO package.
|
||||
See other user package doc files for examples of how to do this. The
|
||||
txt2html tool we use to convert to HTML can be downloaded from "this
|
||||
site"_http://www.sandia.gov/~sjplimp/download.html, so you can perform
|
||||
the HTML conversion yourself to proofread your doc page. :l
|
||||
|
||||
For a new package (or even a single command) you can include one or
|
||||
more example scripts. These should run in no more than 1 minute, even
|
||||
on a single processor, and not require large data files as input. See
|
||||
directories under examples/USER for examples of input scripts other
|
||||
users provided for their packages. :l
|
||||
|
||||
If there is a paper of yours describing your feature (either the
|
||||
algorithm/science behind the feature itself, or its initial usage, or
|
||||
its implementation in LAMMPS), you can add the citation to the *.cpp
|
||||
source file. See src/USER-EFF/atom_vec_electron.cpp for an example.
|
||||
A LaTeX citation is stored in a variable at the top of the file and a
|
||||
single line of code that references the variable is added to the
|
||||
constructor of the class. Whenever a user invokes your feature from
|
||||
their input script, this will cause LAMMPS to output the citation to a
|
||||
log.cite file and prompt the user to examine the file. Note that you
|
||||
should only use this for a paper you or your group authored.
|
||||
E.g. adding a cite in the code for a paper by Nose and Hoover if you
|
||||
write a fix that implements their integrator is not the intended
|
||||
usage. That kind of citation should just be in the doc page you
|
||||
provide. :l,ule
|
||||
|
||||
Finally, as a general rule-of-thumb, the more clear and
|
||||
self-explanatory you make your doc and README files, and the easier
|
||||
you make it for people to get started, e.g. by providing example
|
||||
scripts, the more likely it is that users will try out your new
|
||||
feature.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
:link(Foo)
|
||||
[(Foo)] Foo, Morefoo, and Maxfoo, J of Classic Potentials, 75, 345 (1997).
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,282 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>8. Performance & scalability — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
<link rel="next" title="9. Additional tools" href="Section_tools.html"/>
|
||||
<link rel="prev" title="7. Example problems" href="Section_example.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>8. Performance & scalability</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
<div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_tools.html" class="btn btn-neutral float-right" title="9. Additional tools" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Section_example.html" class="btn btn-neutral" title="7. Example problems" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="performance-scalability">
|
||||
<h1>8. Performance & scalability<a class="headerlink" href="#performance-scalability" title="Permalink to this headline">¶</a></h1>
|
||||
<p>Current LAMMPS performance is discussed on the Benchmarks page of the
|
||||
<a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW Site</a> where CPU timings and parallel efficiencies are
|
||||
listed. The page has several sections, which are briefly described
|
||||
below:</p>
|
||||
<ul class="simple">
|
||||
<li>CPU performance on 5 standard problems, strong and weak scaling</li>
|
||||
<li>GPU and Xeon Phi performance on same and related problems</li>
|
||||
<li>Comparison of cost of interatomic potentials</li>
|
||||
<li>Performance of huge, billion-atom problems</li>
|
||||
</ul>
|
||||
<p>The 5 standard problems are as follow:</p>
|
||||
<ol class="arabic simple">
|
||||
<li>LJ = atomic fluid, Lennard-Jones potential with 2.5 sigma cutoff (55</li>
|
||||
</ol>
|
||||
<blockquote>
|
||||
<div>neighbors per atom), NVE integration</div></blockquote>
|
||||
<ol class="arabic simple">
|
||||
<li>Chain = bead-spring polymer melt of 100-mer chains, FENE bonds and LJ
|
||||
pairwise interactions with a 2^(1/6) sigma cutoff (5 neighbors per
|
||||
atom), NVE integration</li>
|
||||
<li>EAM = metallic solid, Cu EAM potential with 4.95 Angstrom cutoff (45
|
||||
neighbors per atom), NVE integration</li>
|
||||
<li>Chute = granular chute flow, frictional history potential with 1.1
|
||||
sigma cutoff (7 neighbors per atom), NVE integration</li>
|
||||
<li>Rhodo = rhodopsin protein in solvated lipid bilayer, CHARMM force
|
||||
field with a 10 Angstrom LJ cutoff (440 neighbors per atom),
|
||||
particle-particle particle-mesh (PPPM) for long-range Coulombics, NPT
|
||||
integration</li>
|
||||
</ol>
|
||||
<p>Input files for these 5 problems are provided in the bench directory
|
||||
of the LAMMPS distribution. Each has 32,000 atoms and runs for 100
|
||||
timesteps. The size of the problem (number of atoms) can be varied
|
||||
using command-line switches as described in the bench/README file.
|
||||
This is an easy way to test performance and either strong or weak
|
||||
scalability on your machine.</p>
|
||||
<p>The bench directory includes a few log.* files that show performance
|
||||
of these 5 problems on 1 or 4 cores of Linux desktop. The bench/FERMI
|
||||
and bench/KEPLER dirs have input files and scripts and instructions
|
||||
for running the same (or similar) problems using OpenMP or GPU or Xeon
|
||||
Phi acceleration options. See the README files in those dirs and the
|
||||
<a class="reference internal" href="Section_accelerate.html"><em>Section accelerate</em></a> doc pages for
|
||||
instructions on how to build LAMMPS and run on that kind of hardware.</p>
|
||||
<p>The bench/POTENTIALS directory has input files which correspond to the
|
||||
table of results on the
|
||||
<span class="xref std std-ref">Potentials</span> section of
|
||||
the Benchmarks web page. So you can also run those test problems on
|
||||
your machine.</p>
|
||||
<p>The <span class="xref std std-ref">billion-atom</span> section
|
||||
of the Benchmarks web page has performance data for very large
|
||||
benchmark runs of simple Lennard-Jones (LJ) models, which use the
|
||||
bench/in.lj input script.</p>
|
||||
<hr class="docutils" />
|
||||
<p>For all the benchmarks, a useful metric is the CPU cost per atom per
|
||||
timestep. Since performance scales roughly linearly with problem size
|
||||
and timesteps for all LAMMPS models (i.e. inteatomic or coarse-grained
|
||||
potentials), the run time of any problem using the same model (atom
|
||||
style, force field, cutoff, etc) can then be estimated.</p>
|
||||
<p>Performance on a parallel machine can also be predicted from one-core
|
||||
or one-node timings if the parallel efficiency can be estimated. The
|
||||
communication bandwidth and latency of a particular parallel machine
|
||||
affects the efficiency. On most machines LAMMPS will give parallel
|
||||
efficiencies on these benchmarks above 50% so long as the number of
|
||||
atoms/core is a few 100 or greater, and closer to 100% for large
|
||||
numbers of atoms/core. This is for all-MPI mode with one MPI task per
|
||||
core. For nodes with accelerator options or hardware (OpenMP, GPU,
|
||||
Phi), you should first measure single node performance. Then you can
|
||||
estimate parallel performance for multi-node runs using the same logic
|
||||
as for all-MPI mode, except that now you will typically need many more
|
||||
atoms/node to achieve good scalability.</p>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_tools.html" class="btn btn-neutral float-right" title="9. Additional tools" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Section_example.html" class="btn btn-neutral" title="7. Example problems" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,86 +0,0 @@
|
||||
"Previous Section"_Section_example.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_tools.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
8. Performance & scalability :h3
|
||||
|
||||
Current LAMMPS performance is discussed on the Benchmarks page of the
|
||||
"LAMMPS WWW Site"_lws where CPU timings and parallel efficiencies are
|
||||
listed. The page has several sections, which are briefly described
|
||||
below:
|
||||
|
||||
CPU performance on 5 standard problems, strong and weak scaling
|
||||
GPU and Xeon Phi performance on same and related problems
|
||||
Comparison of cost of interatomic potentials
|
||||
Performance of huge, billion-atom problems :ul
|
||||
|
||||
The 5 standard problems are as follow:
|
||||
|
||||
LJ = atomic fluid, Lennard-Jones potential with 2.5 sigma cutoff (55
|
||||
neighbors per atom), NVE integration :olb,l
|
||||
|
||||
Chain = bead-spring polymer melt of 100-mer chains, FENE bonds and LJ
|
||||
pairwise interactions with a 2^(1/6) sigma cutoff (5 neighbors per
|
||||
atom), NVE integration :l
|
||||
|
||||
EAM = metallic solid, Cu EAM potential with 4.95 Angstrom cutoff (45
|
||||
neighbors per atom), NVE integration :l
|
||||
|
||||
Chute = granular chute flow, frictional history potential with 1.1
|
||||
sigma cutoff (7 neighbors per atom), NVE integration :l
|
||||
|
||||
Rhodo = rhodopsin protein in solvated lipid bilayer, CHARMM force
|
||||
field with a 10 Angstrom LJ cutoff (440 neighbors per atom),
|
||||
particle-particle particle-mesh (PPPM) for long-range Coulombics, NPT
|
||||
integration :ole,l
|
||||
|
||||
Input files for these 5 problems are provided in the bench directory
|
||||
of the LAMMPS distribution. Each has 32,000 atoms and runs for 100
|
||||
timesteps. The size of the problem (number of atoms) can be varied
|
||||
using command-line switches as described in the bench/README file.
|
||||
This is an easy way to test performance and either strong or weak
|
||||
scalability on your machine.
|
||||
|
||||
The bench directory includes a few log.* files that show performance
|
||||
of these 5 problems on 1 or 4 cores of Linux desktop. The bench/FERMI
|
||||
and bench/KEPLER dirs have input files and scripts and instructions
|
||||
for running the same (or similar) problems using OpenMP or GPU or Xeon
|
||||
Phi acceleration options. See the README files in those dirs and the
|
||||
"Section accelerate"_Section_accelerate.html doc pages for
|
||||
instructions on how to build LAMMPS and run on that kind of hardware.
|
||||
|
||||
The bench/POTENTIALS directory has input files which correspond to the
|
||||
table of results on the
|
||||
"Potentials"_http://lammps.sandia.gov/bench.html#potentials section of
|
||||
the Benchmarks web page. So you can also run those test problems on
|
||||
your machine.
|
||||
|
||||
The "billion-atom"_http://lammps.sandia.gov/bench.html#billion section
|
||||
of the Benchmarks web page has performance data for very large
|
||||
benchmark runs of simple Lennard-Jones (LJ) models, which use the
|
||||
bench/in.lj input script.
|
||||
|
||||
:line
|
||||
|
||||
For all the benchmarks, a useful metric is the CPU cost per atom per
|
||||
timestep. Since performance scales roughly linearly with problem size
|
||||
and timesteps for all LAMMPS models (i.e. inteatomic or coarse-grained
|
||||
potentials), the run time of any problem using the same model (atom
|
||||
style, force field, cutoff, etc) can then be estimated.
|
||||
|
||||
Performance on a parallel machine can also be predicted from one-core
|
||||
or one-node timings if the parallel efficiency can be estimated. The
|
||||
communication bandwidth and latency of a particular parallel machine
|
||||
affects the efficiency. On most machines LAMMPS will give parallel
|
||||
efficiencies on these benchmarks above 50% so long as the number of
|
||||
atoms/core is a few 100 or greater, and closer to 100% for large
|
||||
numbers of atoms/core. This is for all-MPI mode with one MPI task per
|
||||
core. For nodes with accelerator options or hardware (OpenMP, GPU,
|
||||
Phi), you should first measure single node performance. Then you can
|
||||
estimate parallel performance for multi-node runs using the same logic
|
||||
as for all-MPI mode, except that now you will typically need many more
|
||||
atoms/node to achieve good scalability.
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,839 +0,0 @@
|
||||
"Previous Section"_Section_modify.html - "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc - "Next Section"_Section_errors.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
11. Python interface to LAMMPS :h3
|
||||
|
||||
LAMMPS can work together with Python in two ways. First, Python can
|
||||
wrap LAMMPS through the "LAMMPS library
|
||||
interface"_Section_howto.html#howto_19, so that a Python script can
|
||||
create one or more instances of LAMMPS and launch one or more
|
||||
simulations. In Python lingo, this is "extending" Python with LAMMPS.
|
||||
|
||||
Second, LAMMPS can use the Python interpreter, so that a LAMMPS input
|
||||
script can invoke Python code, and pass information back-and-forth
|
||||
between the input script and Python functions you write. The Python
|
||||
code can also callback to LAMMPS to query or change its attributes.
|
||||
In Python lingo, this is "embedding" Python in LAMMPS.
|
||||
|
||||
This section describes how to do both.
|
||||
|
||||
11.1 "Overview of running LAMMPS from Python"_#py_1
|
||||
11.2 "Overview of using Python from a LAMMPS script"_#py_2
|
||||
11.3 "Building LAMMPS as a shared library"_#py_3
|
||||
11.4 "Installing the Python wrapper into Python"_#py_4
|
||||
11.5 "Extending Python with MPI to run in parallel"_#py_5
|
||||
11.6 "Testing the Python-LAMMPS interface"_#py_6
|
||||
11.7 "Using LAMMPS from Python"_#py_7
|
||||
11.8 "Example Python scripts that use LAMMPS"_#py_8 :ul
|
||||
|
||||
If you are not familiar with it, "Python"_http://www.python.org is a
|
||||
powerful scripting and programming language which can essentially do
|
||||
anything that faster, lower-level languages like C or C++ can do, but
|
||||
typically with much fewer lines of code. When used in embedded mode,
|
||||
Python can perform operations that the simplistic LAMMPS input script
|
||||
syntax cannot. Python can be also be used as a "glue" language to
|
||||
drive a program through its library interface, or to hook multiple
|
||||
pieces of software together, such as a simulation package plus a
|
||||
visualization package, or to run a coupled multiscale or multiphysics
|
||||
model.
|
||||
|
||||
See "Section_howto 10"_Section_howto.html#howto_10 of the manual and
|
||||
the couple directory of the distribution for more ideas about coupling
|
||||
LAMMPS to other codes. See "Section_howto
|
||||
19"_Section_howto.html#howto_19 for a description of the LAMMPS
|
||||
library interface provided in src/library.cpp and src/library.h, and
|
||||
how to extend it for your needs. As described below, that interface
|
||||
is what is exposed to Python either when calling LAMMPS from Python or
|
||||
when calling Python from a LAMMPS input script and then calling back
|
||||
to LAMMPS from Python code. The library interface is designed to be
|
||||
easy to add functions to. Thus the Python interface to LAMMPS is also
|
||||
easy to extend as well.
|
||||
|
||||
If you create interesting Python scripts that run LAMMPS or
|
||||
interesting Python functions that can be called from a LAMMPS input
|
||||
script, that you think would be useful to other users, please "email
|
||||
them to the developers"_http://lammps.sandia.gov/authors.html. We can
|
||||
include them in the LAMMPS distribution.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
11.1 Overview of running LAMMPS from Python :link(py_1),h4
|
||||
|
||||
The LAMMPS distribution includes a python directory with all you need
|
||||
to run LAMMPS from Python. The python/lammps.py file wraps the LAMMPS
|
||||
library interface, with one wrapper function per LAMMPS library
|
||||
function. This file makes it is possible to do the following either
|
||||
from a Python script, or interactively from a Python prompt: create
|
||||
one or more instances of LAMMPS, invoke LAMMPS commands or give it an
|
||||
input script, run LAMMPS incrementally, extract LAMMPS results, an
|
||||
modify internal LAMMPS variables. From a Python script you can do
|
||||
this in serial or parallel. Running Python interactively in parallel
|
||||
does not generally work, unless you have a version of Python that
|
||||
extends standard Python to enable multiple instances of Python to read
|
||||
what you type.
|
||||
|
||||
To do all of this, you must first build LAMMPS as a shared library,
|
||||
then insure that your Python can find the python/lammps.py file and
|
||||
the shared library. These steps are explained in subsequent sections
|
||||
11.3 and 11.4. Sections 11.5 and 11.6 discuss using MPI from a
|
||||
parallel Python program and how to test that you are ready to use
|
||||
LAMMPS from Python. Section 11.7 lists all the functions in the
|
||||
current LAMMPS library interface and how to call them from Python.
|
||||
|
||||
Section 11.8 gives some examples of coupling LAMMPS to other tools via
|
||||
Python. For example, LAMMPS can easily be coupled to a GUI or other
|
||||
visualization tools that display graphs or animations in real time as
|
||||
LAMMPS runs. Examples of such scripts are inlcluded in the python
|
||||
directory.
|
||||
|
||||
Two advantages of using Python to run LAMMPS are how concise the
|
||||
language is, and that it can be run interactively, enabling rapid
|
||||
development and debugging of programs. If you use it to mostly invoke
|
||||
costly operations within LAMMPS, such as running a simulation for a
|
||||
reasonable number of timesteps, then the overhead cost of invoking
|
||||
LAMMPS thru Python will be negligible.
|
||||
|
||||
The Python wrapper for LAMMPS uses the amazing and magical (to me)
|
||||
"ctypes" package in Python, which auto-generates the interface code
|
||||
needed between Python and a set of C interface routines for a library.
|
||||
Ctypes is part of standard Python for versions 2.5 and later. You can
|
||||
check which version of Python you have installed, by simply typing
|
||||
"python" at a shell prompt.
|
||||
|
||||
:line
|
||||
|
||||
11.2 Overview of using Python from a LAMMPS script :link(py_2),h4
|
||||
|
||||
NOTE: It is not currently possible to use the "python"_python.html
|
||||
command described in this section with Python 3, only with Python 2.
|
||||
The C API changed from Python 2 to 3 and the LAMMPS code is not
|
||||
compatible with both.
|
||||
|
||||
LAMMPS has a "python"_python.html command which can be used in an
|
||||
input script to define and execute a Python function that you write
|
||||
the code for. The Python function can also be assigned to a LAMMPS
|
||||
python-style variable via the "variable"_variable.html command. Each
|
||||
time the variable is evaluated, either in the LAMMPS input script
|
||||
itself, or by another LAMMPS command that uses the variable, this will
|
||||
trigger the Python function to be invoked.
|
||||
|
||||
The Python code for the function can be included directly in the input
|
||||
script or in an auxiliary file. The function can have arguments which
|
||||
are mapped to LAMMPS variables (also defined in the input script) and
|
||||
it can return a value to a LAMMPS variable. This is thus a mechanism
|
||||
for your input script to pass information to a piece of Python code,
|
||||
ask Python to execute the code, and return information to your input
|
||||
script.
|
||||
|
||||
Note that a Python function can be arbitrarily complex. It can import
|
||||
other Python modules, instantiate Python classes, call other Python
|
||||
functions, etc. The Python code that you provide can contain more
|
||||
code than the single function. It can contain other functions or
|
||||
Python classes, as well as global variables or other mechanisms for
|
||||
storing state between calls from LAMMPS to the function.
|
||||
|
||||
The Python function you provide can consist of "pure" Python code that
|
||||
only performs operations provided by standard Python. However, the
|
||||
Python function can also "call back" to LAMMPS through its
|
||||
Python-wrapped library interface, in the manner described in the
|
||||
previous section 11.1. This means it can issue LAMMPS input script
|
||||
commands or query and set internal LAMMPS state. As an example, this
|
||||
can be useful in an input script to create a more complex loop with
|
||||
branching logic, than can be created using the simple looping and
|
||||
branching logic enabled by the "next"_next.html and "if"_if.html
|
||||
commands.
|
||||
|
||||
See the "python"_python.html doc page and the "variable"_variable.html
|
||||
doc page for its python-style variables for more info, including
|
||||
examples of Python code you can write for both pure Python operations
|
||||
and callbacks to LAMMPS.
|
||||
|
||||
To run pure Python code from LAMMPS, you only need to build LAMMPS
|
||||
with the PYTHON package installed:
|
||||
|
||||
make yes-python
|
||||
make machine :pre
|
||||
|
||||
Note that this will link LAMMPS with the Python library on your
|
||||
system, which typically requires several auxiliary system libraries to
|
||||
also be linked. The list of these libraries and the paths to find
|
||||
them are specified in the lib/python/Makefile.lammps file. You need
|
||||
to insure that file contains the correct information for your version
|
||||
of Python and your machine to successfully build LAMMPS. See the
|
||||
lib/python/README file for more info.
|
||||
|
||||
If you want to write Python code with callbacks to LAMMPS, then you
|
||||
must also follow the steps overviewed in the preceeding section (11.1)
|
||||
for running LAMMPS from Python. I.e. you must build LAMMPS as a
|
||||
shared library and insure that Python can find the python/lammps.py
|
||||
file and the shared library.
|
||||
|
||||
:line
|
||||
|
||||
11.3 Building LAMMPS as a shared library :link(py_3),h4
|
||||
|
||||
Instructions on how to build LAMMPS as a shared library are given in
|
||||
"Section_start 5"_Section_start.html#start_5. A shared library is one
|
||||
that is dynamically loadable, which is what Python requires to wrap
|
||||
LAMMPS. On Linux this is a library file that ends in ".so", not ".a".
|
||||
|
||||
From the src directory, type
|
||||
|
||||
make foo mode=shlib :pre
|
||||
|
||||
where foo is the machine target name, such as linux or g++ or serial.
|
||||
This should create the file liblammps_foo.so in the src directory, as
|
||||
well as a soft link liblammps.so, which is what the Python wrapper will
|
||||
load by default. Note that if you are building multiple machine
|
||||
versions of the shared library, the soft link is always set to the
|
||||
most recently built version.
|
||||
|
||||
NOTE: If you are building LAMMPS with an MPI or FFT library or other
|
||||
auxiliary libraries (used by various packages), then all of these
|
||||
extra libraries must also be shared libraries. If the LAMMPS
|
||||
shared-library build fails with an error complaining about this, see
|
||||
"Section_start 5"_Section_start.html#start_5 for more details.
|
||||
|
||||
:line
|
||||
|
||||
11.4 Installing the Python wrapper into Python :link(py_4),h4
|
||||
|
||||
For Python to invoke LAMMPS, there are 2 files it needs to know about:
|
||||
|
||||
python/lammps.py
|
||||
src/liblammps.so :ul
|
||||
|
||||
Lammps.py is the Python wrapper on the LAMMPS library interface.
|
||||
Liblammps.so is the shared LAMMPS library that Python loads, as
|
||||
described above.
|
||||
|
||||
You can insure Python can find these files in one of two ways:
|
||||
|
||||
set two environment variables
|
||||
run the python/install.py script :ul
|
||||
|
||||
If you set the paths to these files as environment variables, you only
|
||||
have to do it once. For the csh or tcsh shells, add something like
|
||||
this to your ~/.cshrc file, one line for each of the two files:
|
||||
|
||||
setenv PYTHONPATH $\{PYTHONPATH\}:/home/sjplimp/lammps/python
|
||||
setenv LD_LIBRARY_PATH $\{LD_LIBRARY_PATH\}:/home/sjplimp/lammps/src :pre
|
||||
|
||||
If you use the python/install.py script, you need to invoke it every
|
||||
time you rebuild LAMMPS (as a shared library) or make changes to the
|
||||
python/lammps.py file.
|
||||
|
||||
You can invoke install.py from the python directory as
|
||||
|
||||
% python install.py \[libdir\] \[pydir\] :pre
|
||||
|
||||
The optional libdir is where to copy the LAMMPS shared library to; the
|
||||
default is /usr/local/lib. The optional pydir is where to copy the
|
||||
lammps.py file to; the default is the site-packages directory of the
|
||||
version of Python that is running the install script.
|
||||
|
||||
Note that libdir must be a location that is in your default
|
||||
LD_LIBRARY_PATH, like /usr/local/lib or /usr/lib. And pydir must be a
|
||||
location that Python looks in by default for imported modules, like
|
||||
its site-packages dir. If you want to copy these files to
|
||||
non-standard locations, such as within your own user space, you will
|
||||
need to set your PYTHONPATH and LD_LIBRARY_PATH environment variables
|
||||
accordingly, as above.
|
||||
|
||||
If the install.py script does not allow you to copy files into system
|
||||
directories, prefix the python command with "sudo". If you do this,
|
||||
make sure that the Python that root runs is the same as the Python you
|
||||
run. E.g. you may need to do something like
|
||||
|
||||
% sudo /usr/local/bin/python install.py \[libdir\] \[pydir\] :pre
|
||||
|
||||
You can also invoke install.py from the make command in the src
|
||||
directory as
|
||||
|
||||
% make install-python :pre
|
||||
|
||||
In this mode you cannot append optional arguments. Again, you may
|
||||
need to prefix this with "sudo". In this mode you cannot control
|
||||
which Python is invoked by root.
|
||||
|
||||
Note that if you want Python to be able to load different versions of
|
||||
the LAMMPS shared library (see "this section"_#py_5 below), you will
|
||||
need to manually copy files like liblammps_g++.so into the appropriate
|
||||
system directory. This is not needed if you set the LD_LIBRARY_PATH
|
||||
environment variable as described above.
|
||||
|
||||
:line
|
||||
|
||||
11.5 Extending Python with MPI to run in parallel :link(py_5),h4
|
||||
|
||||
If you wish to run LAMMPS in parallel from Python, you need to extend
|
||||
your Python with an interface to MPI. This also allows you to
|
||||
make MPI calls directly from Python in your script, if you desire.
|
||||
|
||||
There are several Python packages available that purport to wrap MPI
|
||||
as a library and allow MPI functions to be called from Python.
|
||||
|
||||
These include
|
||||
|
||||
"pyMPI"_http://pympi.sourceforge.net/
|
||||
"maroonmpi"_http://code.google.com/p/maroonmpi/
|
||||
"mpi4py"_http://code.google.com/p/mpi4py/
|
||||
"myMPI"_http://nbcr.sdsc.edu/forum/viewtopic.php?t=89&sid=c997fefc3933bd66204875b436940f16
|
||||
"Pypar"_http://code.google.com/p/pypar :ul
|
||||
|
||||
All of these except pyMPI work by wrapping the MPI library and
|
||||
exposing (some portion of) its interface to your Python script. This
|
||||
means Python cannot be used interactively in parallel, since they do
|
||||
not address the issue of interactive input to multiple instances of
|
||||
Python running on different processors. The one exception is pyMPI,
|
||||
which alters the Python interpreter to address this issue, and (I
|
||||
believe) creates a new alternate executable (in place of "python"
|
||||
itself) as a result.
|
||||
|
||||
In principle any of these Python/MPI packages should work to invoke
|
||||
LAMMPS in parallel and to make MPI calls themselves from a Python
|
||||
script which is itself running in parallel. However, when I
|
||||
downloaded and looked at a few of them, their documentation was
|
||||
incomplete and I had trouble with their installation. It's not clear
|
||||
if some of the packages are still being actively developed and
|
||||
supported.
|
||||
|
||||
The packages Pypar and mpi4py have both been successfully tested with
|
||||
LAMMPS. Pypar is simpler and easy to set up and use, but supports
|
||||
only a subset of MPI. Mpi4py is more MPI-feature complete, but also a
|
||||
bit more complex to use. As of version 2.0.0, mpi4py is the only
|
||||
python MPI wrapper that allows passing a custom MPI communicator to
|
||||
the LAMMPS constructor, which means one can easily run one or more
|
||||
LAMMPS instances on subsets of the total MPI ranks.
|
||||
|
||||
:line
|
||||
|
||||
Pypar requires the ubiquitous "Numpy package"_http://numpy.scipy.org
|
||||
be installed in your Python. After launching Python, type
|
||||
|
||||
import numpy :pre
|
||||
|
||||
to see if it is installed. If not, here is how to install it (version
|
||||
1.3.0b1 as of April 2009). Unpack the numpy tarball and from its
|
||||
top-level directory, type
|
||||
|
||||
python setup.py build
|
||||
sudo python setup.py install :pre
|
||||
|
||||
The "sudo" is only needed if required to copy Numpy files into your
|
||||
Python distribution's site-packages directory.
|
||||
|
||||
To install Pypar (version pypar-2.1.4_94 as of Aug 2012), unpack it
|
||||
and from its "source" directory, type
|
||||
|
||||
python setup.py build
|
||||
sudo python setup.py install :pre
|
||||
|
||||
Again, the "sudo" is only needed if required to copy Pypar files into
|
||||
your Python distribution's site-packages directory.
|
||||
|
||||
If you have successully installed Pypar, you should be able to run
|
||||
Python and type
|
||||
|
||||
import pypar :pre
|
||||
|
||||
without error. You should also be able to run python in parallel
|
||||
on a simple test script
|
||||
|
||||
% mpirun -np 4 python test.py :pre
|
||||
|
||||
where test.py contains the lines
|
||||
|
||||
import pypar
|
||||
print "Proc %d out of %d procs" % (pypar.rank(),pypar.size()) :pre
|
||||
|
||||
and see one line of output for each processor you run on.
|
||||
|
||||
NOTE: To use Pypar and LAMMPS in parallel from Python, you must insure
|
||||
both are using the same version of MPI. If you only have one MPI
|
||||
installed on your system, this is not an issue, but it can be if you
|
||||
have multiple MPIs. Your LAMMPS build is explicit about which MPI it
|
||||
is using, since you specify the details in your lo-level
|
||||
src/MAKE/Makefile.foo file. Pypar uses the "mpicc" command to find
|
||||
information about the MPI it uses to build against. And it tries to
|
||||
load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
|
||||
the MPI library that LAMMPS is using. If you have problems running
|
||||
both Pypar and LAMMPS together, this is an issue you may need to
|
||||
address, e.g. by moving other MPI installations so that Pypar finds
|
||||
the right one.
|
||||
|
||||
:line
|
||||
|
||||
To install mpi4py (version mpi4py-2.0.0 as of Oct 2015), unpack it
|
||||
and from its main directory, type
|
||||
|
||||
python setup.py build
|
||||
sudo python setup.py install :pre
|
||||
|
||||
Again, the "sudo" is only needed if required to copy mpi4py files into
|
||||
your Python distribution's site-packages directory. To install with
|
||||
user privilege into the user local directory type
|
||||
|
||||
python setup.py install --user :pre
|
||||
|
||||
If you have successully installed mpi4py, you should be able to run
|
||||
Python and type
|
||||
|
||||
from mpi4py import MPI :pre
|
||||
|
||||
without error. You should also be able to run python in parallel
|
||||
on a simple test script
|
||||
|
||||
% mpirun -np 4 python test.py :pre
|
||||
|
||||
where test.py contains the lines
|
||||
|
||||
from mpi4py import MPI
|
||||
comm = MPI.COMM_WORLD
|
||||
print "Proc %d out of %d procs" % (comm.Get_rank(),comm.Get_size()) :pre
|
||||
|
||||
and see one line of output for each processor you run on.
|
||||
|
||||
NOTE: To use mpi4py and LAMMPS in parallel from Python, you must
|
||||
insure both are using the same version of MPI. If you only have one
|
||||
MPI installed on your system, this is not an issue, but it can be if
|
||||
you have multiple MPIs. Your LAMMPS build is explicit about which MPI
|
||||
it is using, since you specify the details in your lo-level
|
||||
src/MAKE/Makefile.foo file. Mpi4py uses the "mpicc" command to find
|
||||
information about the MPI it uses to build against. And it tries to
|
||||
load "libmpi.so" from the LD_LIBRARY_PATH. This may or may not find
|
||||
the MPI library that LAMMPS is using. If you have problems running
|
||||
both mpi4py and LAMMPS together, this is an issue you may need to
|
||||
address, e.g. by moving other MPI installations so that mpi4py finds
|
||||
the right one.
|
||||
|
||||
:line
|
||||
|
||||
11.6 Testing the Python-LAMMPS interface :link(py_6),h4
|
||||
|
||||
To test if LAMMPS is callable from Python, launch Python interactively
|
||||
and type:
|
||||
|
||||
>>> from lammps import lammps
|
||||
>>> lmp = lammps() :pre
|
||||
|
||||
If you get no errors, you're ready to use LAMMPS from Python. If the
|
||||
2nd command fails, the most common error to see is
|
||||
|
||||
OSError: Could not load LAMMPS dynamic library :pre
|
||||
|
||||
which means Python was unable to load the LAMMPS shared library. This
|
||||
typically occurs if the system can't find the LAMMPS shared library or
|
||||
one of the auxiliary shared libraries it depends on, or if something
|
||||
about the library is incompatible with your Python. The error message
|
||||
should give you an indication of what went wrong.
|
||||
|
||||
You can also test the load directly in Python as follows, without
|
||||
first importing from the lammps.py file:
|
||||
|
||||
>>> from ctypes import CDLL
|
||||
>>> CDLL("liblammps.so") :pre
|
||||
|
||||
If an error occurs, carefully go thru the steps in "Section_start
|
||||
5"_Section_start.html#start_5 and above about building a shared
|
||||
library and about insuring Python can find the necessary two files
|
||||
it needs.
|
||||
|
||||
[Test LAMMPS and Python in serial:] :h5
|
||||
|
||||
To run a LAMMPS test in serial, type these lines into Python
|
||||
interactively from the bench directory:
|
||||
|
||||
>>> from lammps import lammps
|
||||
>>> lmp = lammps()
|
||||
>>> lmp.file("in.lj") :pre
|
||||
|
||||
Or put the same lines in the file test.py and run it as
|
||||
|
||||
% python test.py :pre
|
||||
|
||||
Either way, you should see the results of running the in.lj benchmark
|
||||
on a single processor appear on the screen, the same as if you had
|
||||
typed something like:
|
||||
|
||||
lmp_g++ -in in.lj :pre
|
||||
|
||||
[Test LAMMPS and Python in parallel:] :h5
|
||||
|
||||
To run LAMMPS in parallel, assuming you have installed the
|
||||
"Pypar"_Pypar package as discussed above, create a test.py file
|
||||
containing these lines:
|
||||
|
||||
import pypar
|
||||
from lammps import lammps
|
||||
lmp = lammps()
|
||||
lmp.file("in.lj")
|
||||
print "Proc %d out of %d procs has" % (pypar.rank(),pypar.size()),lmp
|
||||
pypar.finalize() :pre
|
||||
|
||||
To run LAMMPS in parallel, assuming you have installed the
|
||||
"mpi4py"_mpi4py package as discussed above, create a test.py file
|
||||
containing these lines:
|
||||
|
||||
from mpi4py import MPI
|
||||
from lammps import lammps
|
||||
lmp = lammps()
|
||||
lmp.file("in.lj")
|
||||
me = MPI.COMM_WORLD.Get_rank()
|
||||
nprocs = MPI.COMM_WORLD.Get_size()
|
||||
print "Proc %d out of %d procs has" % (me,nprocs),lmp
|
||||
MPI.Finalize() :pre
|
||||
|
||||
You can either script in parallel as:
|
||||
|
||||
% mpirun -np 4 python test.py :pre
|
||||
|
||||
and you should see the same output as if you had typed
|
||||
|
||||
% mpirun -np 4 lmp_g++ -in in.lj :pre
|
||||
|
||||
Note that if you leave out the 3 lines from test.py that specify Pypar
|
||||
commands you will instantiate and run LAMMPS independently on each of
|
||||
the P processors specified in the mpirun command. In this case you
|
||||
should get 4 sets of output, each showing that a LAMMPS run was made
|
||||
on a single processor, instead of one set of output showing that
|
||||
LAMMPS ran on 4 processors. If the 1-processor outputs occur, it
|
||||
means that Pypar is not working correctly.
|
||||
|
||||
Also note that once you import the PyPar module, Pypar initializes MPI
|
||||
for you, and you can use MPI calls directly in your Python script, as
|
||||
described in the Pypar documentation. The last line of your Python
|
||||
script should be pypar.finalize(), to insure MPI is shut down
|
||||
correctly.
|
||||
|
||||
[Running Python scripts:] :h5
|
||||
|
||||
Note that any Python script (not just for LAMMPS) can be invoked in
|
||||
one of several ways:
|
||||
|
||||
% python foo.script
|
||||
% python -i foo.script
|
||||
% foo.script :pre
|
||||
|
||||
The last command requires that the first line of the script be
|
||||
something like this:
|
||||
|
||||
#!/usr/local/bin/python
|
||||
#!/usr/local/bin/python -i :pre
|
||||
|
||||
where the path points to where you have Python installed, and that you
|
||||
have made the script file executable:
|
||||
|
||||
% chmod +x foo.script :pre
|
||||
|
||||
Without the "-i" flag, Python will exit when the script finishes.
|
||||
With the "-i" flag, you will be left in the Python interpreter when
|
||||
the script finishes, so you can type subsequent commands. As
|
||||
mentioned above, you can only run Python interactively when running
|
||||
Python on a single processor, not in parallel.
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
11.7 Using LAMMPS from Python :link(py_7),h4
|
||||
|
||||
As described above, the Python interface to LAMMPS consists of a
|
||||
Python "lammps" module, the source code for which is in
|
||||
python/lammps.py, which creates a "lammps" object, with a set of
|
||||
methods that can be invoked on that object. The sample Python code
|
||||
below assumes you have first imported the "lammps" module in your
|
||||
Python script, as follows:
|
||||
|
||||
from lammps import lammps :pre
|
||||
|
||||
These are the methods defined by the lammps module. If you look at
|
||||
the files src/library.cpp and src/library.h you will see that they
|
||||
correspond one-to-one with calls you can make to the LAMMPS library
|
||||
from a C++ or C or Fortran program.
|
||||
|
||||
lmp = lammps() # create a LAMMPS object using the default liblammps.so library
|
||||
4 optional args are allowed: name, cmdargs, ptr, comm
|
||||
lmp = lammps(ptr=lmpptr) # use lmpptr as previously created LAMMPS object
|
||||
lmp = lammps(comm=split) # create a LAMMPS object with a custom communicator, requires mpi4py 2.0.0 or later
|
||||
lmp = lammps(name="g++") # create a LAMMPS object using the liblammps_g++.so library
|
||||
lmp = lammps(name="g++",cmdargs=list) # add LAMMPS command-line args, e.g. list = \["-echo","screen"\] :pre
|
||||
|
||||
lmp.close() # destroy a LAMMPS object :pre
|
||||
|
||||
version = lmp.version() # return the numerical version id, e.g. LAMMPS 2 Sep 2015 -> 20150902
|
||||
|
||||
lmp.file(file) # run an entire input script, file = "in.lj"
|
||||
lmp.command(cmd) # invoke a single LAMMPS command, cmd = "run 100" :pre
|
||||
|
||||
xlo = lmp.extract_global(name,type) # extract a global quantity
|
||||
# name = "boxxlo", "nlocal", etc
|
||||
# type = 0 = int
|
||||
# 1 = double :pre
|
||||
|
||||
coords = lmp.extract_atom(name,type) # extract a per-atom quantity
|
||||
# name = "x", "type", etc
|
||||
# type = 0 = vector of ints
|
||||
# 1 = array of ints
|
||||
# 2 = vector of doubles
|
||||
# 3 = array of doubles :pre
|
||||
|
||||
eng = lmp.extract_compute(id,style,type) # extract value(s) from a compute
|
||||
v3 = lmp.extract_fix(id,style,type,i,j) # extract value(s) from a fix
|
||||
# id = ID of compute or fix
|
||||
# style = 0 = global data
|
||||
# 1 = per-atom data
|
||||
# 2 = local data
|
||||
# type = 0 = scalar
|
||||
# 1 = vector
|
||||
# 2 = array
|
||||
# i,j = indices of value in global vector or array :pre
|
||||
|
||||
var = lmp.extract_variable(name,group,flag) # extract value(s) from a variable
|
||||
# name = name of variable
|
||||
# group = group ID (ignored for equal-style variables)
|
||||
# flag = 0 = equal-style variable
|
||||
# 1 = atom-style variable :pre
|
||||
|
||||
flag = lmp.set_variable(name,value) # set existing named string-style variable to value, flag = 0 if successful
|
||||
natoms = lmp.get_natoms() # total # of atoms as int
|
||||
data = lmp.gather_atoms(name,type,count) # return atom attribute of all atoms gathered into data, ordered by atom ID
|
||||
# name = "x", "charge", "type", etc
|
||||
# count = # of per-atom values, 1 or 3, etc
|
||||
lmp.scatter_atoms(name,type,count,data) # scatter atom attribute of all atoms from data, ordered by atom ID
|
||||
# name = "x", "charge", "type", etc
|
||||
# count = # of per-atom values, 1 or 3, etc :pre
|
||||
|
||||
:line
|
||||
|
||||
The lines
|
||||
|
||||
from lammps import lammps
|
||||
lmp = lammps() :pre
|
||||
|
||||
create an instance of LAMMPS, wrapped in a Python class by the lammps
|
||||
Python module, and return an instance of the Python class as lmp. It
|
||||
is used to make all subequent calls to the LAMMPS library.
|
||||
|
||||
Additional arguments can be used to tell Python the name of the shared
|
||||
library to load or to pass arguments to the LAMMPS instance, the same
|
||||
as if LAMMPS were launched from a command-line prompt.
|
||||
|
||||
If the ptr argument is set like this:
|
||||
|
||||
lmp = lammps(ptr=lmpptr) :pre
|
||||
|
||||
then lmpptr must be an argument passed to Python via the LAMMPS
|
||||
"python"_python.html command, when it is used to define a Python
|
||||
function that is invoked by the LAMMPS input script. This mode of
|
||||
using Python with LAMMPS is described above in 11.2. The variable
|
||||
lmpptr refers to the instance of LAMMPS that called the embedded
|
||||
Python interpreter. Using it as an argument to lammps() allows the
|
||||
returned Python class instance "lmp" to make calls to that instance of
|
||||
LAMMPS. See the "python"_python.html command doc page for examples
|
||||
using this syntax.
|
||||
|
||||
Note that you can create multiple LAMMPS objects in your Python
|
||||
script, and coordinate and run multiple simulations, e.g.
|
||||
|
||||
from lammps import lammps
|
||||
lmp1 = lammps()
|
||||
lmp2 = lammps()
|
||||
lmp1.file("in.file1")
|
||||
lmp2.file("in.file2") :pre
|
||||
|
||||
The file() and command() methods allow an input script or single
|
||||
commands to be invoked.
|
||||
|
||||
The extract_global(), extract_atom(), extract_compute(),
|
||||
extract_fix(), and extract_variable() methods return values or
|
||||
pointers to data structures internal to LAMMPS.
|
||||
|
||||
For extract_global() see the src/library.cpp file for the list of
|
||||
valid names. New names could easily be added. A double or integer is
|
||||
returned. You need to specify the appropriate data type via the type
|
||||
argument.
|
||||
|
||||
For extract_atom(), a pointer to internal LAMMPS atom-based data is
|
||||
returned, which you can use via normal Python subscripting. See the
|
||||
extract() method in the src/atom.cpp file for a list of valid names.
|
||||
Again, new names could easily be added. A pointer to a vector of
|
||||
doubles or integers, or a pointer to an array of doubles (double **)
|
||||
or integers (int **) is returned. You need to specify the appropriate
|
||||
data type via the type argument.
|
||||
|
||||
For extract_compute() and extract_fix(), the global, per-atom, or
|
||||
local data calulated by the compute or fix can be accessed. What is
|
||||
returned depends on whether the compute or fix calculates a scalar or
|
||||
vector or array. For a scalar, a single double value is returned. If
|
||||
the compute or fix calculates a vector or array, a pointer to the
|
||||
internal LAMMPS data is returned, which you can use via normal Python
|
||||
subscripting. The one exception is that for a fix that calculates a
|
||||
global vector or array, a single double value from the vector or array
|
||||
is returned, indexed by I (vector) or I and J (array). I,J are
|
||||
zero-based indices. The I,J arguments can be left out if not needed.
|
||||
See "Section_howto 15"_Section_howto.html#howto_15 of the manual for a
|
||||
discussion of global, per-atom, and local data, and of scalar, vector,
|
||||
and array data types. See the doc pages for individual
|
||||
"computes"_compute.html and "fixes"_fix.html for a description of what
|
||||
they calculate and store.
|
||||
|
||||
For extract_variable(), an "equal-style or atom-style
|
||||
variable"_variable.html is evaluated and its result returned.
|
||||
|
||||
For equal-style variables a single double value is returned and the
|
||||
group argument is ignored. For atom-style variables, a vector of
|
||||
doubles is returned, one value per atom, which you can use via normal
|
||||
Python subscripting. The values will be zero for atoms not in the
|
||||
specified group.
|
||||
|
||||
The get_natoms() method returns the total number of atoms in the
|
||||
simulation, as an int.
|
||||
|
||||
The gather_atoms() method returns a ctypes vector of ints or doubles
|
||||
as specified by type, of length count*natoms, for the property of all
|
||||
the atoms in the simulation specified by name, ordered by count and
|
||||
then by atom ID. The vector can be used via normal Python
|
||||
subscripting. If atom IDs are not consecutively ordered within
|
||||
LAMMPS, a None is returned as indication of an error.
|
||||
|
||||
Note that the data structure gather_atoms("x") returns is different
|
||||
from the data structure returned by extract_atom("x") in four ways.
|
||||
(1) Gather_atoms() returns a vector which you index as x\[i\];
|
||||
extract_atom() returns an array which you index as x\[i\]\[j\]. (2)
|
||||
Gather_atoms() orders the atoms by atom ID while extract_atom() does
|
||||
not. (3) Gathert_atoms() returns a list of all atoms in the
|
||||
simulation; extract_atoms() returns just the atoms local to each
|
||||
processor. (4) Finally, the gather_atoms() data structure is a copy
|
||||
of the atom coords stored internally in LAMMPS, whereas extract_atom()
|
||||
returns an array that effectively points directly to the internal
|
||||
data. This means you can change values inside LAMMPS from Python by
|
||||
assigning a new values to the extract_atom() array. To do this with
|
||||
the gather_atoms() vector, you need to change values in the vector,
|
||||
then invoke the scatter_atoms() method.
|
||||
|
||||
The scatter_atoms() method takes a vector of ints or doubles as
|
||||
specified by type, of length count*natoms, for the property of all the
|
||||
atoms in the simulation specified by name, ordered by bount and then
|
||||
by atom ID. It uses the vector of data to overwrite the corresponding
|
||||
properties for each atom inside LAMMPS. This requires LAMMPS to have
|
||||
its "map" option enabled; see the "atom_modify"_atom_modify.html
|
||||
command for details. If it is not, or if atom IDs are not
|
||||
consecutively ordered, no coordinates are reset.
|
||||
|
||||
The array of coordinates passed to scatter_atoms() must be a ctypes
|
||||
vector of ints or doubles, allocated and initialized something like
|
||||
this:
|
||||
|
||||
from ctypes import *
|
||||
natoms = lmp.get_natoms()
|
||||
n3 = 3*natoms
|
||||
x = (n3*c_double)()
|
||||
x\[0\] = x coord of atom with ID 1
|
||||
x\[1\] = y coord of atom with ID 1
|
||||
x\[2\] = z coord of atom with ID 1
|
||||
x\[3\] = x coord of atom with ID 2
|
||||
...
|
||||
x\[n3-1\] = z coord of atom with ID natoms
|
||||
lmp.scatter_coords("x",1,3,x) :pre
|
||||
|
||||
Alternatively, you can just change values in the vector returned by
|
||||
gather_atoms("x",1,3), since it is a ctypes vector of doubles.
|
||||
|
||||
:line
|
||||
|
||||
As noted above, these Python class methods correspond one-to-one with
|
||||
the functions in the LAMMPS library interface in src/library.cpp and
|
||||
library.h. This means you can extend the Python wrapper via the
|
||||
following steps:
|
||||
|
||||
Add a new interface function to src/library.cpp and
|
||||
src/library.h. :ulb,l
|
||||
|
||||
Rebuild LAMMPS as a shared library. :l
|
||||
|
||||
Add a wrapper method to python/lammps.py for this interface
|
||||
function. :l
|
||||
|
||||
You should now be able to invoke the new interface function from a
|
||||
Python script. Isn't ctypes amazing? :l,ule
|
||||
|
||||
:line
|
||||
:line
|
||||
|
||||
11.8 Example Python scripts that use LAMMPS :link(py_8),h4
|
||||
|
||||
These are the Python scripts included as demos in the python/examples
|
||||
directory of the LAMMPS distribution, to illustrate the kinds of
|
||||
things that are possible when Python wraps LAMMPS. If you create your
|
||||
own scripts, send them to us and we can include them in the LAMMPS
|
||||
distribution.
|
||||
|
||||
trivial.py, read/run a LAMMPS input script thru Python,
|
||||
demo.py, invoke various LAMMPS library interface routines,
|
||||
simple.py, run in parallel, similar to examples/COUPLE/simple/simple.cpp,
|
||||
split.py, same as simple.py but running in parallel on a subset of procs,
|
||||
gui.py, GUI go/stop/temperature-slider to control LAMMPS,
|
||||
plot.py, real-time temeperature plot with GnuPlot via Pizza.py,
|
||||
viz_tool.py, real-time viz via some viz package,
|
||||
vizplotgui_tool.py, combination of viz_tool.py and plot.py and gui.py :tb(c=2)
|
||||
|
||||
:line
|
||||
|
||||
For the viz_tool.py and vizplotgui_tool.py commands, replace "tool"
|
||||
with "gl" or "atomeye" or "pymol" or "vmd", depending on what
|
||||
visualization package you have installed.
|
||||
|
||||
Note that for GL, you need to be able to run the Pizza.py GL tool,
|
||||
which is included in the pizza sub-directory. See the "Pizza.py doc
|
||||
pages"_pizza for more info:
|
||||
|
||||
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
|
||||
|
||||
Note that for AtomEye, you need version 3, and there is a line in the
|
||||
scripts that specifies the path and name of the executable. See the
|
||||
AtomEye WWW pages "here"_atomeye or "here"_atomeye3 for more details:
|
||||
|
||||
http://mt.seas.upenn.edu/Archive/Graphics/A
|
||||
http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html :pre
|
||||
|
||||
:link(atomeye,http://mt.seas.upenn.edu/Archive/Graphics/A)
|
||||
:link(atomeye3,http://mt.seas.upenn.edu/Archive/Graphics/A3/A3.html)
|
||||
|
||||
The latter link is to AtomEye 3 which has the scriping
|
||||
capability needed by these Python scripts.
|
||||
|
||||
Note that for PyMol, you need to have built and installed the
|
||||
open-source version of PyMol in your Python, so that you can import it
|
||||
from a Python script. See the PyMol WWW pages "here"_pymol or
|
||||
"here"_pymolopen for more details:
|
||||
|
||||
http://www.pymol.org
|
||||
http://sourceforge.net/scm/?type=svn&group_id=4546 :pre
|
||||
|
||||
:link(pymol,http://www.pymol.org)
|
||||
:link(pymolopen,http://sourceforge.net/scm/?type=svn&group_id=4546)
|
||||
|
||||
The latter link is to the open-source version.
|
||||
|
||||
Note that for VMD, you need a fairly current version (1.8.7 works for
|
||||
me) and there are some lines in the pizza/vmd.py script for 4 PIZZA
|
||||
variables that have to match the VMD installation on your system.
|
||||
|
||||
:line
|
||||
|
||||
See the python/README file for instructions on how to run them and the
|
||||
source code for individual scripts for comments about what they do.
|
||||
|
||||
Here are screenshots of the vizplotgui_tool.py script in action for
|
||||
different visualization package options. Click to see larger images:
|
||||
|
||||
:image(JPG/screenshot_gl_small.jpg,JPG/screenshot_gl.jpg)
|
||||
:image(JPG/screenshot_atomeye_small.jpg,JPG/screenshot_atomeye.jpg)
|
||||
:image(JPG/screenshot_pymol_small.jpg,JPG/screenshot_pymol.jpg)
|
||||
:image(JPG/screenshot_vmd_small.jpg,JPG/screenshot_vmd.jpg)
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1,707 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>9. Additional tools — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
<link rel="next" title="10. Modifying & extending LAMMPS" href="Section_modify.html"/>
|
||||
<link rel="prev" title="8. Performance & scalability" href="Section_perf.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">9. Additional tools</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#amber2lmp-tool">9.1. amber2lmp tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#binary2txt-tool">9.2. binary2txt tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#ch2lmp-tool">9.3. ch2lmp tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#chain-tool">9.4. chain tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#colvars-tools">9.5. colvars tools</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#createatoms-tool">9.6. createatoms tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#data2xmovie-tool">9.7. data2xmovie tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#eam-database-tool">9.8. eam database tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#eam-generate-tool">9.9. eam generate tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#eff-tool">9.10. eff tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#emacs-tool">9.11. emacs tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#fep-tool">9.12. fep tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#i-pi-tool">9.13. i-pi tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#ipp-tool">9.14. ipp tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#kate-tool">9.15. kate tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#lmp2arc-tool">9.16. lmp2arc tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#lmp2cfg-tool">9.17. lmp2cfg tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#lmp2vmd-tool">9.18. lmp2vmd tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#matlab-tool">9.19. matlab tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#micelle2d-tool">9.20. micelle2d tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#moltemplate-tool">9.21. moltemplate tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#msi2lmp-tool">9.22. msi2lmp tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#phonon-tool">9.23. phonon tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#polymer-bonding-tool">9.24. polymer bonding tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#pymol-asphere-tool">9.25. pymol_asphere tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#python-tool">9.26. python tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#reax-tool">9.27. reax tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#restart2data-tool">9.28. restart2data tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#vim-tool">9.29. vim tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#xmgrace-tool">9.30. xmgrace tool</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="#xmovie-tool">9.31. xmovie tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>9. Additional tools</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
<div class="rst-footer-buttons" style="margin-bottom: 1em" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_modify.html" class="btn btn-neutral float-right" title="10. Modifying & extending LAMMPS" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Section_perf.html" class="btn btn-neutral" title="8. Performance & scalability" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="additional-tools">
|
||||
<h1>9. Additional tools<a class="headerlink" href="#additional-tools" title="Permalink to this headline">¶</a></h1>
|
||||
<p>LAMMPS is designed to be a computational kernel for performing
|
||||
molecular dynamics computations. Additional pre- and post-processing
|
||||
steps are often necessary to setup and analyze a simulation. A few
|
||||
additional tools are provided with the LAMMPS distribution and are
|
||||
described in this section.</p>
|
||||
<p>Our group has also written and released a separate toolkit called
|
||||
<a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> which provides tools for doing setup, analysis,
|
||||
plotting, and visualization for LAMMPS simulations. Pizza.py is
|
||||
written in <a class="reference external" href="http://www.python.org">Python</a> and is available for download from <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">the Pizza.py WWW site</a>.</p>
|
||||
<p>Note that many users write their own setup or analysis tools or use
|
||||
other existing codes and convert their output to a LAMMPS input format
|
||||
or vice versa. The tools listed here are included in the LAMMPS
|
||||
distribution as examples of auxiliary tools. Some of them are not
|
||||
actively supported by Sandia, as they were contributed by LAMMPS
|
||||
users. If you have problems using them, we can direct you to the
|
||||
authors.</p>
|
||||
<p>The source code for each of these codes is in the tools sub-directory
|
||||
of the LAMMPS distribution. There is a Makefile (which you may need
|
||||
to edit for your platform) which will build several of the tools which
|
||||
reside in that directory. Some of them are larger packages in their
|
||||
own sub-directories with their own Makefiles.</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference internal" href="#amber"><span>amber2lmp</span></a></li>
|
||||
<li><a class="reference internal" href="#binary"><span>binary2txt</span></a></li>
|
||||
<li><a class="reference internal" href="#charmm"><span>ch2lmp</span></a></li>
|
||||
<li><a class="reference internal" href="#chain"><span>chain</span></a></li>
|
||||
<li><a class="reference internal" href="#colvars"><span>colvars</span></a></li>
|
||||
<li><a class="reference internal" href="#create"><span>createatoms</span></a></li>
|
||||
<li><a class="reference internal" href="#data"><span>data2xmovie</span></a></li>
|
||||
<li><a class="reference internal" href="#eamdb"><span>eam database</span></a></li>
|
||||
<li><a class="reference internal" href="#eamgn"><span>eam generate</span></a></li>
|
||||
<li><a class="reference internal" href="#eff"><span>eff</span></a></li>
|
||||
<li><a class="reference internal" href="#emacs"><span>emacs</span></a></li>
|
||||
<li><a class="reference internal" href="#fep"><span>fep</span></a></li>
|
||||
<li><a class="reference internal" href="fix_ipi.html#ipi"><span>i-pi</span></a></li>
|
||||
<li><a class="reference internal" href="#ipp"><span>ipp</span></a></li>
|
||||
<li><a class="reference internal" href="#kate"><span>kate</span></a></li>
|
||||
<li><a class="reference internal" href="#arc"><span>lmp2arc</span></a></li>
|
||||
<li><a class="reference internal" href="#cfg"><span>lmp2cfg</span></a></li>
|
||||
<li><a class="reference internal" href="#vmd"><span>lmp2vmd</span></a></li>
|
||||
<li><span class="xref std std-ref">matlab</span></li>
|
||||
<li><a class="reference internal" href="#micelle"><span>micelle2d</span></a></li>
|
||||
<li><a class="reference internal" href="#moltemplate"><span>moltemplate</span></a></li>
|
||||
<li><a class="reference internal" href="#msi"><span>msi2lmp</span></a></li>
|
||||
<li><a class="reference internal" href="#phonon"><span>phonon</span></a></li>
|
||||
<li><a class="reference internal" href="#polybond"><span>polymer bonding</span></a></li>
|
||||
<li><span class="xref std std-ref">pymol_asphere</span></li>
|
||||
<li><a class="reference internal" href="#pythontools"><span>python</span></a></li>
|
||||
<li><a class="reference internal" href="#reax"><span>reax</span></a></li>
|
||||
<li><a class="reference internal" href="#restart"><span>restart2data</span></a></li>
|
||||
<li><a class="reference internal" href="#vim"><span>vim</span></a></li>
|
||||
<li><a class="reference internal" href="#xmgrace"><span>xmgrace</span></a></li>
|
||||
<li><a class="reference internal" href="#xmovie"><span>xmovie</span></a></li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="amber2lmp-tool">
|
||||
<span id="amber"></span><h2>9.1. amber2lmp tool<a class="headerlink" href="#amber2lmp-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The amber2lmp sub-directory contains two Python scripts for converting
|
||||
files back-and-forth between the AMBER MD code and LAMMPS. See the
|
||||
README file in amber2lmp for more information.</p>
|
||||
<p>These tools were written by Keir Novik while he was at Queen Mary
|
||||
University of London. Keir is no longer there and cannot support
|
||||
these tools which are out-of-date with respect to the current LAMMPS
|
||||
version (and maybe with respect to AMBER as well). Since we don’t use
|
||||
these tools at Sandia, you’ll need to experiment with them and make
|
||||
necessary modifications yourself.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="binary2txt-tool">
|
||||
<span id="binary"></span><h2>9.2. binary2txt tool<a class="headerlink" href="#binary2txt-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The file binary2txt.cpp converts one or more binary LAMMPS dump file
|
||||
into ASCII text files. The syntax for running the tool is</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>binary2txt file1 file2 ...
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>which creates file1.txt, file2.txt, etc. This tool must be compiled
|
||||
on a platform that can read the binary file created by a LAMMPS run,
|
||||
since binary files are not compatible across all platforms.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="ch2lmp-tool">
|
||||
<span id="charmm"></span><h2>9.3. ch2lmp tool<a class="headerlink" href="#ch2lmp-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The ch2lmp sub-directory contains tools for converting files
|
||||
back-and-forth between the CHARMM MD code and LAMMPS.</p>
|
||||
<p>They are intended to make it easy to use CHARMM as a builder and as a
|
||||
post-processor for LAMMPS. Using charmm2lammps.pl, you can convert an
|
||||
ensemble built in CHARMM into its LAMMPS equivalent. Using
|
||||
lammps2pdb.pl you can convert LAMMPS atom dumps into pdb files.</p>
|
||||
<p>See the README file in the ch2lmp sub-directory for more information.</p>
|
||||
<p>These tools were created by Pieter in’t Veld (pjintve at sandia.gov)
|
||||
and Paul Crozier (pscrozi at sandia.gov) at Sandia.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="chain-tool">
|
||||
<span id="chain"></span><h2>9.4. chain tool<a class="headerlink" href="#chain-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The file chain.f creates a LAMMPS data file containing bead-spring
|
||||
polymer chains and/or monomer solvent atoms. It uses a text file
|
||||
containing chain definition parameters as an input. The created
|
||||
chains and solvent atoms can strongly overlap, so LAMMPS needs to run
|
||||
the system initially with a “soft” pair potential to un-overlap it.
|
||||
The syntax for running the tool is</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>chain < def.chain > data.file
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>See the def.chain or def.chain.ab files in the tools directory for
|
||||
examples of definition files. This tool was used to create the
|
||||
system for the <a class="reference internal" href="Section_perf.html"><em>chain benchmark</em></a>.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="colvars-tools">
|
||||
<span id="colvars"></span><h2>9.5. colvars tools<a class="headerlink" href="#colvars-tools" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The colvars directory contains a collection of tools for postprocessing
|
||||
data produced by the colvars collective variable library.
|
||||
To compile the tools, edit the makefile for your system and run “make”.</p>
|
||||
<p>Please report problems and issues the colvars library and its tools
|
||||
at: <a class="reference external" href="https://github.com/colvars/colvars/issues">https://github.com/colvars/colvars/issues</a></p>
|
||||
<p>abf_integrate:</p>
|
||||
<p>MC-based integration of multidimensional free energy gradient
|
||||
Version 20110511</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>Syntax: ./abf_integrate < filename > [-n < nsteps >] [-t < temp >] [-m [0|1] (metadynamics)] [-h < hill_height >] [-f < variable_hill_factor >]
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The LAMMPS interface to the colvars collective variable library, as
|
||||
well as these tools, were created by Axel Kohlmeyer (akohlmey at
|
||||
gmail.com) at ICTP, Italy.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="createatoms-tool">
|
||||
<span id="create"></span><h2>9.6. createatoms tool<a class="headerlink" href="#createatoms-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The tools/createatoms directory contains a Fortran program called
|
||||
createAtoms.f which can generate a variety of interesting crystal
|
||||
structures and geometries and output the resulting list of atom
|
||||
coordinates in LAMMPS or other formats.</p>
|
||||
<p>See the included Manual.pdf for details.</p>
|
||||
<p>The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="data2xmovie-tool">
|
||||
<span id="data"></span><h2>9.7. data2xmovie tool<a class="headerlink" href="#data2xmovie-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The file data2xmovie.c converts a LAMMPS data file into a snapshot
|
||||
suitable for visualizing with the <a class="reference internal" href="#xmovie"><span>xmovie</span></a> tool, as if it had
|
||||
been output with a dump command from LAMMPS itself. The syntax for
|
||||
running the tool is</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre><span class="n">data2xmovie</span> <span class="p">[</span><span class="n">options</span><span class="p">]</span> <span class="o"><</span> <span class="n">infile</span> <span class="o">></span> <span class="n">outfile</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>See the top of the data2xmovie.c file for a discussion of the options.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="eam-database-tool">
|
||||
<span id="eamdb"></span><h2>9.8. eam database tool<a class="headerlink" href="#eam-database-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The tools/eam_database directory contains a Fortran program that will
|
||||
generate EAM alloy setfl potential files for any combination of 16
|
||||
elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
|
||||
Zr. The files can then be used with the <a class="reference internal" href="pair_eam.html"><em>pair_style eam/alloy</em></a> command.</p>
|
||||
<p>The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov,
|
||||
and is based on his paper:</p>
|
||||
<p>X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
|
||||
144113 (2004).</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="eam-generate-tool">
|
||||
<span id="eamgn"></span><h2>9.9. eam generate tool<a class="headerlink" href="#eam-generate-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The tools/eam_generate directory contains several one-file C programs
|
||||
that convert an analytic formula into a tabulated <a class="reference internal" href="pair_eam.html"><em>embedded atom method (EAM)</em></a> setfl potential file. The potentials they
|
||||
produce are in the potentials directory, and can be used with the
|
||||
<a class="reference internal" href="pair_eam.html"><em>pair_style eam/alloy</em></a> command.</p>
|
||||
<p>The source files and potentials were provided by Gerolf Ziegenhain
|
||||
(gerolf at ziegenhain.com).</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="eff-tool">
|
||||
<span id="eff"></span><h2>9.10. eff tool<a class="headerlink" href="#eff-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The tools/eff directory contains various scripts for generating
|
||||
structures and post-processing output for simulations using the
|
||||
electron force field (eFF).</p>
|
||||
<p>These tools were provided by Andres Jaramillo-Botero at CalTech
|
||||
(ajaramil at wag.caltech.edu).</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="emacs-tool">
|
||||
<span id="emacs"></span><h2>9.11. emacs tool<a class="headerlink" href="#emacs-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The tools/emacs directory contains a Lips add-on file for Emacs that
|
||||
enables a lammps-mode for editing of input scripts when using Emacs,
|
||||
with various highlighting options setup.</p>
|
||||
<p>These tools were provided by Aidan Thompson at Sandia
|
||||
(athomps at sandia.gov).</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="fep-tool">
|
||||
<span id="fep"></span><h2>9.12. fep tool<a class="headerlink" href="#fep-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The tools/fep directory contains Python scripts useful for
|
||||
post-processing results from performing free-energy perturbation
|
||||
simulations using the USER-FEP package.</p>
|
||||
<p>The scripts were contributed by Agilio Padua (Universite Blaise
|
||||
Pascal Clermont-Ferrand), agilio.padua at univ-bpclermont.fr.</p>
|
||||
<p>See README file in the tools/fep directory.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="i-pi-tool">
|
||||
<span id="ipi"></span><h2>9.13. i-pi tool<a class="headerlink" href="#i-pi-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The tools/i-pi directory contains a version of the i-PI package, with
|
||||
all the LAMMPS-unrelated files removed. It is provided so that it can
|
||||
be used with the <a class="reference internal" href="fix_ipi.html"><em>fix ipi</em></a> command to perform
|
||||
path-integral molecular dynamics (PIMD).</p>
|
||||
<p>The i-PI package was created and is maintained by Michele Ceriotti,
|
||||
michele.ceriotti at gmail.com, to interface to a variety of molecular
|
||||
dynamics codes.</p>
|
||||
<p>See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
|
||||
<a class="reference internal" href="fix_ipi.html"><em>fix ipi</em></a> doc page for further details on running PIMD
|
||||
calculations with LAMMPS.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="ipp-tool">
|
||||
<span id="ipp"></span><h2>9.14. ipp tool<a class="headerlink" href="#ipp-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The tools/ipp directory contains a Perl script ipp which can be used
|
||||
to facilitate the creation of a complicated file (say, a lammps input
|
||||
script or tools/createatoms input file) using a template file.</p>
|
||||
<p>ipp was created and is maintained by Reese Jones (Sandia), rjones at
|
||||
sandia.gov.</p>
|
||||
<p>See two examples in the tools/ipp directory. One of them is for the
|
||||
tools/createatoms tool’s input file.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="kate-tool">
|
||||
<span id="kate"></span><h2>9.15. kate tool<a class="headerlink" href="#kate-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The file in the tools/kate directory is an add-on to the Kate editor
|
||||
in the KDE suite that allow syntax highlighting of LAMMPS input
|
||||
scripts. See the README.txt file for details.</p>
|
||||
<p>The file was provided by Alessandro Luigi Sellerio
|
||||
(alessandro.sellerio at ieni.cnr.it).</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="lmp2arc-tool">
|
||||
<span id="arc"></span><h2>9.16. lmp2arc tool<a class="headerlink" href="#lmp2arc-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The lmp2arc sub-directory contains a tool for converting LAMMPS output
|
||||
files to the format for Accelrys’ Insight MD code (formerly
|
||||
MSI/Biosym and its Discover MD code). See the README file for more
|
||||
information.</p>
|
||||
<p>This tool was written by John Carpenter (Cray), Michael Peachey
|
||||
(Cray), and Steve Lustig (Dupont). John is now at the Mayo Clinic
|
||||
(jec at mayo.edu), but still fields questions about the tool.</p>
|
||||
<p>This tool was updated for the current LAMMPS C++ version by Jeff
|
||||
Greathouse at Sandia (jagreat at sandia.gov).</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="lmp2cfg-tool">
|
||||
<span id="cfg"></span><h2>9.17. lmp2cfg tool<a class="headerlink" href="#lmp2cfg-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The lmp2cfg sub-directory contains a tool for converting LAMMPS output
|
||||
files into a series of <a href="#id1"><span class="problematic" id="id2">*</span></a>.cfg files which can be read into the
|
||||
<a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a> visualizer. See
|
||||
the README file for more information.</p>
|
||||
<p>This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="lmp2vmd-tool">
|
||||
<span id="vmd"></span><h2>9.18. lmp2vmd tool<a class="headerlink" href="#lmp2vmd-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The lmp2vmd sub-directory contains a README.txt file that describes
|
||||
details of scripts and plugin support within the <a class="reference external" href="http://www.ks.uiuc.edu/Research/vmd">VMD package</a> for visualizing LAMMPS
|
||||
dump files.</p>
|
||||
<p>The VMD plugins and other supporting scripts were written by Axel
|
||||
Kohlmeyer (akohlmey at cmm.chem.upenn.edu) at U Penn.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="matlab-tool">
|
||||
<span id="matlab"></span><h2>9.19. matlab tool<a class="headerlink" href="#matlab-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The matlab sub-directory contains several <span class="xref std std-ref">MATLAB</span> scripts for
|
||||
post-processing LAMMPS output. The scripts include readers for log
|
||||
and dump files, a reader for EAM potential files, and a converter that
|
||||
reads LAMMPS dump files and produces CFG files that can be visualized
|
||||
with the <a class="reference external" href="http://mt.seas.upenn.edu/Archive/Graphics/A">AtomEye</a>
|
||||
visualizer.</p>
|
||||
<p>See the README.pdf file for more information.</p>
|
||||
<p>These scripts were written by Arun Subramaniyan at Purdue Univ
|
||||
(asubrama at purdue.edu).</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="micelle2d-tool">
|
||||
<span id="micelle"></span><h2>9.20. micelle2d tool<a class="headerlink" href="#micelle2d-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The file micelle2d.f creates a LAMMPS data file containing short lipid
|
||||
chains in a monomer solution. It uses a text file containing lipid
|
||||
definition parameters as an input. The created molecules and solvent
|
||||
atoms can strongly overlap, so LAMMPS needs to run the system
|
||||
initially with a “soft” pair potential to un-overlap it. The syntax
|
||||
for running the tool is</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>micelle2d < def.micelle2d > data.file
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>See the def.micelle2d file in the tools directory for an example of a
|
||||
definition file. This tool was used to create the system for the
|
||||
<a class="reference internal" href="Section_example.html"><em>micelle example</em></a>.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="moltemplate-tool">
|
||||
<span id="moltemplate"></span><h2>9.21. moltemplate tool<a class="headerlink" href="#moltemplate-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The moltemplate sub-directory contains a Python-based tool for
|
||||
building molecular systems based on a text-file description, and
|
||||
creating LAMMPS data files that encode their molecular topology as
|
||||
lists of bonds, angles, dihedrals, etc. See the README.TXT file for
|
||||
more information.</p>
|
||||
<p>This tool was written by Andrew Jewett (jewett.aij at gmail.com), who
|
||||
supports it. It has its own WWW page at
|
||||
<a class="reference external" href="http://moltemplate.org">http://moltemplate.org</a>.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="msi2lmp-tool">
|
||||
<span id="msi"></span><h2>9.22. msi2lmp tool<a class="headerlink" href="#msi2lmp-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The msi2lmp sub-directory contains a tool for creating LAMMPS input
|
||||
data files from Accelrys’ Insight MD code (formerly MSI/Biosym and
|
||||
its Discover MD code). See the README file for more information.</p>
|
||||
<p>This tool was written by John Carpenter (Cray), Michael Peachey
|
||||
(Cray), and Steve Lustig (Dupont). John is now at the Mayo Clinic
|
||||
(jec at mayo.edu), but still fields questions about the tool.</p>
|
||||
<p>This tool may be out-of-date with respect to the current LAMMPS and
|
||||
Insight versions. Since we don’t use it at Sandia, you’ll need to
|
||||
experiment with it yourself.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="phonon-tool">
|
||||
<span id="phonon"></span><h2>9.23. phonon tool<a class="headerlink" href="#phonon-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The phonon sub-directory contains a post-processing tool useful for
|
||||
analyzing the output of the <a class="reference internal" href="fix_phonon.html"><em>fix phonon</em></a> command in
|
||||
the USER-PHONON package.</p>
|
||||
<p>See the README file for instruction on building the tool and what
|
||||
library it needs. And see the examples/USER/phonon directory
|
||||
for example problems that can be post-processed with this tool.</p>
|
||||
<p>This tool was written by Ling-Ti Kong at Shanghai Jiao Tong
|
||||
University.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="polymer-bonding-tool">
|
||||
<span id="polybond"></span><h2>9.24. polymer bonding tool<a class="headerlink" href="#polymer-bonding-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The polybond sub-directory contains a Python-based tool useful for
|
||||
performing “programmable polymer bonding”. The Python file
|
||||
lmpsdata.py provides a “Lmpsdata” class with various methods which can
|
||||
be invoked by a user-written Python script to create data files with
|
||||
complex bonding topologies.</p>
|
||||
<p>See the Manual.pdf for details and example scripts.</p>
|
||||
<p>This tool was written by Zachary Kraus at Georgia Tech.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="pymol-asphere-tool">
|
||||
<span id="pymol"></span><h2>9.25. pymol_asphere tool<a class="headerlink" href="#pymol-asphere-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The pymol_asphere sub-directory contains a tool for converting a
|
||||
LAMMPS dump file that contains orientation info for ellipsoidal
|
||||
particles into an input file for the <span class="xref std std-ref">PyMol visualization package</span>.</p>
|
||||
<p>Specifically, the tool triangulates the ellipsoids so they can be
|
||||
viewed as true ellipsoidal particles within PyMol. See the README and
|
||||
examples directory within pymol_asphere for more information.</p>
|
||||
<p>This tool was written by Mike Brown at Sandia.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="python-tool">
|
||||
<span id="pythontools"></span><h2>9.26. python tool<a class="headerlink" href="#python-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The python sub-directory contains several Python scripts
|
||||
that perform common LAMMPS post-processing tasks, such as:</p>
|
||||
<ul class="simple">
|
||||
<li>extract thermodynamic info from a log file as columns of numbers</li>
|
||||
<li>plot two columns of thermodynamic info from a log file using GnuPlot</li>
|
||||
<li>sort the snapshots in a dump file by atom ID</li>
|
||||
<li>convert multiple <a class="reference internal" href="neb.html"><em>NEB</em></a> dump files into one dump file for viz</li>
|
||||
<li>convert dump files into XYZ, CFG, or PDB format for viz by other packages</li>
|
||||
</ul>
|
||||
<p>These are simple scripts built on <a class="reference external" href="http://www.sandia.gov/~sjplimp/pizza.html">Pizza.py</a> modules. See the
|
||||
README for more info on Pizza.py and how to use these scripts.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="reax-tool">
|
||||
<span id="reax"></span><h2>9.27. reax tool<a class="headerlink" href="#reax-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The reax sub-directory contains stand-alond codes that can
|
||||
post-process the output of the <a class="reference internal" href="fix_reax_bonds.html"><em>fix reax/bonds</em></a>
|
||||
command from a LAMMPS simulation using <a class="reference internal" href="pair_reax.html"><em>ReaxFF</em></a>. See
|
||||
the README.txt file for more info.</p>
|
||||
<p>These tools were written by Aidan Thompson at Sandia.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="restart2data-tool">
|
||||
<span id="restart"></span><h2>9.28. restart2data tool<a class="headerlink" href="#restart2data-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">This tool is now obsolete and is not included in the current
|
||||
LAMMPS distribution. This is becaues there is now a
|
||||
<a class="reference internal" href="write_data.html"><em>write_data</em></a> command, which can create a data file
|
||||
from within an input script. Running LAMMPS with the “-r”
|
||||
<a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> as follows:</p>
|
||||
</div>
|
||||
<p>lmp_g++ -r restartfile datafile</p>
|
||||
<p>is the same as running a 2-line input script:</p>
|
||||
<p>read_restart restartfile
|
||||
write_data datafile</p>
|
||||
<p>which will produce the same data file that the restart2data tool used
|
||||
to create. The following information is included in case you have an
|
||||
older version of LAMMPS which still includes the restart2data tool.</p>
|
||||
<p>The file restart2data.cpp converts a binary LAMMPS restart file into
|
||||
an ASCII data file. The syntax for running the tool is</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>restart2data restart-file data-file (input-file)
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Input-file is optional and if specified will contain LAMMPS input
|
||||
commands for the masses and force field parameters, instead of putting
|
||||
those in the data-file. Only a few force field styles currently
|
||||
support this option.</p>
|
||||
<p>This tool must be compiled on a platform that can read the binary file
|
||||
created by a LAMMPS run, since binary files are not compatible across
|
||||
all platforms.</p>
|
||||
<p>Note that a text data file has less precision than a binary restart
|
||||
file. Hence, continuing a run from a converted data file will
|
||||
typically not conform as closely to a previous run as will restarting
|
||||
from a binary restart file.</p>
|
||||
<p>If a “%” appears in the specified restart-file, the tool expects a set
|
||||
of multiple files to exist. See the <a class="reference internal" href="restart.html"><em>restart</em></a> and
|
||||
<a class="reference internal" href="write_restart.html"><em>write_restart</em></a> commands for info on how such sets
|
||||
of files are written by LAMMPS, and how the files are named.</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="vim-tool">
|
||||
<span id="vim"></span><h2>9.29. vim tool<a class="headerlink" href="#vim-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The files in the tools/vim directory are add-ons to the VIM editor
|
||||
that allow easier editing of LAMMPS input scripts. See the README.txt
|
||||
file for details.</p>
|
||||
<p>These files were provided by Gerolf Ziegenhain (gerolf at
|
||||
ziegenhain.com)</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="xmgrace-tool">
|
||||
<span id="xmgrace"></span><h2>9.30. xmgrace tool<a class="headerlink" href="#xmgrace-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The files in the tools/xmgrace directory can be used to plot the
|
||||
thermodynamic data in LAMMPS log files via the xmgrace plotting
|
||||
package. There are several tools in the directory that can be used in
|
||||
post-processing mode. The lammpsplot.cpp file can be compiled and
|
||||
used to create plots from the current state of a running LAMMPS
|
||||
simulation.</p>
|
||||
<p>See the README file for details.</p>
|
||||
<p>These files were provided by Vikas Varshney (vv0210 at gmail.com)</p>
|
||||
<hr class="docutils" />
|
||||
</div>
|
||||
<div class="section" id="xmovie-tool">
|
||||
<span id="xmovie"></span><h2>9.31. xmovie tool<a class="headerlink" href="#xmovie-tool" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The xmovie tool is an X-based visualization package that can read
|
||||
LAMMPS dump files and animate them. It is in its own sub-directory
|
||||
with the tools directory. You may need to modify its Makefile so that
|
||||
it can find the appropriate X libraries to link against.</p>
|
||||
<p>The syntax for running xmovie is</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>xmovie [options] dump.file1 dump.file2 ...
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>If you just type “xmovie” you will see a list of options. Note that
|
||||
by default, LAMMPS dump files are in scaled coordinates, so you
|
||||
typically need to use the -scale option with xmovie. When xmovie runs
|
||||
it opens a visualization window and a control window. The control
|
||||
options are straightforward to use.</p>
|
||||
<p>Xmovie was mostly written by Mike Uttormark (U Wisconsin) while he
|
||||
spent a summer at Sandia. It displays 2d projections of a 3d domain.
|
||||
While simple in design, it is an amazingly fast program that can
|
||||
render large numbers of atoms very quickly. It’s a useful tool for
|
||||
debugging LAMMPS input and output and making sure your simulation is
|
||||
doing what you think it should. The animations on the Examples page
|
||||
of the <a class="reference external" href="http://lammps.sandia.gov">LAMMPS WWW site</a> were created with xmovie.</p>
|
||||
<p>I’ve lost contact with Mike, so I hope he’s comfortable with us
|
||||
distributing his great tool!</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
|
||||
|
||||
<a href="Section_modify.html" class="btn btn-neutral float-right" title="10. Modifying & extending LAMMPS" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
||||
|
||||
|
||||
<a href="Section_perf.html" class="btn btn-neutral" title="8. Performance & scalability" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,566 +0,0 @@
|
||||
"Previous Section"_Section_perf.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
||||
Documentation"_ld - "LAMMPS Commands"_lc - "Next
|
||||
Section"_Section_modify.html :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
9. Additional tools :h3
|
||||
|
||||
LAMMPS is designed to be a computational kernel for performing
|
||||
molecular dynamics computations. Additional pre- and post-processing
|
||||
steps are often necessary to setup and analyze a simulation. A few
|
||||
additional tools are provided with the LAMMPS distribution and are
|
||||
described in this section.
|
||||
|
||||
Our group has also written and released a separate toolkit called
|
||||
"Pizza.py"_pizza which provides tools for doing setup, analysis,
|
||||
plotting, and visualization for LAMMPS simulations. Pizza.py is
|
||||
written in "Python"_python and is available for download from "the
|
||||
Pizza.py WWW site"_pizza.
|
||||
|
||||
:link(pizza,http://www.sandia.gov/~sjplimp/pizza.html)
|
||||
:link(python,http://www.python.org)
|
||||
|
||||
Note that many users write their own setup or analysis tools or use
|
||||
other existing codes and convert their output to a LAMMPS input format
|
||||
or vice versa. The tools listed here are included in the LAMMPS
|
||||
distribution as examples of auxiliary tools. Some of them are not
|
||||
actively supported by Sandia, as they were contributed by LAMMPS
|
||||
users. If you have problems using them, we can direct you to the
|
||||
authors.
|
||||
|
||||
The source code for each of these codes is in the tools sub-directory
|
||||
of the LAMMPS distribution. There is a Makefile (which you may need
|
||||
to edit for your platform) which will build several of the tools which
|
||||
reside in that directory. Some of them are larger packages in their
|
||||
own sub-directories with their own Makefiles.
|
||||
|
||||
"amber2lmp"_#amber
|
||||
"binary2txt"_#binary
|
||||
"ch2lmp"_#charmm
|
||||
"chain"_#chain
|
||||
"colvars"_#colvars
|
||||
"createatoms"_#create
|
||||
"data2xmovie"_#data
|
||||
"eam database"_#eamdb
|
||||
"eam generate"_#eamgn
|
||||
"eff"_#eff
|
||||
"emacs"_#emacs
|
||||
"fep"_#fep
|
||||
"i-pi"_#ipi
|
||||
"ipp"_#ipp
|
||||
"kate"_#kate
|
||||
"lmp2arc"_#arc
|
||||
"lmp2cfg"_#cfg
|
||||
"lmp2vmd"_#vmd
|
||||
"matlab"_#matlab
|
||||
"micelle2d"_#micelle
|
||||
"moltemplate"_#moltemplate
|
||||
"msi2lmp"_#msi
|
||||
"phonon"_#phonon
|
||||
"polymer bonding"_#polybond
|
||||
"pymol_asphere"_#pymol
|
||||
"python"_#pythontools
|
||||
"reax"_#reax
|
||||
"restart2data"_#restart
|
||||
"vim"_#vim
|
||||
"xmgrace"_#xmgrace
|
||||
"xmovie"_#xmovie :ul
|
||||
|
||||
:line
|
||||
|
||||
amber2lmp tool :h4,link(amber)
|
||||
|
||||
The amber2lmp sub-directory contains two Python scripts for converting
|
||||
files back-and-forth between the AMBER MD code and LAMMPS. See the
|
||||
README file in amber2lmp for more information.
|
||||
|
||||
These tools were written by Keir Novik while he was at Queen Mary
|
||||
University of London. Keir is no longer there and cannot support
|
||||
these tools which are out-of-date with respect to the current LAMMPS
|
||||
version (and maybe with respect to AMBER as well). Since we don't use
|
||||
these tools at Sandia, you'll need to experiment with them and make
|
||||
necessary modifications yourself.
|
||||
|
||||
:line
|
||||
|
||||
binary2txt tool :h4,link(binary)
|
||||
|
||||
The file binary2txt.cpp converts one or more binary LAMMPS dump file
|
||||
into ASCII text files. The syntax for running the tool is
|
||||
|
||||
binary2txt file1 file2 ... :pre
|
||||
|
||||
which creates file1.txt, file2.txt, etc. This tool must be compiled
|
||||
on a platform that can read the binary file created by a LAMMPS run,
|
||||
since binary files are not compatible across all platforms.
|
||||
|
||||
:line
|
||||
|
||||
ch2lmp tool :h4,link(charmm)
|
||||
|
||||
The ch2lmp sub-directory contains tools for converting files
|
||||
back-and-forth between the CHARMM MD code and LAMMPS.
|
||||
|
||||
They are intended to make it easy to use CHARMM as a builder and as a
|
||||
post-processor for LAMMPS. Using charmm2lammps.pl, you can convert an
|
||||
ensemble built in CHARMM into its LAMMPS equivalent. Using
|
||||
lammps2pdb.pl you can convert LAMMPS atom dumps into pdb files.
|
||||
|
||||
See the README file in the ch2lmp sub-directory for more information.
|
||||
|
||||
These tools were created by Pieter in't Veld (pjintve at sandia.gov)
|
||||
and Paul Crozier (pscrozi at sandia.gov) at Sandia.
|
||||
|
||||
:line
|
||||
|
||||
chain tool :h4,link(chain)
|
||||
|
||||
The file chain.f creates a LAMMPS data file containing bead-spring
|
||||
polymer chains and/or monomer solvent atoms. It uses a text file
|
||||
containing chain definition parameters as an input. The created
|
||||
chains and solvent atoms can strongly overlap, so LAMMPS needs to run
|
||||
the system initially with a "soft" pair potential to un-overlap it.
|
||||
The syntax for running the tool is
|
||||
|
||||
chain < def.chain > data.file :pre
|
||||
|
||||
See the def.chain or def.chain.ab files in the tools directory for
|
||||
examples of definition files. This tool was used to create the
|
||||
system for the "chain benchmark"_Section_perf.html.
|
||||
|
||||
:line
|
||||
|
||||
colvars tools :h4,link(colvars)
|
||||
|
||||
The colvars directory contains a collection of tools for postprocessing
|
||||
data produced by the colvars collective variable library.
|
||||
To compile the tools, edit the makefile for your system and run "make".
|
||||
|
||||
Please report problems and issues the colvars library and its tools
|
||||
at: https://github.com/colvars/colvars/issues
|
||||
|
||||
abf_integrate:
|
||||
|
||||
MC-based integration of multidimensional free energy gradient
|
||||
Version 20110511
|
||||
|
||||
Syntax: ./abf_integrate < filename > \[-n < nsteps >\] \[-t < temp >\] \[-m \[0|1\] (metadynamics)\] \[-h < hill_height >\] \[-f < variable_hill_factor >\] :pre
|
||||
|
||||
The LAMMPS interface to the colvars collective variable library, as
|
||||
well as these tools, were created by Axel Kohlmeyer (akohlmey at
|
||||
gmail.com) at ICTP, Italy.
|
||||
|
||||
:line
|
||||
|
||||
createatoms tool :h4,link(create)
|
||||
|
||||
The tools/createatoms directory contains a Fortran program called
|
||||
createAtoms.f which can generate a variety of interesting crystal
|
||||
structures and geometries and output the resulting list of atom
|
||||
coordinates in LAMMPS or other formats.
|
||||
|
||||
See the included Manual.pdf for details.
|
||||
|
||||
The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov.
|
||||
|
||||
:line
|
||||
|
||||
data2xmovie tool :h4,link(data)
|
||||
|
||||
The file data2xmovie.c converts a LAMMPS data file into a snapshot
|
||||
suitable for visualizing with the "xmovie"_#xmovie tool, as if it had
|
||||
been output with a dump command from LAMMPS itself. The syntax for
|
||||
running the tool is
|
||||
|
||||
data2xmovie \[options\] < infile > outfile :pre
|
||||
|
||||
See the top of the data2xmovie.c file for a discussion of the options.
|
||||
|
||||
:line
|
||||
|
||||
eam database tool :h4,link(eamdb)
|
||||
|
||||
The tools/eam_database directory contains a Fortran program that will
|
||||
generate EAM alloy setfl potential files for any combination of 16
|
||||
elements: Cu, Ag, Au, Ni, Pd, Pt, Al, Pb, Fe, Mo, Ta, W, Mg, Co, Ti,
|
||||
Zr. The files can then be used with the "pair_style
|
||||
eam/alloy"_pair_eam.html command.
|
||||
|
||||
The tool is authored by Xiaowang Zhou (Sandia), xzhou at sandia.gov,
|
||||
and is based on his paper:
|
||||
|
||||
X. W. Zhou, R. A. Johnson, and H. N. G. Wadley, Phys. Rev. B, 69,
|
||||
144113 (2004).
|
||||
|
||||
:line
|
||||
|
||||
eam generate tool :h4,link(eamgn)
|
||||
|
||||
The tools/eam_generate directory contains several one-file C programs
|
||||
that convert an analytic formula into a tabulated "embedded atom
|
||||
method (EAM)"_pair_eam.html setfl potential file. The potentials they
|
||||
produce are in the potentials directory, and can be used with the
|
||||
"pair_style eam/alloy"_pair_eam.html command.
|
||||
|
||||
The source files and potentials were provided by Gerolf Ziegenhain
|
||||
(gerolf at ziegenhain.com).
|
||||
|
||||
:line
|
||||
|
||||
eff tool :h4,link(eff)
|
||||
|
||||
The tools/eff directory contains various scripts for generating
|
||||
structures and post-processing output for simulations using the
|
||||
electron force field (eFF).
|
||||
|
||||
These tools were provided by Andres Jaramillo-Botero at CalTech
|
||||
(ajaramil at wag.caltech.edu).
|
||||
|
||||
:line
|
||||
|
||||
emacs tool :h4,link(emacs)
|
||||
|
||||
The tools/emacs directory contains a Lips add-on file for Emacs that
|
||||
enables a lammps-mode for editing of input scripts when using Emacs,
|
||||
with various highlighting options setup.
|
||||
|
||||
These tools were provided by Aidan Thompson at Sandia
|
||||
(athomps at sandia.gov).
|
||||
|
||||
:line
|
||||
|
||||
fep tool :h4,link(fep)
|
||||
|
||||
The tools/fep directory contains Python scripts useful for
|
||||
post-processing results from performing free-energy perturbation
|
||||
simulations using the USER-FEP package.
|
||||
|
||||
The scripts were contributed by Agilio Padua (Universite Blaise
|
||||
Pascal Clermont-Ferrand), agilio.padua at univ-bpclermont.fr.
|
||||
|
||||
See README file in the tools/fep directory.
|
||||
|
||||
:line
|
||||
|
||||
i-pi tool :h4,link(ipi)
|
||||
|
||||
The tools/i-pi directory contains a version of the i-PI package, with
|
||||
all the LAMMPS-unrelated files removed. It is provided so that it can
|
||||
be used with the "fix ipi"_fix_ipi.html command to perform
|
||||
path-integral molecular dynamics (PIMD).
|
||||
|
||||
The i-PI package was created and is maintained by Michele Ceriotti,
|
||||
michele.ceriotti at gmail.com, to interface to a variety of molecular
|
||||
dynamics codes.
|
||||
|
||||
See the tools/i-pi/manual.pdf file for an overview of i-PI, and the
|
||||
"fix ipi"_fix_ipi.html doc page for further details on running PIMD
|
||||
calculations with LAMMPS.
|
||||
|
||||
:line
|
||||
|
||||
ipp tool :h4,link(ipp)
|
||||
|
||||
The tools/ipp directory contains a Perl script ipp which can be used
|
||||
to facilitate the creation of a complicated file (say, a lammps input
|
||||
script or tools/createatoms input file) using a template file.
|
||||
|
||||
ipp was created and is maintained by Reese Jones (Sandia), rjones at
|
||||
sandia.gov.
|
||||
|
||||
See two examples in the tools/ipp directory. One of them is for the
|
||||
tools/createatoms tool's input file.
|
||||
|
||||
:line
|
||||
|
||||
kate tool :h4,link(kate)
|
||||
|
||||
The file in the tools/kate directory is an add-on to the Kate editor
|
||||
in the KDE suite that allow syntax highlighting of LAMMPS input
|
||||
scripts. See the README.txt file for details.
|
||||
|
||||
The file was provided by Alessandro Luigi Sellerio
|
||||
(alessandro.sellerio at ieni.cnr.it).
|
||||
|
||||
:line
|
||||
|
||||
lmp2arc tool :h4,link(arc)
|
||||
|
||||
The lmp2arc sub-directory contains a tool for converting LAMMPS output
|
||||
files to the format for Accelrys' Insight MD code (formerly
|
||||
MSI/Biosym and its Discover MD code). See the README file for more
|
||||
information.
|
||||
|
||||
This tool was written by John Carpenter (Cray), Michael Peachey
|
||||
(Cray), and Steve Lustig (Dupont). John is now at the Mayo Clinic
|
||||
(jec at mayo.edu), but still fields questions about the tool.
|
||||
|
||||
This tool was updated for the current LAMMPS C++ version by Jeff
|
||||
Greathouse at Sandia (jagreat at sandia.gov).
|
||||
|
||||
:line
|
||||
|
||||
lmp2cfg tool :h4,link(cfg)
|
||||
|
||||
The lmp2cfg sub-directory contains a tool for converting LAMMPS output
|
||||
files into a series of *.cfg files which can be read into the
|
||||
"AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A visualizer. See
|
||||
the README file for more information.
|
||||
|
||||
This tool was written by Ara Kooser at Sandia (askoose at sandia.gov).
|
||||
|
||||
:line
|
||||
|
||||
lmp2vmd tool :h4,link(vmd)
|
||||
|
||||
The lmp2vmd sub-directory contains a README.txt file that describes
|
||||
details of scripts and plugin support within the "VMD
|
||||
package"_http://www.ks.uiuc.edu/Research/vmd for visualizing LAMMPS
|
||||
dump files.
|
||||
|
||||
The VMD plugins and other supporting scripts were written by Axel
|
||||
Kohlmeyer (akohlmey at cmm.chem.upenn.edu) at U Penn.
|
||||
|
||||
:line
|
||||
|
||||
matlab tool :h4,link(matlab)
|
||||
|
||||
The matlab sub-directory contains several "MATLAB"_matlab scripts for
|
||||
post-processing LAMMPS output. The scripts include readers for log
|
||||
and dump files, a reader for EAM potential files, and a converter that
|
||||
reads LAMMPS dump files and produces CFG files that can be visualized
|
||||
with the "AtomEye"_http://mt.seas.upenn.edu/Archive/Graphics/A
|
||||
visualizer.
|
||||
|
||||
See the README.pdf file for more information.
|
||||
|
||||
These scripts were written by Arun Subramaniyan at Purdue Univ
|
||||
(asubrama at purdue.edu).
|
||||
|
||||
:link(matlab,http://www.mathworks.com)
|
||||
|
||||
:line
|
||||
|
||||
micelle2d tool :h4,link(micelle)
|
||||
|
||||
The file micelle2d.f creates a LAMMPS data file containing short lipid
|
||||
chains in a monomer solution. It uses a text file containing lipid
|
||||
definition parameters as an input. The created molecules and solvent
|
||||
atoms can strongly overlap, so LAMMPS needs to run the system
|
||||
initially with a "soft" pair potential to un-overlap it. The syntax
|
||||
for running the tool is
|
||||
|
||||
micelle2d < def.micelle2d > data.file :pre
|
||||
|
||||
See the def.micelle2d file in the tools directory for an example of a
|
||||
definition file. This tool was used to create the system for the
|
||||
"micelle example"_Section_example.html.
|
||||
|
||||
:line
|
||||
|
||||
moltemplate tool :h4,link(moltemplate)
|
||||
|
||||
The moltemplate sub-directory contains a Python-based tool for
|
||||
building molecular systems based on a text-file description, and
|
||||
creating LAMMPS data files that encode their molecular topology as
|
||||
lists of bonds, angles, dihedrals, etc. See the README.TXT file for
|
||||
more information.
|
||||
|
||||
This tool was written by Andrew Jewett (jewett.aij at gmail.com), who
|
||||
supports it. It has its own WWW page at
|
||||
"http://moltemplate.org"_http://moltemplate.org.
|
||||
|
||||
:line
|
||||
|
||||
msi2lmp tool :h4,link(msi)
|
||||
|
||||
The msi2lmp sub-directory contains a tool for creating LAMMPS input
|
||||
data files from Accelrys' Insight MD code (formerly MSI/Biosym and
|
||||
its Discover MD code). See the README file for more information.
|
||||
|
||||
This tool was written by John Carpenter (Cray), Michael Peachey
|
||||
(Cray), and Steve Lustig (Dupont). John is now at the Mayo Clinic
|
||||
(jec at mayo.edu), but still fields questions about the tool.
|
||||
|
||||
This tool may be out-of-date with respect to the current LAMMPS and
|
||||
Insight versions. Since we don't use it at Sandia, you'll need to
|
||||
experiment with it yourself.
|
||||
|
||||
:line
|
||||
|
||||
phonon tool :h4,link(phonon)
|
||||
|
||||
The phonon sub-directory contains a post-processing tool useful for
|
||||
analyzing the output of the "fix phonon"_fix_phonon.html command in
|
||||
the USER-PHONON package.
|
||||
|
||||
See the README file for instruction on building the tool and what
|
||||
library it needs. And see the examples/USER/phonon directory
|
||||
for example problems that can be post-processed with this tool.
|
||||
|
||||
This tool was written by Ling-Ti Kong at Shanghai Jiao Tong
|
||||
University.
|
||||
|
||||
:line
|
||||
|
||||
polymer bonding tool :h4,link(polybond)
|
||||
|
||||
The polybond sub-directory contains a Python-based tool useful for
|
||||
performing "programmable polymer bonding". The Python file
|
||||
lmpsdata.py provides a "Lmpsdata" class with various methods which can
|
||||
be invoked by a user-written Python script to create data files with
|
||||
complex bonding topologies.
|
||||
|
||||
See the Manual.pdf for details and example scripts.
|
||||
|
||||
This tool was written by Zachary Kraus at Georgia Tech.
|
||||
|
||||
:line
|
||||
|
||||
pymol_asphere tool :h4,link(pymol)
|
||||
|
||||
The pymol_asphere sub-directory contains a tool for converting a
|
||||
LAMMPS dump file that contains orientation info for ellipsoidal
|
||||
particles into an input file for the "PyMol visualization
|
||||
package"_pymol.
|
||||
|
||||
:link(pymol,http://pymol.sourceforge.net)
|
||||
|
||||
Specifically, the tool triangulates the ellipsoids so they can be
|
||||
viewed as true ellipsoidal particles within PyMol. See the README and
|
||||
examples directory within pymol_asphere for more information.
|
||||
|
||||
This tool was written by Mike Brown at Sandia.
|
||||
|
||||
:line
|
||||
|
||||
python tool :h4,link(pythontools)
|
||||
|
||||
The python sub-directory contains several Python scripts
|
||||
that perform common LAMMPS post-processing tasks, such as:
|
||||
|
||||
extract thermodynamic info from a log file as columns of numbers
|
||||
plot two columns of thermodynamic info from a log file using GnuPlot
|
||||
sort the snapshots in a dump file by atom ID
|
||||
convert multiple "NEB"_neb.html dump files into one dump file for viz
|
||||
convert dump files into XYZ, CFG, or PDB format for viz by other packages :ul
|
||||
|
||||
These are simple scripts built on "Pizza.py"_pizza modules. See the
|
||||
README for more info on Pizza.py and how to use these scripts.
|
||||
|
||||
:line
|
||||
|
||||
reax tool :h4,link(reax)
|
||||
|
||||
The reax sub-directory contains stand-alond codes that can
|
||||
post-process the output of the "fix reax/bonds"_fix_reax_bonds.html
|
||||
command from a LAMMPS simulation using "ReaxFF"_pair_reax.html. See
|
||||
the README.txt file for more info.
|
||||
|
||||
These tools were written by Aidan Thompson at Sandia.
|
||||
|
||||
:line
|
||||
|
||||
restart2data tool :h4,link(restart)
|
||||
|
||||
NOTE: This tool is now obsolete and is not included in the current
|
||||
LAMMPS distribution. This is becaues there is now a
|
||||
"write_data"_write_data.html command, which can create a data file
|
||||
from within an input script. Running LAMMPS with the "-r"
|
||||
"command-line switch"_Section_start.html#start_7 as follows:
|
||||
|
||||
lmp_g++ -r restartfile datafile
|
||||
|
||||
is the same as running a 2-line input script:
|
||||
|
||||
read_restart restartfile
|
||||
write_data datafile
|
||||
|
||||
which will produce the same data file that the restart2data tool used
|
||||
to create. The following information is included in case you have an
|
||||
older version of LAMMPS which still includes the restart2data tool.
|
||||
|
||||
The file restart2data.cpp converts a binary LAMMPS restart file into
|
||||
an ASCII data file. The syntax for running the tool is
|
||||
|
||||
restart2data restart-file data-file (input-file) :pre
|
||||
|
||||
Input-file is optional and if specified will contain LAMMPS input
|
||||
commands for the masses and force field parameters, instead of putting
|
||||
those in the data-file. Only a few force field styles currently
|
||||
support this option.
|
||||
|
||||
This tool must be compiled on a platform that can read the binary file
|
||||
created by a LAMMPS run, since binary files are not compatible across
|
||||
all platforms.
|
||||
|
||||
Note that a text data file has less precision than a binary restart
|
||||
file. Hence, continuing a run from a converted data file will
|
||||
typically not conform as closely to a previous run as will restarting
|
||||
from a binary restart file.
|
||||
|
||||
If a "%" appears in the specified restart-file, the tool expects a set
|
||||
of multiple files to exist. See the "restart"_restart.html and
|
||||
"write_restart"_write_restart.html commands for info on how such sets
|
||||
of files are written by LAMMPS, and how the files are named.
|
||||
|
||||
:line
|
||||
|
||||
vim tool :h4,link(vim)
|
||||
|
||||
The files in the tools/vim directory are add-ons to the VIM editor
|
||||
that allow easier editing of LAMMPS input scripts. See the README.txt
|
||||
file for details.
|
||||
|
||||
These files were provided by Gerolf Ziegenhain (gerolf at
|
||||
ziegenhain.com)
|
||||
|
||||
:line
|
||||
|
||||
xmgrace tool :h4,link(xmgrace)
|
||||
|
||||
The files in the tools/xmgrace directory can be used to plot the
|
||||
thermodynamic data in LAMMPS log files via the xmgrace plotting
|
||||
package. There are several tools in the directory that can be used in
|
||||
post-processing mode. The lammpsplot.cpp file can be compiled and
|
||||
used to create plots from the current state of a running LAMMPS
|
||||
simulation.
|
||||
|
||||
See the README file for details.
|
||||
|
||||
These files were provided by Vikas Varshney (vv0210 at gmail.com)
|
||||
|
||||
:line
|
||||
|
||||
xmovie tool :h4,link(xmovie)
|
||||
|
||||
The xmovie tool is an X-based visualization package that can read
|
||||
LAMMPS dump files and animate them. It is in its own sub-directory
|
||||
with the tools directory. You may need to modify its Makefile so that
|
||||
it can find the appropriate X libraries to link against.
|
||||
|
||||
The syntax for running xmovie is
|
||||
|
||||
xmovie \[options\] dump.file1 dump.file2 ... :pre
|
||||
|
||||
If you just type "xmovie" you will see a list of options. Note that
|
||||
by default, LAMMPS dump files are in scaled coordinates, so you
|
||||
typically need to use the -scale option with xmovie. When xmovie runs
|
||||
it opens a visualization window and a control window. The control
|
||||
options are straightforward to use.
|
||||
|
||||
Xmovie was mostly written by Mike Uttormark (U Wisconsin) while he
|
||||
spent a summer at Sandia. It displays 2d projections of a 3d domain.
|
||||
While simple in design, it is an amazingly fast program that can
|
||||
render large numbers of atoms very quickly. It's a useful tool for
|
||||
debugging LAMMPS input and output and making sure your simulation is
|
||||
doing what you think it should. The animations on the Examples page
|
||||
of the "LAMMPS WWW site"_lws were created with xmovie.
|
||||
|
||||
I've lost contact with Mike, so I hope he's comfortable with us
|
||||
distributing his great tool!
|
||||
@ -1,372 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>5.USER-CUDA package — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>5.USER-CUDA package</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<p><a class="reference internal" href="Section_accelerate.html"><em>Return to Section accelerate overview</em></a></p>
|
||||
<div class="section" id="user-cuda-package">
|
||||
<h1>5.USER-CUDA package<a class="headerlink" href="#user-cuda-package" title="Permalink to this headline">¶</a></h1>
|
||||
<p>The USER-CUDA package was developed by Christian Trott (Sandia) while
|
||||
at U Technology Ilmenau in Germany. It provides NVIDIA GPU versions
|
||||
of many pair styles, many fixes, a few computes, and for long-range
|
||||
Coulombics via the PPPM command. It has the following general
|
||||
features:</p>
|
||||
<ul class="simple">
|
||||
<li>The package is designed to allow an entire LAMMPS calculation, for
|
||||
many timesteps, to run entirely on the GPU (except for inter-processor
|
||||
MPI communication), so that atom-based data (e.g. coordinates, forces)
|
||||
do not have to move back-and-forth between the CPU and GPU.</li>
|
||||
<li>The speed-up advantage of this approach is typically better when the
|
||||
number of atoms per GPU is large</li>
|
||||
<li>Data will stay on the GPU until a timestep where a non-USER-CUDA fix
|
||||
or compute is invoked. Whenever a non-GPU operation occurs (fix,
|
||||
compute, output), data automatically moves back to the CPU as needed.
|
||||
This may incur a performance penalty, but should otherwise work
|
||||
transparently.</li>
|
||||
<li>Neighbor lists are constructed on the GPU.</li>
|
||||
<li>The package only supports use of a single MPI task, running on a
|
||||
single CPU (core), assigned to each GPU.</li>
|
||||
</ul>
|
||||
<p>Here is a quick overview of how to use the USER-CUDA package:</p>
|
||||
<ul class="simple">
|
||||
<li>build the library in lib/cuda for your GPU hardware with desired precision</li>
|
||||
<li>include the USER-CUDA package and build LAMMPS</li>
|
||||
<li>use the mpirun command to specify 1 MPI task per GPU (on each node)</li>
|
||||
<li>enable the USER-CUDA package via the “-c on” command-line switch</li>
|
||||
<li>specify the # of GPUs per node</li>
|
||||
<li>use USER-CUDA styles in your input script</li>
|
||||
</ul>
|
||||
<p>The latter two steps can be done using the “-pk cuda” and “-sf cuda”
|
||||
<a class="reference internal" href="Section_start.html#start-7"><span>command-line switches</span></a> respectively. Or
|
||||
the effect of the “-pk” or “-sf” switches can be duplicated by adding
|
||||
the <a class="reference internal" href="package.html"><em>package cuda</em></a> or <a class="reference internal" href="suffix.html"><em>suffix cuda</em></a> commands
|
||||
respectively to your input script.</p>
|
||||
<p><strong>Required hardware/software:</strong></p>
|
||||
<p>To use this package, you need to have one or more NVIDIA GPUs and
|
||||
install the NVIDIA Cuda software on your system:</p>
|
||||
<p>Your NVIDIA GPU needs to support Compute Capability 1.3. This list may
|
||||
help you to find out the Compute Capability of your card:</p>
|
||||
<p><a class="reference external" href="http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units">http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units</a></p>
|
||||
<p>Install the Nvidia Cuda Toolkit (version 3.2 or higher) and the
|
||||
corresponding GPU drivers. The Nvidia Cuda SDK is not required, but
|
||||
we recommend it also be installed. You can then make sure its sample
|
||||
projects can be compiled without problems.</p>
|
||||
<p><strong>Building LAMMPS with the USER-CUDA package:</strong></p>
|
||||
<p>This requires two steps (a,b): build the USER-CUDA library, then build
|
||||
LAMMPS with the USER-CUDA package.</p>
|
||||
<p>You can do both these steps in one line, using the src/Make.py script,
|
||||
described in <a class="reference internal" href="Section_start.html#start-4"><span>Section 2.4</span></a> of the manual.
|
||||
Type “Make.py -h” for help. If run from the src directory, this
|
||||
command will create src/lmp_cuda using src/MAKE/Makefile.mpi as the
|
||||
starting Makefile.machine:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>Make.py -p cuda -cuda mode=single arch=20 -o cuda -a lib-cuda file mpi
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Or you can follow these two (a,b) steps:</p>
|
||||
<ol class="loweralpha simple">
|
||||
<li>Build the USER-CUDA library</li>
|
||||
</ol>
|
||||
<p>The USER-CUDA library is in lammps/lib/cuda. If your <em>CUDA</em> toolkit
|
||||
is not installed in the default system directoy <em>/usr/local/cuda</em> edit
|
||||
the file <em>lib/cuda/Makefile.common</em> accordingly.</p>
|
||||
<p>To build the library with the settings in lib/cuda/Makefile.default,
|
||||
simply type:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre><span class="n">make</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>To set options when the library is built, type “make OPTIONS”, where
|
||||
<em>OPTIONS</em> are one or more of the following. The settings will be
|
||||
written to the <em>lib/cuda/Makefile.defaults</em> before the build.</p>
|
||||
<pre class="literal-block">
|
||||
<em>precision=N</em> to set the precision level
|
||||
N = 1 for single precision (default)
|
||||
N = 2 for double precision
|
||||
N = 3 for positions in double precision
|
||||
N = 4 for positions and velocities in double precision
|
||||
<em>arch=M</em> to set GPU compute capability
|
||||
M = 35 for Kepler GPUs
|
||||
M = 20 for CC2.0 (GF100/110, e.g. C2050,GTX580,GTX470) (default)
|
||||
M = 21 for CC2.1 (GF104/114, e.g. GTX560, GTX460, GTX450)
|
||||
M = 13 for CC1.3 (GF200, e.g. C1060, GTX285)
|
||||
<em>prec_timer=0/1</em> to use hi-precision timers
|
||||
0 = do not use them (default)
|
||||
1 = use them
|
||||
this is usually only useful for Mac machines
|
||||
<em>dbg=0/1</em> to activate debug mode
|
||||
0 = no debug mode (default)
|
||||
1 = yes debug mode
|
||||
this is only useful for developers
|
||||
<em>cufft=1</em> for use of the CUDA FFT library
|
||||
0 = no CUFFT support (default)
|
||||
in the future other CUDA-enabled FFT libraries might be supported
|
||||
</pre>
|
||||
<p>If the build is successful, it will produce the files liblammpscuda.a and
|
||||
Makefile.lammps.</p>
|
||||
<p>Note that if you change any of the options (like precision), you need
|
||||
to re-build the entire library. Do a “make clean” first, followed by
|
||||
“make”.</p>
|
||||
<ol class="loweralpha simple" start="2">
|
||||
<li>Build LAMMPS with the USER-CUDA package</li>
|
||||
</ol>
|
||||
<div class="highlight-python"><div class="highlight"><pre>cd lammps/src
|
||||
make yes-user-cuda
|
||||
make machine
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>No additional compile/link flags are needed in Makefile.machine.</p>
|
||||
<p>Note that if you change the USER-CUDA library precision (discussed
|
||||
above) and rebuild the USER-CUDA library, then you also need to
|
||||
re-install the USER-CUDA package and re-build LAMMPS, so that all
|
||||
affected files are re-compiled and linked to the new USER-CUDA
|
||||
library.</p>
|
||||
<p><strong>Run with the USER-CUDA package from the command line:</strong></p>
|
||||
<p>The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.</p>
|
||||
<p>When using the USER-CUDA package, you must use exactly one MPI task
|
||||
per physical GPU.</p>
|
||||
<p>You must use the “-c on” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> to enable the USER-CUDA package.
|
||||
The “-c on” switch also issues a default <a class="reference internal" href="package.html"><em>package cuda 1</em></a>
|
||||
command which sets various USER-CUDA options to default values, as
|
||||
discussed on the <a class="reference internal" href="package.html"><em>package</em></a> command doc page.</p>
|
||||
<p>Use the “-sf cuda” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>,
|
||||
which will automatically append “cuda” to styles that support it. Use
|
||||
the “-pk cuda Ng” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> to
|
||||
set Ng = # of GPUs per node to a different value than the default set
|
||||
by the “-c on” switch (1 GPU) or change other <a class="reference internal" href="package.html"><em>package cuda</em></a> options.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>lmp_machine -c on -sf cuda -pk cuda 1 -in in.script # 1 MPI task uses 1 GPU
|
||||
mpirun -np 2 lmp_machine -c on -sf cuda -pk cuda 2 -in in.script # 2 MPI tasks use 2 GPUs on a single 16-core (or whatever) node
|
||||
mpirun -np 24 -ppn 2 lmp_machine -c on -sf cuda -pk cuda 2 -in in.script # ditto on 12 16-core nodes
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The syntax for the “-pk” switch is the same as same as the “package
|
||||
cuda” command. See the <a class="reference internal" href="package.html"><em>package</em></a> command doc page for
|
||||
details, including the default values used for all its options if it
|
||||
is not specified.</p>
|
||||
<p>Note that the default for the <a class="reference internal" href="package.html"><em>package cuda</em></a> command is
|
||||
to set the Newton flag to “off” for both pairwise and bonded
|
||||
interactions. This typically gives fastest performance. If the
|
||||
<a class="reference internal" href="newton.html"><em>newton</em></a> command is used in the input script, it can
|
||||
override these defaults.</p>
|
||||
<p><strong>Or run with the USER-CUDA package by editing an input script:</strong></p>
|
||||
<p>The discussion above for the mpirun/mpiexec command and the requirement
|
||||
of one MPI task per GPU is the same.</p>
|
||||
<p>You must still use the “-c on” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> to enable the USER-CUDA package.</p>
|
||||
<p>Use the <a class="reference internal" href="suffix.html"><em>suffix cuda</em></a> command, or you can explicitly add a
|
||||
“cuda” suffix to individual styles in your input script, e.g.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>pair_style lj/cut/cuda 2.5
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>You only need to use the <a class="reference internal" href="package.html"><em>package cuda</em></a> command if you
|
||||
wish to change any of its option defaults, including the number of
|
||||
GPUs/node (default = 1), as set by the “-c on” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>.</p>
|
||||
<p><strong>Speed-ups to expect:</strong></p>
|
||||
<p>The performance of a GPU versus a multi-core CPU is a function of your
|
||||
hardware, which pair style is used, the number of atoms/GPU, and the
|
||||
precision used on the GPU (double, single, mixed).</p>
|
||||
<p>See the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the
|
||||
LAMMPS web site for performance of the USER-CUDA package on different
|
||||
hardware.</p>
|
||||
<p><strong>Guidelines for best performance:</strong></p>
|
||||
<ul class="simple">
|
||||
<li>The USER-CUDA package offers more speed-up relative to CPU performance
|
||||
when the number of atoms per GPU is large, e.g. on the order of tens
|
||||
or hundreds of 1000s.</li>
|
||||
<li>As noted above, this package will continue to run a simulation
|
||||
entirely on the GPU(s) (except for inter-processor MPI communication),
|
||||
for multiple timesteps, until a CPU calculation is required, either by
|
||||
a fix or compute that is non-GPU-ized, or until output is performed
|
||||
(thermo or dump snapshot or restart file). The less often this
|
||||
occurs, the faster your simulation will run.</li>
|
||||
</ul>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>None.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,223 +0,0 @@
|
||||
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
"Return to Section accelerate overview"_Section_accelerate.html
|
||||
|
||||
5.3.1 USER-CUDA package :h4
|
||||
|
||||
The USER-CUDA package was developed by Christian Trott (Sandia) while
|
||||
at U Technology Ilmenau in Germany. It provides NVIDIA GPU versions
|
||||
of many pair styles, many fixes, a few computes, and for long-range
|
||||
Coulombics via the PPPM command. It has the following general
|
||||
features:
|
||||
|
||||
The package is designed to allow an entire LAMMPS calculation, for
|
||||
many timesteps, to run entirely on the GPU (except for inter-processor
|
||||
MPI communication), so that atom-based data (e.g. coordinates, forces)
|
||||
do not have to move back-and-forth between the CPU and GPU. :ulb,l
|
||||
|
||||
The speed-up advantage of this approach is typically better when the
|
||||
number of atoms per GPU is large :l
|
||||
|
||||
Data will stay on the GPU until a timestep where a non-USER-CUDA fix
|
||||
or compute is invoked. Whenever a non-GPU operation occurs (fix,
|
||||
compute, output), data automatically moves back to the CPU as needed.
|
||||
This may incur a performance penalty, but should otherwise work
|
||||
transparently. :l
|
||||
|
||||
Neighbor lists are constructed on the GPU. :l
|
||||
|
||||
The package only supports use of a single MPI task, running on a
|
||||
single CPU (core), assigned to each GPU. :l,ule
|
||||
|
||||
Here is a quick overview of how to use the USER-CUDA package:
|
||||
|
||||
build the library in lib/cuda for your GPU hardware with desired precision
|
||||
include the USER-CUDA package and build LAMMPS
|
||||
use the mpirun command to specify 1 MPI task per GPU (on each node)
|
||||
enable the USER-CUDA package via the "-c on" command-line switch
|
||||
specify the # of GPUs per node
|
||||
use USER-CUDA styles in your input script :ul
|
||||
|
||||
The latter two steps can be done using the "-pk cuda" and "-sf cuda"
|
||||
"command-line switches"_Section_start.html#start_7 respectively. Or
|
||||
the effect of the "-pk" or "-sf" switches can be duplicated by adding
|
||||
the "package cuda"_package.html or "suffix cuda"_suffix.html commands
|
||||
respectively to your input script.
|
||||
|
||||
[Required hardware/software:]
|
||||
|
||||
To use this package, you need to have one or more NVIDIA GPUs and
|
||||
install the NVIDIA Cuda software on your system:
|
||||
|
||||
Your NVIDIA GPU needs to support Compute Capability 1.3. This list may
|
||||
help you to find out the Compute Capability of your card:
|
||||
|
||||
http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units
|
||||
|
||||
Install the Nvidia Cuda Toolkit (version 3.2 or higher) and the
|
||||
corresponding GPU drivers. The Nvidia Cuda SDK is not required, but
|
||||
we recommend it also be installed. You can then make sure its sample
|
||||
projects can be compiled without problems.
|
||||
|
||||
[Building LAMMPS with the USER-CUDA package:]
|
||||
|
||||
This requires two steps (a,b): build the USER-CUDA library, then build
|
||||
LAMMPS with the USER-CUDA package.
|
||||
|
||||
You can do both these steps in one line, using the src/Make.py script,
|
||||
described in "Section 2.4"_Section_start.html#start_4 of the manual.
|
||||
Type "Make.py -h" for help. If run from the src directory, this
|
||||
command will create src/lmp_cuda using src/MAKE/Makefile.mpi as the
|
||||
starting Makefile.machine:
|
||||
|
||||
Make.py -p cuda -cuda mode=single arch=20 -o cuda -a lib-cuda file mpi :pre
|
||||
|
||||
Or you can follow these two (a,b) steps:
|
||||
|
||||
(a) Build the USER-CUDA library
|
||||
|
||||
The USER-CUDA library is in lammps/lib/cuda. If your {CUDA} toolkit
|
||||
is not installed in the default system directoy {/usr/local/cuda} edit
|
||||
the file {lib/cuda/Makefile.common} accordingly.
|
||||
|
||||
To build the library with the settings in lib/cuda/Makefile.default,
|
||||
simply type:
|
||||
|
||||
make :pre
|
||||
|
||||
To set options when the library is built, type "make OPTIONS", where
|
||||
{OPTIONS} are one or more of the following. The settings will be
|
||||
written to the {lib/cuda/Makefile.defaults} before the build.
|
||||
|
||||
{precision=N} to set the precision level
|
||||
N = 1 for single precision (default)
|
||||
N = 2 for double precision
|
||||
N = 3 for positions in double precision
|
||||
N = 4 for positions and velocities in double precision
|
||||
{arch=M} to set GPU compute capability
|
||||
M = 35 for Kepler GPUs
|
||||
M = 20 for CC2.0 (GF100/110, e.g. C2050,GTX580,GTX470) (default)
|
||||
M = 21 for CC2.1 (GF104/114, e.g. GTX560, GTX460, GTX450)
|
||||
M = 13 for CC1.3 (GF200, e.g. C1060, GTX285)
|
||||
{prec_timer=0/1} to use hi-precision timers
|
||||
0 = do not use them (default)
|
||||
1 = use them
|
||||
this is usually only useful for Mac machines
|
||||
{dbg=0/1} to activate debug mode
|
||||
0 = no debug mode (default)
|
||||
1 = yes debug mode
|
||||
this is only useful for developers
|
||||
{cufft=1} for use of the CUDA FFT library
|
||||
0 = no CUFFT support (default)
|
||||
in the future other CUDA-enabled FFT libraries might be supported :pre
|
||||
|
||||
If the build is successful, it will produce the files liblammpscuda.a and
|
||||
Makefile.lammps.
|
||||
|
||||
Note that if you change any of the options (like precision), you need
|
||||
to re-build the entire library. Do a "make clean" first, followed by
|
||||
"make".
|
||||
|
||||
(b) Build LAMMPS with the USER-CUDA package
|
||||
|
||||
cd lammps/src
|
||||
make yes-user-cuda
|
||||
make machine :pre
|
||||
|
||||
No additional compile/link flags are needed in Makefile.machine.
|
||||
|
||||
Note that if you change the USER-CUDA library precision (discussed
|
||||
above) and rebuild the USER-CUDA library, then you also need to
|
||||
re-install the USER-CUDA package and re-build LAMMPS, so that all
|
||||
affected files are re-compiled and linked to the new USER-CUDA
|
||||
library.
|
||||
|
||||
[Run with the USER-CUDA package from the command line:]
|
||||
|
||||
The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
|
||||
|
||||
When using the USER-CUDA package, you must use exactly one MPI task
|
||||
per physical GPU.
|
||||
|
||||
You must use the "-c on" "command-line
|
||||
switch"_Section_start.html#start_7 to enable the USER-CUDA package.
|
||||
The "-c on" switch also issues a default "package cuda 1"_package.html
|
||||
command which sets various USER-CUDA options to default values, as
|
||||
discussed on the "package"_package.html command doc page.
|
||||
|
||||
Use the "-sf cuda" "command-line switch"_Section_start.html#start_7,
|
||||
which will automatically append "cuda" to styles that support it. Use
|
||||
the "-pk cuda Ng" "command-line switch"_Section_start.html#start_7 to
|
||||
set Ng = # of GPUs per node to a different value than the default set
|
||||
by the "-c on" switch (1 GPU) or change other "package
|
||||
cuda"_package.html options.
|
||||
|
||||
lmp_machine -c on -sf cuda -pk cuda 1 -in in.script # 1 MPI task uses 1 GPU
|
||||
mpirun -np 2 lmp_machine -c on -sf cuda -pk cuda 2 -in in.script # 2 MPI tasks use 2 GPUs on a single 16-core (or whatever) node
|
||||
mpirun -np 24 -ppn 2 lmp_machine -c on -sf cuda -pk cuda 2 -in in.script # ditto on 12 16-core nodes :pre
|
||||
|
||||
The syntax for the "-pk" switch is the same as same as the "package
|
||||
cuda" command. See the "package"_package.html command doc page for
|
||||
details, including the default values used for all its options if it
|
||||
is not specified.
|
||||
|
||||
Note that the default for the "package cuda"_package.html command is
|
||||
to set the Newton flag to "off" for both pairwise and bonded
|
||||
interactions. This typically gives fastest performance. If the
|
||||
"newton"_newton.html command is used in the input script, it can
|
||||
override these defaults.
|
||||
|
||||
[Or run with the USER-CUDA package by editing an input script:]
|
||||
|
||||
The discussion above for the mpirun/mpiexec command and the requirement
|
||||
of one MPI task per GPU is the same.
|
||||
|
||||
You must still use the "-c on" "command-line
|
||||
switch"_Section_start.html#start_7 to enable the USER-CUDA package.
|
||||
|
||||
Use the "suffix cuda"_suffix.html command, or you can explicitly add a
|
||||
"cuda" suffix to individual styles in your input script, e.g.
|
||||
|
||||
pair_style lj/cut/cuda 2.5 :pre
|
||||
|
||||
You only need to use the "package cuda"_package.html command if you
|
||||
wish to change any of its option defaults, including the number of
|
||||
GPUs/node (default = 1), as set by the "-c on" "command-line
|
||||
switch"_Section_start.html#start_7.
|
||||
|
||||
[Speed-ups to expect:]
|
||||
|
||||
The performance of a GPU versus a multi-core CPU is a function of your
|
||||
hardware, which pair style is used, the number of atoms/GPU, and the
|
||||
precision used on the GPU (double, single, mixed).
|
||||
|
||||
See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
|
||||
LAMMPS web site for performance of the USER-CUDA package on different
|
||||
hardware.
|
||||
|
||||
[Guidelines for best performance:]
|
||||
|
||||
The USER-CUDA package offers more speed-up relative to CPU performance
|
||||
when the number of atoms per GPU is large, e.g. on the order of tens
|
||||
or hundreds of 1000s. :ulb,l
|
||||
|
||||
As noted above, this package will continue to run a simulation
|
||||
entirely on the GPU(s) (except for inter-processor MPI communication),
|
||||
for multiple timesteps, until a CPU calculation is required, either by
|
||||
a fix or compute that is non-GPU-ized, or until output is performed
|
||||
(thermo or dump snapshot or restart file). The less often this
|
||||
occurs, the faster your simulation will run. :l,ule
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
None.
|
||||
@ -1,401 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>5.GPU package — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>5.GPU package</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<p><a class="reference internal" href="Section_accelerate.html"><em>Return to Section accelerate overview</em></a></p>
|
||||
<div class="section" id="gpu-package">
|
||||
<h1>5.GPU package<a class="headerlink" href="#gpu-package" title="Permalink to this headline">¶</a></h1>
|
||||
<p>The GPU package was developed by Mike Brown at ORNL and his
|
||||
collaborators, particularly Trung Nguyen (ORNL). It provides GPU
|
||||
versions of many pair styles, including the 3-body Stillinger-Weber
|
||||
pair style, and for <a class="reference internal" href="kspace_style.html"><em>kspace_style pppm</em></a> for
|
||||
long-range Coulombics. It has the following general features:</p>
|
||||
<ul class="simple">
|
||||
<li>It is designed to exploit common GPU hardware configurations where one
|
||||
or more GPUs are coupled to many cores of one or more multi-core CPUs,
|
||||
e.g. within a node of a parallel machine.</li>
|
||||
<li>Atom-based data (e.g. coordinates, forces) moves back-and-forth
|
||||
between the CPU(s) and GPU every timestep.</li>
|
||||
<li>Neighbor lists can be built on the CPU or on the GPU</li>
|
||||
<li>The charge assignement and force interpolation portions of PPPM can be
|
||||
run on the GPU. The FFT portion, which requires MPI communication
|
||||
between processors, runs on the CPU.</li>
|
||||
<li>Asynchronous force computations can be performed simultaneously on the
|
||||
CPU(s) and GPU.</li>
|
||||
<li>It allows for GPU computations to be performed in single or double
|
||||
precision, or in mixed-mode precision, where pairwise forces are
|
||||
computed in single precision, but accumulated into double-precision
|
||||
force vectors.</li>
|
||||
<li>LAMMPS-specific code is in the GPU package. It makes calls to a
|
||||
generic GPU library in the lib/gpu directory. This library provides
|
||||
NVIDIA support as well as more general OpenCL support, so that the
|
||||
same functionality can eventually be supported on a variety of GPU
|
||||
hardware.</li>
|
||||
</ul>
|
||||
<p>Here is a quick overview of how to use the GPU package:</p>
|
||||
<ul class="simple">
|
||||
<li>build the library in lib/gpu for your GPU hardware wity desired precision</li>
|
||||
<li>include the GPU package and build LAMMPS</li>
|
||||
<li>use the mpirun command to set the number of MPI tasks/node which determines the number of MPI tasks/GPU</li>
|
||||
<li>specify the # of GPUs per node</li>
|
||||
<li>use GPU styles in your input script</li>
|
||||
</ul>
|
||||
<p>The latter two steps can be done using the “-pk gpu” and “-sf gpu”
|
||||
<a class="reference internal" href="Section_start.html#start-7"><span>command-line switches</span></a> respectively. Or
|
||||
the effect of the “-pk” or “-sf” switches can be duplicated by adding
|
||||
the <a class="reference internal" href="package.html"><em>package gpu</em></a> or <a class="reference internal" href="suffix.html"><em>suffix gpu</em></a> commands
|
||||
respectively to your input script.</p>
|
||||
<p><strong>Required hardware/software:</strong></p>
|
||||
<p>To use this package, you currently need to have an NVIDIA GPU and
|
||||
install the NVIDIA Cuda software on your system:</p>
|
||||
<ul class="simple">
|
||||
<li>Check if you have an NVIDIA GPU: cat /proc/driver/nvidia/gpus/0/information</li>
|
||||
<li>Go to <a class="reference external" href="http://www.nvidia.com/object/cuda_get.html">http://www.nvidia.com/object/cuda_get.html</a></li>
|
||||
<li>Install a driver and toolkit appropriate for your system (SDK is not necessary)</li>
|
||||
<li>Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) to list supported devices and properties</li>
|
||||
</ul>
|
||||
<p><strong>Building LAMMPS with the GPU package:</strong></p>
|
||||
<p>This requires two steps (a,b): build the GPU library, then build
|
||||
LAMMPS with the GPU package.</p>
|
||||
<p>You can do both these steps in one line, using the src/Make.py script,
|
||||
described in <a class="reference internal" href="Section_start.html#start-4"><span>Section 2.4</span></a> of the manual.
|
||||
Type “Make.py -h” for help. If run from the src directory, this
|
||||
command will create src/lmp_gpu using src/MAKE/Makefile.mpi as the
|
||||
starting Makefile.machine:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>Make.py -p gpu -gpu mode=single arch=31 -o gpu -a lib-gpu file mpi
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Or you can follow these two (a,b) steps:</p>
|
||||
<ol class="loweralpha simple">
|
||||
<li>Build the GPU library</li>
|
||||
</ol>
|
||||
<p>The GPU library is in lammps/lib/gpu. Select a Makefile.machine (in
|
||||
lib/gpu) appropriate for your system. You should pay special
|
||||
attention to 3 settings in this makefile.</p>
|
||||
<ul class="simple">
|
||||
<li>CUDA_HOME = needs to be where NVIDIA Cuda software is installed on your system</li>
|
||||
<li>CUDA_ARCH = needs to be appropriate to your GPUs</li>
|
||||
<li>CUDA_PREC = precision (double, mixed, single) you desire</li>
|
||||
</ul>
|
||||
<p>See lib/gpu/Makefile.linux.double for examples of the ARCH settings
|
||||
for different GPU choices, e.g. Fermi vs Kepler. It also lists the
|
||||
possible precision settings:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre><span class="n">CUDA_PREC</span> <span class="o">=</span> <span class="o">-</span><span class="n">D_SINGLE_SINGLE</span> <span class="c"># single precision for all calculations</span>
|
||||
<span class="n">CUDA_PREC</span> <span class="o">=</span> <span class="o">-</span><span class="n">D_DOUBLE_DOUBLE</span> <span class="c"># double precision for all calculations</span>
|
||||
<span class="n">CUDA_PREC</span> <span class="o">=</span> <span class="o">-</span><span class="n">D_SINGLE_DOUBLE</span> <span class="c"># accumulation of forces, etc, in double</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The last setting is the mixed mode referred to above. Note that your
|
||||
GPU must support double precision to use either the 2nd or 3rd of
|
||||
these settings.</p>
|
||||
<p>To build the library, type:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>make -f Makefile.machine
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>If successful, it will produce the files libgpu.a and Makefile.lammps.</p>
|
||||
<p>The latter file has 3 settings that need to be appropriate for the
|
||||
paths and settings for the CUDA system software on your machine.
|
||||
Makefile.lammps is a copy of the file specified by the EXTRAMAKE
|
||||
setting in Makefile.machine. You can change EXTRAMAKE or create your
|
||||
own Makefile.lammps.machine if needed.</p>
|
||||
<p>Note that to change the precision of the GPU library, you need to
|
||||
re-build the entire library. Do a “clean” first, e.g. “make -f
|
||||
Makefile.linux clean”, followed by the make command above.</p>
|
||||
<ol class="loweralpha simple" start="2">
|
||||
<li>Build LAMMPS with the GPU package</li>
|
||||
</ol>
|
||||
<div class="highlight-python"><div class="highlight"><pre>cd lammps/src
|
||||
make yes-gpu
|
||||
make machine
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>No additional compile/link flags are needed in Makefile.machine.</p>
|
||||
<p>Note that if you change the GPU library precision (discussed above)
|
||||
and rebuild the GPU library, then you also need to re-install the GPU
|
||||
package and re-build LAMMPS, so that all affected files are
|
||||
re-compiled and linked to the new GPU library.</p>
|
||||
<p><strong>Run with the GPU package from the command line:</strong></p>
|
||||
<p>The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.</p>
|
||||
<p>When using the GPU package, you cannot assign more than one GPU to a
|
||||
single MPI task. However multiple MPI tasks can share the same GPU,
|
||||
and in many cases it will be more efficient to run this way. Likewise
|
||||
it may be more efficient to use less MPI tasks/node than the available
|
||||
# of CPU cores. Assignment of multiple MPI tasks to a GPU will happen
|
||||
automatically if you create more MPI tasks/node than there are
|
||||
GPUs/mode. E.g. with 8 MPI tasks/node and 2 GPUs, each GPU will be
|
||||
shared by 4 MPI tasks.</p>
|
||||
<p>Use the “-sf gpu” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>,
|
||||
which will automatically append “gpu” to styles that support it. Use
|
||||
the “-pk gpu Ng” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> to
|
||||
set Ng = # of GPUs/node to use.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>lmp_machine -sf gpu -pk gpu 1 -in in.script # 1 MPI task uses 1 GPU
|
||||
mpirun -np 12 lmp_machine -sf gpu -pk gpu 2 -in in.script # 12 MPI tasks share 2 GPUs on a single 16-core (or whatever) node
|
||||
mpirun -np 48 -ppn 12 lmp_machine -sf gpu -pk gpu 2 -in in.script # ditto on 4 16-core nodes
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Note that if the “-sf gpu” switch is used, it also issues a default
|
||||
<a class="reference internal" href="package.html"><em>package gpu 1</em></a> command, which sets the number of
|
||||
GPUs/node to 1.</p>
|
||||
<p>Using the “-pk” switch explicitly allows for setting of the number of
|
||||
GPUs/node to use and additional options. Its syntax is the same as
|
||||
same as the “package gpu” command. See the <a class="reference internal" href="package.html"><em>package</em></a>
|
||||
command doc page for details, including the default values used for
|
||||
all its options if it is not specified.</p>
|
||||
<p>Note that the default for the <a class="reference internal" href="package.html"><em>package gpu</em></a> command is to
|
||||
set the Newton flag to “off” pairwise interactions. It does not
|
||||
affect the setting for bonded interactions (LAMMPS default is “on”).
|
||||
The “off” setting for pairwise interaction is currently required for
|
||||
GPU package pair styles.</p>
|
||||
<p><strong>Or run with the GPU package by editing an input script:</strong></p>
|
||||
<p>The discussion above for the mpirun/mpiexec command, MPI tasks/node,
|
||||
and use of multiple MPI tasks/GPU is the same.</p>
|
||||
<p>Use the <a class="reference internal" href="suffix.html"><em>suffix gpu</em></a> command, or you can explicitly add an
|
||||
“gpu” suffix to individual styles in your input script, e.g.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>pair_style lj/cut/gpu 2.5
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>You must also use the <a class="reference internal" href="package.html"><em>package gpu</em></a> command to enable the
|
||||
GPU package, unless the “-sf gpu” or “-pk gpu” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switches</span></a> were used. It specifies the
|
||||
number of GPUs/node to use, as well as other options.</p>
|
||||
<p><strong>Speed-ups to expect:</strong></p>
|
||||
<p>The performance of a GPU versus a multi-core CPU is a function of your
|
||||
hardware, which pair style is used, the number of atoms/GPU, and the
|
||||
precision used on the GPU (double, single, mixed).</p>
|
||||
<p>See the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the
|
||||
LAMMPS web site for performance of the GPU package on various
|
||||
hardware, including the Titan HPC platform at ORNL.</p>
|
||||
<p>You should also experiment with how many MPI tasks per GPU to use to
|
||||
give the best performance for your problem and machine. This is also
|
||||
a function of the problem size and the pair style being using.
|
||||
Likewise, you should experiment with the precision setting for the GPU
|
||||
library to see if single or mixed precision will give accurate
|
||||
results, since they will typically be faster.</p>
|
||||
<p><strong>Guidelines for best performance:</strong></p>
|
||||
<ul class="simple">
|
||||
<li>Using multiple MPI tasks per GPU will often give the best performance,
|
||||
as allowed my most multi-core CPU/GPU configurations.</li>
|
||||
<li>If the number of particles per MPI task is small (e.g. 100s of
|
||||
particles), it can be more efficient to run with fewer MPI tasks per
|
||||
GPU, even if you do not use all the cores on the compute node.</li>
|
||||
<li>The <a class="reference internal" href="package.html"><em>package gpu</em></a> command has several options for tuning
|
||||
performance. Neighbor lists can be built on the GPU or CPU. Force
|
||||
calculations can be dynamically balanced across the CPU cores and
|
||||
GPUs. GPU-specific settings can be made which can be optimized
|
||||
for different hardware. See the <a class="reference internal" href="package.html"><em>packakge</em></a> command
|
||||
doc page for details.</li>
|
||||
<li>As described by the <a class="reference internal" href="package.html"><em>package gpu</em></a> command, GPU
|
||||
accelerated pair styles can perform computations asynchronously with
|
||||
CPU computations. The “Pair” time reported by LAMMPS will be the
|
||||
maximum of the time required to complete the CPU pair style
|
||||
computations and the time required to complete the GPU pair style
|
||||
computations. Any time spent for GPU-enabled pair styles for
|
||||
computations that run simultaneously with <a class="reference internal" href="bond_style.html"><em>bond</em></a>,
|
||||
<a class="reference internal" href="angle_style.html"><em>angle</em></a>, <a class="reference internal" href="dihedral_style.html"><em>dihedral</em></a>,
|
||||
<a class="reference internal" href="improper_style.html"><em>improper</em></a>, and <a class="reference internal" href="kspace_style.html"><em>long-range</em></a>
|
||||
calculations will not be included in the “Pair” time.</li>
|
||||
<li>When the <em>mode</em> setting for the package gpu command is force/neigh,
|
||||
the time for neighbor list calculations on the GPU will be added into
|
||||
the “Pair” time, not the “Neigh” time. An additional breakdown of the
|
||||
times required for various tasks on the GPU (data copy, neighbor
|
||||
calculations, force computations, etc) are output only with the LAMMPS
|
||||
screen output (not in the log file) at the end of each run. These
|
||||
timings represent total time spent on the GPU for each routine,
|
||||
regardless of asynchronous CPU calculations.</li>
|
||||
<li>The output section “GPU Time Info (average)” reports “Max Mem / Proc”.
|
||||
This is the maximum memory used at one time on the GPU for data
|
||||
storage by a single MPI process.</li>
|
||||
</ul>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>None.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,252 +0,0 @@
|
||||
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
"Return to Section accelerate overview"_Section_accelerate.html
|
||||
|
||||
5.3.2 GPU package :h4
|
||||
|
||||
The GPU package was developed by Mike Brown at ORNL and his
|
||||
collaborators, particularly Trung Nguyen (ORNL). It provides GPU
|
||||
versions of many pair styles, including the 3-body Stillinger-Weber
|
||||
pair style, and for "kspace_style pppm"_kspace_style.html for
|
||||
long-range Coulombics. It has the following general features:
|
||||
|
||||
It is designed to exploit common GPU hardware configurations where one
|
||||
or more GPUs are coupled to many cores of one or more multi-core CPUs,
|
||||
e.g. within a node of a parallel machine. :ulb,l
|
||||
|
||||
Atom-based data (e.g. coordinates, forces) moves back-and-forth
|
||||
between the CPU(s) and GPU every timestep. :l
|
||||
|
||||
Neighbor lists can be built on the CPU or on the GPU :l
|
||||
|
||||
The charge assignement and force interpolation portions of PPPM can be
|
||||
run on the GPU. The FFT portion, which requires MPI communication
|
||||
between processors, runs on the CPU. :l
|
||||
|
||||
Asynchronous force computations can be performed simultaneously on the
|
||||
CPU(s) and GPU. :l
|
||||
|
||||
It allows for GPU computations to be performed in single or double
|
||||
precision, or in mixed-mode precision, where pairwise forces are
|
||||
computed in single precision, but accumulated into double-precision
|
||||
force vectors. :l
|
||||
|
||||
LAMMPS-specific code is in the GPU package. It makes calls to a
|
||||
generic GPU library in the lib/gpu directory. This library provides
|
||||
NVIDIA support as well as more general OpenCL support, so that the
|
||||
same functionality can eventually be supported on a variety of GPU
|
||||
hardware. :l,ule
|
||||
|
||||
Here is a quick overview of how to use the GPU package:
|
||||
|
||||
build the library in lib/gpu for your GPU hardware wity desired precision
|
||||
include the GPU package and build LAMMPS
|
||||
use the mpirun command to set the number of MPI tasks/node which determines the number of MPI tasks/GPU
|
||||
specify the # of GPUs per node
|
||||
use GPU styles in your input script :ul
|
||||
|
||||
The latter two steps can be done using the "-pk gpu" and "-sf gpu"
|
||||
"command-line switches"_Section_start.html#start_7 respectively. Or
|
||||
the effect of the "-pk" or "-sf" switches can be duplicated by adding
|
||||
the "package gpu"_package.html or "suffix gpu"_suffix.html commands
|
||||
respectively to your input script.
|
||||
|
||||
[Required hardware/software:]
|
||||
|
||||
To use this package, you currently need to have an NVIDIA GPU and
|
||||
install the NVIDIA Cuda software on your system:
|
||||
|
||||
Check if you have an NVIDIA GPU: cat /proc/driver/nvidia/gpus/0/information
|
||||
Go to http://www.nvidia.com/object/cuda_get.html
|
||||
Install a driver and toolkit appropriate for your system (SDK is not necessary)
|
||||
Run lammps/lib/gpu/nvc_get_devices (after building the GPU library, see below) to list supported devices and properties :ul
|
||||
|
||||
[Building LAMMPS with the GPU package:]
|
||||
|
||||
This requires two steps (a,b): build the GPU library, then build
|
||||
LAMMPS with the GPU package.
|
||||
|
||||
You can do both these steps in one line, using the src/Make.py script,
|
||||
described in "Section 2.4"_Section_start.html#start_4 of the manual.
|
||||
Type "Make.py -h" for help. If run from the src directory, this
|
||||
command will create src/lmp_gpu using src/MAKE/Makefile.mpi as the
|
||||
starting Makefile.machine:
|
||||
|
||||
Make.py -p gpu -gpu mode=single arch=31 -o gpu -a lib-gpu file mpi :pre
|
||||
|
||||
Or you can follow these two (a,b) steps:
|
||||
|
||||
(a) Build the GPU library
|
||||
|
||||
The GPU library is in lammps/lib/gpu. Select a Makefile.machine (in
|
||||
lib/gpu) appropriate for your system. You should pay special
|
||||
attention to 3 settings in this makefile.
|
||||
|
||||
CUDA_HOME = needs to be where NVIDIA Cuda software is installed on your system
|
||||
CUDA_ARCH = needs to be appropriate to your GPUs
|
||||
CUDA_PREC = precision (double, mixed, single) you desire :ul
|
||||
|
||||
See lib/gpu/Makefile.linux.double for examples of the ARCH settings
|
||||
for different GPU choices, e.g. Fermi vs Kepler. It also lists the
|
||||
possible precision settings:
|
||||
|
||||
CUDA_PREC = -D_SINGLE_SINGLE # single precision for all calculations
|
||||
CUDA_PREC = -D_DOUBLE_DOUBLE # double precision for all calculations
|
||||
CUDA_PREC = -D_SINGLE_DOUBLE # accumulation of forces, etc, in double :pre
|
||||
|
||||
The last setting is the mixed mode referred to above. Note that your
|
||||
GPU must support double precision to use either the 2nd or 3rd of
|
||||
these settings.
|
||||
|
||||
To build the library, type:
|
||||
|
||||
make -f Makefile.machine :pre
|
||||
|
||||
If successful, it will produce the files libgpu.a and Makefile.lammps.
|
||||
|
||||
The latter file has 3 settings that need to be appropriate for the
|
||||
paths and settings for the CUDA system software on your machine.
|
||||
Makefile.lammps is a copy of the file specified by the EXTRAMAKE
|
||||
setting in Makefile.machine. You can change EXTRAMAKE or create your
|
||||
own Makefile.lammps.machine if needed.
|
||||
|
||||
Note that to change the precision of the GPU library, you need to
|
||||
re-build the entire library. Do a "clean" first, e.g. "make -f
|
||||
Makefile.linux clean", followed by the make command above.
|
||||
|
||||
(b) Build LAMMPS with the GPU package
|
||||
|
||||
cd lammps/src
|
||||
make yes-gpu
|
||||
make machine :pre
|
||||
|
||||
No additional compile/link flags are needed in Makefile.machine.
|
||||
|
||||
Note that if you change the GPU library precision (discussed above)
|
||||
and rebuild the GPU library, then you also need to re-install the GPU
|
||||
package and re-build LAMMPS, so that all affected files are
|
||||
re-compiled and linked to the new GPU library.
|
||||
|
||||
[Run with the GPU package from the command line:]
|
||||
|
||||
The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
|
||||
|
||||
When using the GPU package, you cannot assign more than one GPU to a
|
||||
single MPI task. However multiple MPI tasks can share the same GPU,
|
||||
and in many cases it will be more efficient to run this way. Likewise
|
||||
it may be more efficient to use less MPI tasks/node than the available
|
||||
# of CPU cores. Assignment of multiple MPI tasks to a GPU will happen
|
||||
automatically if you create more MPI tasks/node than there are
|
||||
GPUs/mode. E.g. with 8 MPI tasks/node and 2 GPUs, each GPU will be
|
||||
shared by 4 MPI tasks.
|
||||
|
||||
Use the "-sf gpu" "command-line switch"_Section_start.html#start_7,
|
||||
which will automatically append "gpu" to styles that support it. Use
|
||||
the "-pk gpu Ng" "command-line switch"_Section_start.html#start_7 to
|
||||
set Ng = # of GPUs/node to use.
|
||||
|
||||
lmp_machine -sf gpu -pk gpu 1 -in in.script # 1 MPI task uses 1 GPU
|
||||
mpirun -np 12 lmp_machine -sf gpu -pk gpu 2 -in in.script # 12 MPI tasks share 2 GPUs on a single 16-core (or whatever) node
|
||||
mpirun -np 48 -ppn 12 lmp_machine -sf gpu -pk gpu 2 -in in.script # ditto on 4 16-core nodes :pre
|
||||
|
||||
Note that if the "-sf gpu" switch is used, it also issues a default
|
||||
"package gpu 1"_package.html command, which sets the number of
|
||||
GPUs/node to 1.
|
||||
|
||||
Using the "-pk" switch explicitly allows for setting of the number of
|
||||
GPUs/node to use and additional options. Its syntax is the same as
|
||||
same as the "package gpu" command. See the "package"_package.html
|
||||
command doc page for details, including the default values used for
|
||||
all its options if it is not specified.
|
||||
|
||||
Note that the default for the "package gpu"_package.html command is to
|
||||
set the Newton flag to "off" pairwise interactions. It does not
|
||||
affect the setting for bonded interactions (LAMMPS default is "on").
|
||||
The "off" setting for pairwise interaction is currently required for
|
||||
GPU package pair styles.
|
||||
|
||||
[Or run with the GPU package by editing an input script:]
|
||||
|
||||
The discussion above for the mpirun/mpiexec command, MPI tasks/node,
|
||||
and use of multiple MPI tasks/GPU is the same.
|
||||
|
||||
Use the "suffix gpu"_suffix.html command, or you can explicitly add an
|
||||
"gpu" suffix to individual styles in your input script, e.g.
|
||||
|
||||
pair_style lj/cut/gpu 2.5 :pre
|
||||
|
||||
You must also use the "package gpu"_package.html command to enable the
|
||||
GPU package, unless the "-sf gpu" or "-pk gpu" "command-line
|
||||
switches"_Section_start.html#start_7 were used. It specifies the
|
||||
number of GPUs/node to use, as well as other options.
|
||||
|
||||
[Speed-ups to expect:]
|
||||
|
||||
The performance of a GPU versus a multi-core CPU is a function of your
|
||||
hardware, which pair style is used, the number of atoms/GPU, and the
|
||||
precision used on the GPU (double, single, mixed).
|
||||
|
||||
See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
|
||||
LAMMPS web site for performance of the GPU package on various
|
||||
hardware, including the Titan HPC platform at ORNL.
|
||||
|
||||
You should also experiment with how many MPI tasks per GPU to use to
|
||||
give the best performance for your problem and machine. This is also
|
||||
a function of the problem size and the pair style being using.
|
||||
Likewise, you should experiment with the precision setting for the GPU
|
||||
library to see if single or mixed precision will give accurate
|
||||
results, since they will typically be faster.
|
||||
|
||||
[Guidelines for best performance:]
|
||||
|
||||
Using multiple MPI tasks per GPU will often give the best performance,
|
||||
as allowed my most multi-core CPU/GPU configurations. :ulb,l
|
||||
|
||||
If the number of particles per MPI task is small (e.g. 100s of
|
||||
particles), it can be more efficient to run with fewer MPI tasks per
|
||||
GPU, even if you do not use all the cores on the compute node. :l
|
||||
|
||||
The "package gpu"_package.html command has several options for tuning
|
||||
performance. Neighbor lists can be built on the GPU or CPU. Force
|
||||
calculations can be dynamically balanced across the CPU cores and
|
||||
GPUs. GPU-specific settings can be made which can be optimized
|
||||
for different hardware. See the "packakge"_package.html command
|
||||
doc page for details. :l
|
||||
|
||||
As described by the "package gpu"_package.html command, GPU
|
||||
accelerated pair styles can perform computations asynchronously with
|
||||
CPU computations. The "Pair" time reported by LAMMPS will be the
|
||||
maximum of the time required to complete the CPU pair style
|
||||
computations and the time required to complete the GPU pair style
|
||||
computations. Any time spent for GPU-enabled pair styles for
|
||||
computations that run simultaneously with "bond"_bond_style.html,
|
||||
"angle"_angle_style.html, "dihedral"_dihedral_style.html,
|
||||
"improper"_improper_style.html, and "long-range"_kspace_style.html
|
||||
calculations will not be included in the "Pair" time. :l
|
||||
|
||||
When the {mode} setting for the package gpu command is force/neigh,
|
||||
the time for neighbor list calculations on the GPU will be added into
|
||||
the "Pair" time, not the "Neigh" time. An additional breakdown of the
|
||||
times required for various tasks on the GPU (data copy, neighbor
|
||||
calculations, force computations, etc) are output only with the LAMMPS
|
||||
screen output (not in the log file) at the end of each run. These
|
||||
timings represent total time spent on the GPU for each routine,
|
||||
regardless of asynchronous CPU calculations. :l
|
||||
|
||||
The output section "GPU Time Info (average)" reports "Max Mem / Proc".
|
||||
This is the maximum memory used at one time on the GPU for data
|
||||
storage by a single MPI process. :l,ule
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
None.
|
||||
@ -1,462 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>5.USER-INTEL package — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>5.USER-INTEL package</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<p><a class="reference internal" href="Section_accelerate.html"><em>Return to Section accelerate overview</em></a></p>
|
||||
<div class="section" id="user-intel-package">
|
||||
<h1>5.USER-INTEL package<a class="headerlink" href="#user-intel-package" title="Permalink to this headline">¶</a></h1>
|
||||
<p>The USER-INTEL package was developed by Mike Brown at Intel
|
||||
Corporation. It provides two methods for accelerating simulations,
|
||||
depending on the hardware you have. The first is acceleration on
|
||||
Intel(R) CPUs by running in single, mixed, or double precision with
|
||||
vectorization. The second is acceleration on Intel(R) Xeon Phi(TM)
|
||||
coprocessors via offloading neighbor list and non-bonded force
|
||||
calculations to the Phi. The same C++ code is used in both cases.
|
||||
When offloading to a coprocessor from a CPU, the same routine is run
|
||||
twice, once on the CPU and once with an offload flag.</p>
|
||||
<p>Note that the USER-INTEL package supports use of the Phi in “offload”
|
||||
mode, not “native” mode like the <a class="reference internal" href="accelerate_kokkos.html"><em>KOKKOS package</em></a>.</p>
|
||||
<p>Also note that the USER-INTEL package can be used in tandem with the
|
||||
<a class="reference internal" href="accelerate_omp.html"><em>USER-OMP package</em></a>. This is useful when
|
||||
offloading pair style computations to the Phi, so that other styles
|
||||
not supported by the USER-INTEL package, e.g. bond, angle, dihedral,
|
||||
improper, and long-range electrostatics, can run simultaneously in
|
||||
threaded mode on the CPU cores. Since less MPI tasks than CPU cores
|
||||
will typically be invoked when running with coprocessors, this enables
|
||||
the extra CPU cores to be used for useful computation.</p>
|
||||
<p>As illustrated below, if LAMMPS is built with both the USER-INTEL and
|
||||
USER-OMP packages, this dual mode of operation is made easier to use,
|
||||
via the “-suffix hybrid intel omp” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> or the <a class="reference internal" href="suffix.html"><em>suffix hybrid intel omp</em></a> command. Both set a second-choice suffix to “omp” so
|
||||
that styles from the USER-INTEL package will be used if available,
|
||||
with styles from the USER-OMP package as a second choice.</p>
|
||||
<p>Here is a quick overview of how to use the USER-INTEL package for CPU
|
||||
acceleration, assuming one or more 16-core nodes. More details
|
||||
follow.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>use an Intel compiler
|
||||
use these CCFLAGS settings in Makefile.machine: -fopenmp, -DLAMMPS_MEMALIGN=64, -restrict, -xHost, -fno-alias, -ansi-alias, -override-limits
|
||||
use these LINKFLAGS settings in Makefile.machine: -fopenmp, -xHost
|
||||
make yes-user-intel yes-user-omp # including user-omp is optional
|
||||
make mpi # build with the USER-INTEL package, if settings (including compiler) added to Makefile.mpi
|
||||
make intel_cpu # or Makefile.intel_cpu already has settings, uses Intel MPI wrapper
|
||||
Make.py -v -p intel omp -intel cpu -a file mpich_icc # or one-line build via Make.py for MPICH
|
||||
Make.py -v -p intel omp -intel cpu -a file ompi_icc # or for OpenMPI
|
||||
Make.py -v -p intel omp -intel cpu -a file intel_cpu # or for Intel MPI wrapper
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>lmp_machine -sf intel -pk intel 0 omp 16 -in in.script # 1 node, 1 MPI task/node, 16 threads/task, no USER-OMP
|
||||
mpirun -np 32 lmp_machine -sf intel -in in.script # 2 nodess, 16 MPI tasks/node, no threads, no USER-OMP
|
||||
lmp_machine -sf hybrid intel omp -pk intel 0 omp 16 -pk omp 16 -in in.script # 1 node, 1 MPI task/node, 16 threads/task, with USER-OMP
|
||||
mpirun -np 32 -ppn 4 lmp_machine -sf hybrid intel omp -pk omp 4 -pk omp 4 -in in.script # 8 nodes, 4 MPI tasks/node, 4 threads/task, with USER-OMP
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Here is a quick overview of how to use the USER-INTEL package for the
|
||||
same CPUs as above (16 cores/node), with an additional Xeon Phi(TM)
|
||||
coprocessor per node. More details follow.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>Same as above for building, with these additions/changes:
|
||||
add the flag -DLMP_INTEL_OFFLOAD to CCFLAGS in Makefile.machine
|
||||
add the flag -offload to LINKFLAGS in Makefile.machine
|
||||
for Make.py change "-intel cpu" to "-intel phi", and "file intel_cpu" to "file intel_phi"
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>mpirun -np 32 lmp_machine -sf intel -pk intel 1 -in in.script # 2 nodes, 16 MPI tasks/node, 240 total threads on coprocessor, no USER-OMP
|
||||
mpirun -np 16 -ppn 8 lmp_machine -sf intel -pk intel 1 omp 2 -in in.script # 2 nodes, 8 MPI tasks/node, 2 threads/task, 240 total threads on coprocessor, no USER-OMP
|
||||
mpirun -np 32 -ppn 8 lmp_machine -sf hybrid intel omp -pk intel 1 omp 2 -pk omp 2 -in in.script # 4 nodes, 8 MPI tasks/node, 2 threads/task, 240 total threads on coprocessor, with USER-OMP
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>Required hardware/software:</strong></p>
|
||||
<p>Your compiler must support the OpenMP interface. Use of an Intel(R)
|
||||
C++ compiler is recommended, but not required. However, g++ will not
|
||||
recognize some of the settings listed above, so they cannot be used.
|
||||
Optimizations for vectorization have only been tested with the
|
||||
Intel(R) compiler. Use of other compilers may not result in
|
||||
vectorization, or give poor performance.</p>
|
||||
<p>The recommended version of the Intel(R) compiler is 14.0.1.106.
|
||||
Versions 15.0.1.133 and later are also supported. If using Intel(R)
|
||||
MPI, versions 15.0.2.044 and later are recommended.</p>
|
||||
<p>To use the offload option, you must have one or more Intel(R) Xeon
|
||||
Phi(TM) coprocessors and use an Intel(R) C++ compiler.</p>
|
||||
<p><strong>Building LAMMPS with the USER-INTEL package:</strong></p>
|
||||
<p>The lines above illustrate how to include/build with the USER-INTEL
|
||||
package, for either CPU or Phi support, in two steps, using the “make”
|
||||
command. Or how to do it with one command via the src/Make.py script,
|
||||
described in <a class="reference internal" href="Section_start.html#start-4"><span>Section 2.4</span></a> of the manual.
|
||||
Type “Make.py -h” for help. Because the mechanism for specifing what
|
||||
compiler to use (Intel in this case) is different for different MPI
|
||||
wrappers, 3 versions of the Make.py command are shown.</p>
|
||||
<p>Note that if you build with support for a Phi coprocessor, the same
|
||||
binary can be used on nodes with or without coprocessors installed.
|
||||
However, if you do not have coprocessors on your system, building
|
||||
without offload support will produce a smaller binary.</p>
|
||||
<p>If you also build with the USER-OMP package, you can use styles from
|
||||
both packages, as described below.</p>
|
||||
<p>Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
|
||||
include “-fopenmp”. Likewise, if you use an Intel compiler, the
|
||||
CCFLAGS setting must include “-restrict”. For Phi support, the
|
||||
“-DLMP_INTEL_OFFLOAD” (CCFLAGS) and “-offload” (LINKFLAGS) settings
|
||||
are required. The other settings listed above are optional, but will
|
||||
typically improve performance. The Make.py command will add all of
|
||||
these automatically.</p>
|
||||
<p>If you are compiling on the same architecture that will be used for
|
||||
the runs, adding the flag <em>-xHost</em> to CCFLAGS enables vectorization
|
||||
with the Intel(R) compiler. Otherwise, you must provide the correct
|
||||
compute node architecture to the -x option (e.g. -xAVX).</p>
|
||||
<p>Example machines makefiles Makefile.intel_cpu and Makefile.intel_phi
|
||||
are included in the src/MAKE/OPTIONS directory with settings that
|
||||
perform well with the Intel(R) compiler. The latter has support for
|
||||
offload to Phi coprocessors; the former does not.</p>
|
||||
<p><strong>Run with the USER-INTEL package from the command line:</strong></p>
|
||||
<p>The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.</p>
|
||||
<p>If you compute (any portion of) pairwise interactions using USER-INTEL
|
||||
pair styles on the CPU, or use USER-OMP styles on the CPU, you need to
|
||||
choose how many OpenMP threads per MPI task to use. If both packages
|
||||
are used, it must be done for both packages, and the same thread count
|
||||
value should be used for both. Note that the product of MPI tasks *
|
||||
threads/task should not exceed the physical number of cores (on a
|
||||
node), otherwise performance will suffer.</p>
|
||||
<p>When using the USER-INTEL package for the Phi, you also need to
|
||||
specify the number of coprocessor/node and optionally the number of
|
||||
coprocessor threads per MPI task to use. Note that coprocessor
|
||||
threads (which run on the coprocessor) are totally independent from
|
||||
OpenMP threads (which run on the CPU). The default values for the
|
||||
settings that affect coprocessor threads are typically fine, as
|
||||
discussed below.</p>
|
||||
<p>As in the lines above, use the “-sf intel” or “-sf hybrid intel omp”
|
||||
<a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>, which will
|
||||
automatically append “intel” to styles that support it. In the second
|
||||
case, “omp” will be appended if an “intel” style does not exist.</p>
|
||||
<p>Note that if either switch is used, it also invokes a default command:
|
||||
<a class="reference internal" href="package.html"><em>package intel 1</em></a>. If the “-sf hybrid intel omp” switch
|
||||
is used, the default USER-OMP command <a class="reference internal" href="package.html"><em>package omp 0</em></a> is
|
||||
also invoked (if LAMMPS was built with USER-OMP). Both set the number
|
||||
of OpenMP threads per MPI task via the OMP_NUM_THREADS environment
|
||||
variable. The first command sets the number of Xeon Phi(TM)
|
||||
coprocessors/node to 1 (ignored if USER-INTEL is built for CPU-only),
|
||||
and the precision mode to “mixed” (default value).</p>
|
||||
<p>You can also use the “-pk intel Nphi” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> to explicitly set Nphi = # of Xeon
|
||||
Phi(TM) coprocessors/node, as well as additional options. Nphi should
|
||||
be >= 1 if LAMMPS was built with coprocessor support, otherswise Nphi
|
||||
= 0 for a CPU-only build. All the available coprocessor threads on
|
||||
each Phi will be divided among MPI tasks, unless the <em>tptask</em> option
|
||||
of the “-pk intel” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> is
|
||||
used to limit the coprocessor threads per MPI task. See the <a class="reference internal" href="package.html"><em>package intel</em></a> command for details, including the default values
|
||||
used for all its options if not specified, and how to set the number
|
||||
of OpenMP threads via the OMP_NUM_THREADS environment variable if
|
||||
desired.</p>
|
||||
<p>If LAMMPS was built with the USER-OMP package, you can also use the
|
||||
“-pk omp Nt” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> to
|
||||
explicitly set Nt = # of OpenMP threads per MPI task to use, as well
|
||||
as additional options. Nt should be the same threads per MPI task as
|
||||
set for the USER-INTEL package, e.g. via the “-pk intel Nphi omp Nt”
|
||||
command. Again, see the <a class="reference internal" href="package.html"><em>package omp</em></a> command for
|
||||
details, including the default values used for all its options if not
|
||||
specified, and how to set the number of OpenMP threads via the
|
||||
OMP_NUM_THREADS environment variable if desired.</p>
|
||||
<p><strong>Or run with the USER-INTEL package by editing an input script:</strong></p>
|
||||
<p>The discussion above for the mpirun/mpiexec command, MPI tasks/node,
|
||||
OpenMP threads per MPI task, and coprocessor threads per MPI task is
|
||||
the same.</p>
|
||||
<p>Use the <a class="reference internal" href="suffix.html"><em>suffix intel</em></a> or <a class="reference internal" href="suffix.html"><em>suffix hybrid intel omp</em></a> commands, or you can explicitly add an “intel” or
|
||||
“omp” suffix to individual styles in your input script, e.g.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>pair_style lj/cut/intel 2.5
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>You must also use the <a class="reference internal" href="package.html"><em>package intel</em></a> command, unless the
|
||||
“-sf intel” or “-pk intel” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switches</span></a> were used. It specifies how many
|
||||
coprocessors/node to use, as well as other OpenMP threading and
|
||||
coprocessor options. The <a class="reference internal" href="package.html"><em>package</em></a> doc page explains how
|
||||
to set the number of OpenMP threads via an environment variable if
|
||||
desired.</p>
|
||||
<p>If LAMMPS was also built with the USER-OMP package, you must also use
|
||||
the <a class="reference internal" href="package.html"><em>package omp</em></a> command to enable that package, unless
|
||||
the “-sf hybrid intel omp” or “-pk omp” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switches</span></a> were used. It specifies how many
|
||||
OpenMP threads per MPI task to use (should be same as the setting for
|
||||
the USER-INTEL package), as well as other options. Its doc page
|
||||
explains how to set the number of OpenMP threads via an environment
|
||||
variable if desired.</p>
|
||||
<p><strong>Speed-ups to expect:</strong></p>
|
||||
<p>If LAMMPS was not built with coprocessor support (CPU only) when
|
||||
including the USER-INTEL package, then acclerated styles will run on
|
||||
the CPU using vectorization optimizations and the specified precision.
|
||||
This may give a substantial speed-up for a pair style, particularly if
|
||||
mixed or single precision is used.</p>
|
||||
<p>If LAMMPS was built with coproccesor support, the pair styles will run
|
||||
on one or more Intel(R) Xeon Phi(TM) coprocessors (per node). The
|
||||
performance of a Xeon Phi versus a multi-core CPU is a function of
|
||||
your hardware, which pair style is used, the number of
|
||||
atoms/coprocessor, and the precision used on the coprocessor (double,
|
||||
single, mixed).</p>
|
||||
<p>See the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the
|
||||
LAMMPS web site for performance of the USER-INTEL package on different
|
||||
hardware.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">Setting core affinity is often used to pin MPI tasks and OpenMP
|
||||
threads to a core or group of cores so that memory access can be
|
||||
uniform. Unless disabled at build time, affinity for MPI tasks and
|
||||
OpenMP threads on the host (CPU) will be set by default on the host
|
||||
when using offload to a coprocessor. In this case, it is unnecessary
|
||||
to use other methods to control affinity (e.g. taskset, numactl,
|
||||
I_MPI_PIN_DOMAIN, etc.). This can be disabled in an input script with
|
||||
the <em>no_affinity</em> option to the <a class="reference internal" href="package.html"><em>package intel</em></a> command
|
||||
or by disabling the option at build time (by adding
|
||||
-DINTEL_OFFLOAD_NOAFFINITY to the CCFLAGS line of your Makefile).
|
||||
Disabling this option is not recommended, especially when running on a
|
||||
machine with hyperthreading disabled.</p>
|
||||
</div>
|
||||
<p><strong>Guidelines for best performance on an Intel(R) Xeon Phi(TM)
|
||||
coprocessor:</strong></p>
|
||||
<ul class="simple">
|
||||
<li>The default for the <a class="reference internal" href="package.html"><em>package intel</em></a> command is to have
|
||||
all the MPI tasks on a given compute node use a single Xeon Phi(TM)
|
||||
coprocessor. In general, running with a large number of MPI tasks on
|
||||
each node will perform best with offload. Each MPI task will
|
||||
automatically get affinity to a subset of the hardware threads
|
||||
available on the coprocessor. For example, if your card has 61 cores,
|
||||
with 60 cores available for offload and 4 hardware threads per core
|
||||
(240 total threads), running with 24 MPI tasks per node will cause
|
||||
each MPI task to use a subset of 10 threads on the coprocessor. Fine
|
||||
tuning of the number of threads to use per MPI task or the number of
|
||||
threads to use per core can be accomplished with keyword settings of
|
||||
the <a class="reference internal" href="package.html"><em>package intel</em></a> command.</li>
|
||||
<li>If desired, only a fraction of the pair style computation can be
|
||||
offloaded to the coprocessors. This is accomplished by using the
|
||||
<em>balance</em> keyword in the <a class="reference internal" href="package.html"><em>package intel</em></a> command. A
|
||||
balance of 0 runs all calculations on the CPU. A balance of 1 runs
|
||||
all calculations on the coprocessor. A balance of 0.5 runs half of
|
||||
the calculations on the coprocessor. Setting the balance to -1 (the
|
||||
default) will enable dynamic load balancing that continously adjusts
|
||||
the fraction of offloaded work throughout the simulation. This option
|
||||
typically produces results within 5 to 10 percent of the optimal fixed
|
||||
balance.</li>
|
||||
<li>When using offload with CPU hyperthreading disabled, it may help
|
||||
performance to use fewer MPI tasks and OpenMP threads than available
|
||||
cores. This is due to the fact that additional threads are generated
|
||||
internally to handle the asynchronous offload tasks.</li>
|
||||
<li>If running short benchmark runs with dynamic load balancing, adding a
|
||||
short warm-up run (10-20 steps) will allow the load-balancer to find a
|
||||
near-optimal setting that will carry over to additional runs.</li>
|
||||
<li>If pair computations are being offloaded to an Intel(R) Xeon Phi(TM)
|
||||
coprocessor, a diagnostic line is printed to the screen (not to the
|
||||
log file), during the setup phase of a run, indicating that offload
|
||||
mode is being used and indicating the number of coprocessor threads
|
||||
per MPI task. Additionally, an offload timing summary is printed at
|
||||
the end of each run. When offloading, the frequency for <a class="reference internal" href="atom_modify.html"><em>atom sorting</em></a> is changed to 1 so that the per-atom data is
|
||||
effectively sorted at every rebuild of the neighbor lists.</li>
|
||||
<li>For simulations with long-range electrostatics or bond, angle,
|
||||
dihedral, improper calculations, computation and data transfer to the
|
||||
coprocessor will run concurrently with computations and MPI
|
||||
communications for these calculations on the host CPU. The USER-INTEL
|
||||
package has two modes for deciding which atoms will be handled by the
|
||||
coprocessor. This choice is controlled with the <em>ghost</em> keyword of
|
||||
the <a class="reference internal" href="package.html"><em>package intel</em></a> command. When set to 0, ghost atoms
|
||||
(atoms at the borders between MPI tasks) are not offloaded to the
|
||||
card. This allows for overlap of MPI communication of forces with
|
||||
computation on the coprocessor when the <a class="reference internal" href="newton.html"><em>newton</em></a> setting
|
||||
is “on”. The default is dependent on the style being used, however,
|
||||
better performance may be achieved by setting this option
|
||||
explictly.</li>
|
||||
</ul>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>When offloading to a coprocessor, <a class="reference internal" href="pair_hybrid.html"><em>hybrid</em></a> styles
|
||||
that require skip lists for neighbor builds cannot be offloaded.
|
||||
Using <a class="reference internal" href="pair_hybrid.html"><em>hybrid/overlay</em></a> is allowed. Only one intel
|
||||
accelerated style may be used with hybrid styles.
|
||||
<a class="reference internal" href="special_bonds.html"><em>Special_bonds</em></a> exclusion lists are not currently
|
||||
supported with offload, however, the same effect can often be
|
||||
accomplished by setting cutoffs for excluded atom types to 0. None of
|
||||
the pair styles in the USER-INTEL package currently support the
|
||||
“inner”, “middle”, “outer” options for rRESPA integration via the
|
||||
<a class="reference internal" href="run_style.html"><em>run_style respa</em></a> command; only the “pair” option is
|
||||
supported.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,321 +0,0 @@
|
||||
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
"Return to Section accelerate overview"_Section_accelerate.html
|
||||
|
||||
5.3.3 USER-INTEL package :h4
|
||||
|
||||
The USER-INTEL package was developed by Mike Brown at Intel
|
||||
Corporation. It provides two methods for accelerating simulations,
|
||||
depending on the hardware you have. The first is acceleration on
|
||||
Intel(R) CPUs by running in single, mixed, or double precision with
|
||||
vectorization. The second is acceleration on Intel(R) Xeon Phi(TM)
|
||||
coprocessors via offloading neighbor list and non-bonded force
|
||||
calculations to the Phi. The same C++ code is used in both cases.
|
||||
When offloading to a coprocessor from a CPU, the same routine is run
|
||||
twice, once on the CPU and once with an offload flag.
|
||||
|
||||
Note that the USER-INTEL package supports use of the Phi in "offload"
|
||||
mode, not "native" mode like the "KOKKOS
|
||||
package"_accelerate_kokkos.html.
|
||||
|
||||
Also note that the USER-INTEL package can be used in tandem with the
|
||||
"USER-OMP package"_accelerate_omp.html. This is useful when
|
||||
offloading pair style computations to the Phi, so that other styles
|
||||
not supported by the USER-INTEL package, e.g. bond, angle, dihedral,
|
||||
improper, and long-range electrostatics, can run simultaneously in
|
||||
threaded mode on the CPU cores. Since less MPI tasks than CPU cores
|
||||
will typically be invoked when running with coprocessors, this enables
|
||||
the extra CPU cores to be used for useful computation.
|
||||
|
||||
As illustrated below, if LAMMPS is built with both the USER-INTEL and
|
||||
USER-OMP packages, this dual mode of operation is made easier to use,
|
||||
via the "-suffix hybrid intel omp" "command-line
|
||||
switch"_Section_start.html#start_7 or the "suffix hybrid intel
|
||||
omp"_suffix.html command. Both set a second-choice suffix to "omp" so
|
||||
that styles from the USER-INTEL package will be used if available,
|
||||
with styles from the USER-OMP package as a second choice.
|
||||
|
||||
Here is a quick overview of how to use the USER-INTEL package for CPU
|
||||
acceleration, assuming one or more 16-core nodes. More details
|
||||
follow.
|
||||
|
||||
use an Intel compiler
|
||||
use these CCFLAGS settings in Makefile.machine: -fopenmp, -DLAMMPS_MEMALIGN=64, -restrict, -xHost, -fno-alias, -ansi-alias, -override-limits
|
||||
use these LINKFLAGS settings in Makefile.machine: -fopenmp, -xHost
|
||||
make yes-user-intel yes-user-omp # including user-omp is optional
|
||||
make mpi # build with the USER-INTEL package, if settings (including compiler) added to Makefile.mpi
|
||||
make intel_cpu # or Makefile.intel_cpu already has settings, uses Intel MPI wrapper
|
||||
Make.py -v -p intel omp -intel cpu -a file mpich_icc # or one-line build via Make.py for MPICH
|
||||
Make.py -v -p intel omp -intel cpu -a file ompi_icc # or for OpenMPI
|
||||
Make.py -v -p intel omp -intel cpu -a file intel_cpu # or for Intel MPI wrapper :pre
|
||||
|
||||
lmp_machine -sf intel -pk intel 0 omp 16 -in in.script # 1 node, 1 MPI task/node, 16 threads/task, no USER-OMP
|
||||
mpirun -np 32 lmp_machine -sf intel -in in.script # 2 nodess, 16 MPI tasks/node, no threads, no USER-OMP
|
||||
lmp_machine -sf hybrid intel omp -pk intel 0 omp 16 -pk omp 16 -in in.script # 1 node, 1 MPI task/node, 16 threads/task, with USER-OMP
|
||||
mpirun -np 32 -ppn 4 lmp_machine -sf hybrid intel omp -pk omp 4 -pk omp 4 -in in.script # 8 nodes, 4 MPI tasks/node, 4 threads/task, with USER-OMP :pre
|
||||
|
||||
Here is a quick overview of how to use the USER-INTEL package for the
|
||||
same CPUs as above (16 cores/node), with an additional Xeon Phi(TM)
|
||||
coprocessor per node. More details follow.
|
||||
|
||||
Same as above for building, with these additions/changes:
|
||||
add the flag -DLMP_INTEL_OFFLOAD to CCFLAGS in Makefile.machine
|
||||
add the flag -offload to LINKFLAGS in Makefile.machine
|
||||
for Make.py change "-intel cpu" to "-intel phi", and "file intel_cpu" to "file intel_phi" :pre
|
||||
|
||||
mpirun -np 32 lmp_machine -sf intel -pk intel 1 -in in.script # 2 nodes, 16 MPI tasks/node, 240 total threads on coprocessor, no USER-OMP
|
||||
mpirun -np 16 -ppn 8 lmp_machine -sf intel -pk intel 1 omp 2 -in in.script # 2 nodes, 8 MPI tasks/node, 2 threads/task, 240 total threads on coprocessor, no USER-OMP
|
||||
mpirun -np 32 -ppn 8 lmp_machine -sf hybrid intel omp -pk intel 1 omp 2 -pk omp 2 -in in.script # 4 nodes, 8 MPI tasks/node, 2 threads/task, 240 total threads on coprocessor, with USER-OMP :pre
|
||||
|
||||
[Required hardware/software:]
|
||||
|
||||
Your compiler must support the OpenMP interface. Use of an Intel(R)
|
||||
C++ compiler is recommended, but not required. However, g++ will not
|
||||
recognize some of the settings listed above, so they cannot be used.
|
||||
Optimizations for vectorization have only been tested with the
|
||||
Intel(R) compiler. Use of other compilers may not result in
|
||||
vectorization, or give poor performance.
|
||||
|
||||
The recommended version of the Intel(R) compiler is 14.0.1.106.
|
||||
Versions 15.0.1.133 and later are also supported. If using Intel(R)
|
||||
MPI, versions 15.0.2.044 and later are recommended.
|
||||
|
||||
To use the offload option, you must have one or more Intel(R) Xeon
|
||||
Phi(TM) coprocessors and use an Intel(R) C++ compiler.
|
||||
|
||||
[Building LAMMPS with the USER-INTEL package:]
|
||||
|
||||
The lines above illustrate how to include/build with the USER-INTEL
|
||||
package, for either CPU or Phi support, in two steps, using the "make"
|
||||
command. Or how to do it with one command via the src/Make.py script,
|
||||
described in "Section 2.4"_Section_start.html#start_4 of the manual.
|
||||
Type "Make.py -h" for help. Because the mechanism for specifing what
|
||||
compiler to use (Intel in this case) is different for different MPI
|
||||
wrappers, 3 versions of the Make.py command are shown.
|
||||
|
||||
Note that if you build with support for a Phi coprocessor, the same
|
||||
binary can be used on nodes with or without coprocessors installed.
|
||||
However, if you do not have coprocessors on your system, building
|
||||
without offload support will produce a smaller binary.
|
||||
|
||||
If you also build with the USER-OMP package, you can use styles from
|
||||
both packages, as described below.
|
||||
|
||||
Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
|
||||
include "-fopenmp". Likewise, if you use an Intel compiler, the
|
||||
CCFLAGS setting must include "-restrict". For Phi support, the
|
||||
"-DLMP_INTEL_OFFLOAD" (CCFLAGS) and "-offload" (LINKFLAGS) settings
|
||||
are required. The other settings listed above are optional, but will
|
||||
typically improve performance. The Make.py command will add all of
|
||||
these automatically.
|
||||
|
||||
If you are compiling on the same architecture that will be used for
|
||||
the runs, adding the flag {-xHost} to CCFLAGS enables vectorization
|
||||
with the Intel(R) compiler. Otherwise, you must provide the correct
|
||||
compute node architecture to the -x option (e.g. -xAVX).
|
||||
|
||||
Example machines makefiles Makefile.intel_cpu and Makefile.intel_phi
|
||||
are included in the src/MAKE/OPTIONS directory with settings that
|
||||
perform well with the Intel(R) compiler. The latter has support for
|
||||
offload to Phi coprocessors; the former does not.
|
||||
|
||||
[Run with the USER-INTEL package from the command line:]
|
||||
|
||||
The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
|
||||
|
||||
If you compute (any portion of) pairwise interactions using USER-INTEL
|
||||
pair styles on the CPU, or use USER-OMP styles on the CPU, you need to
|
||||
choose how many OpenMP threads per MPI task to use. If both packages
|
||||
are used, it must be done for both packages, and the same thread count
|
||||
value should be used for both. Note that the product of MPI tasks *
|
||||
threads/task should not exceed the physical number of cores (on a
|
||||
node), otherwise performance will suffer.
|
||||
|
||||
When using the USER-INTEL package for the Phi, you also need to
|
||||
specify the number of coprocessor/node and optionally the number of
|
||||
coprocessor threads per MPI task to use. Note that coprocessor
|
||||
threads (which run on the coprocessor) are totally independent from
|
||||
OpenMP threads (which run on the CPU). The default values for the
|
||||
settings that affect coprocessor threads are typically fine, as
|
||||
discussed below.
|
||||
|
||||
As in the lines above, use the "-sf intel" or "-sf hybrid intel omp"
|
||||
"command-line switch"_Section_start.html#start_7, which will
|
||||
automatically append "intel" to styles that support it. In the second
|
||||
case, "omp" will be appended if an "intel" style does not exist.
|
||||
|
||||
Note that if either switch is used, it also invokes a default command:
|
||||
"package intel 1"_package.html. If the "-sf hybrid intel omp" switch
|
||||
is used, the default USER-OMP command "package omp 0"_package.html is
|
||||
also invoked (if LAMMPS was built with USER-OMP). Both set the number
|
||||
of OpenMP threads per MPI task via the OMP_NUM_THREADS environment
|
||||
variable. The first command sets the number of Xeon Phi(TM)
|
||||
coprocessors/node to 1 (ignored if USER-INTEL is built for CPU-only),
|
||||
and the precision mode to "mixed" (default value).
|
||||
|
||||
You can also use the "-pk intel Nphi" "command-line
|
||||
switch"_Section_start.html#start_7 to explicitly set Nphi = # of Xeon
|
||||
Phi(TM) coprocessors/node, as well as additional options. Nphi should
|
||||
be >= 1 if LAMMPS was built with coprocessor support, otherswise Nphi
|
||||
= 0 for a CPU-only build. All the available coprocessor threads on
|
||||
each Phi will be divided among MPI tasks, unless the {tptask} option
|
||||
of the "-pk intel" "command-line switch"_Section_start.html#start_7 is
|
||||
used to limit the coprocessor threads per MPI task. See the "package
|
||||
intel"_package.html command for details, including the default values
|
||||
used for all its options if not specified, and how to set the number
|
||||
of OpenMP threads via the OMP_NUM_THREADS environment variable if
|
||||
desired.
|
||||
|
||||
If LAMMPS was built with the USER-OMP package, you can also use the
|
||||
"-pk omp Nt" "command-line switch"_Section_start.html#start_7 to
|
||||
explicitly set Nt = # of OpenMP threads per MPI task to use, as well
|
||||
as additional options. Nt should be the same threads per MPI task as
|
||||
set for the USER-INTEL package, e.g. via the "-pk intel Nphi omp Nt"
|
||||
command. Again, see the "package omp"_package.html command for
|
||||
details, including the default values used for all its options if not
|
||||
specified, and how to set the number of OpenMP threads via the
|
||||
OMP_NUM_THREADS environment variable if desired.
|
||||
|
||||
[Or run with the USER-INTEL package by editing an input script:]
|
||||
|
||||
The discussion above for the mpirun/mpiexec command, MPI tasks/node,
|
||||
OpenMP threads per MPI task, and coprocessor threads per MPI task is
|
||||
the same.
|
||||
|
||||
Use the "suffix intel"_suffix.html or "suffix hybrid intel
|
||||
omp"_suffix.html commands, or you can explicitly add an "intel" or
|
||||
"omp" suffix to individual styles in your input script, e.g.
|
||||
|
||||
pair_style lj/cut/intel 2.5 :pre
|
||||
|
||||
You must also use the "package intel"_package.html command, unless the
|
||||
"-sf intel" or "-pk intel" "command-line
|
||||
switches"_Section_start.html#start_7 were used. It specifies how many
|
||||
coprocessors/node to use, as well as other OpenMP threading and
|
||||
coprocessor options. The "package"_package.html doc page explains how
|
||||
to set the number of OpenMP threads via an environment variable if
|
||||
desired.
|
||||
|
||||
If LAMMPS was also built with the USER-OMP package, you must also use
|
||||
the "package omp"_package.html command to enable that package, unless
|
||||
the "-sf hybrid intel omp" or "-pk omp" "command-line
|
||||
switches"_Section_start.html#start_7 were used. It specifies how many
|
||||
OpenMP threads per MPI task to use (should be same as the setting for
|
||||
the USER-INTEL package), as well as other options. Its doc page
|
||||
explains how to set the number of OpenMP threads via an environment
|
||||
variable if desired.
|
||||
|
||||
[Speed-ups to expect:]
|
||||
|
||||
If LAMMPS was not built with coprocessor support (CPU only) when
|
||||
including the USER-INTEL package, then acclerated styles will run on
|
||||
the CPU using vectorization optimizations and the specified precision.
|
||||
This may give a substantial speed-up for a pair style, particularly if
|
||||
mixed or single precision is used.
|
||||
|
||||
If LAMMPS was built with coproccesor support, the pair styles will run
|
||||
on one or more Intel(R) Xeon Phi(TM) coprocessors (per node). The
|
||||
performance of a Xeon Phi versus a multi-core CPU is a function of
|
||||
your hardware, which pair style is used, the number of
|
||||
atoms/coprocessor, and the precision used on the coprocessor (double,
|
||||
single, mixed).
|
||||
|
||||
See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
|
||||
LAMMPS web site for performance of the USER-INTEL package on different
|
||||
hardware.
|
||||
|
||||
NOTE: Setting core affinity is often used to pin MPI tasks and OpenMP
|
||||
threads to a core or group of cores so that memory access can be
|
||||
uniform. Unless disabled at build time, affinity for MPI tasks and
|
||||
OpenMP threads on the host (CPU) will be set by default on the host
|
||||
when using offload to a coprocessor. In this case, it is unnecessary
|
||||
to use other methods to control affinity (e.g. taskset, numactl,
|
||||
I_MPI_PIN_DOMAIN, etc.). This can be disabled in an input script with
|
||||
the {no_affinity} option to the "package intel"_package.html command
|
||||
or by disabling the option at build time (by adding
|
||||
-DINTEL_OFFLOAD_NOAFFINITY to the CCFLAGS line of your Makefile).
|
||||
Disabling this option is not recommended, especially when running on a
|
||||
machine with hyperthreading disabled.
|
||||
|
||||
[Guidelines for best performance on an Intel(R) Xeon Phi(TM)
|
||||
coprocessor:]
|
||||
|
||||
The default for the "package intel"_package.html command is to have
|
||||
all the MPI tasks on a given compute node use a single Xeon Phi(TM)
|
||||
coprocessor. In general, running with a large number of MPI tasks on
|
||||
each node will perform best with offload. Each MPI task will
|
||||
automatically get affinity to a subset of the hardware threads
|
||||
available on the coprocessor. For example, if your card has 61 cores,
|
||||
with 60 cores available for offload and 4 hardware threads per core
|
||||
(240 total threads), running with 24 MPI tasks per node will cause
|
||||
each MPI task to use a subset of 10 threads on the coprocessor. Fine
|
||||
tuning of the number of threads to use per MPI task or the number of
|
||||
threads to use per core can be accomplished with keyword settings of
|
||||
the "package intel"_package.html command. :ulb,l
|
||||
|
||||
If desired, only a fraction of the pair style computation can be
|
||||
offloaded to the coprocessors. This is accomplished by using the
|
||||
{balance} keyword in the "package intel"_package.html command. A
|
||||
balance of 0 runs all calculations on the CPU. A balance of 1 runs
|
||||
all calculations on the coprocessor. A balance of 0.5 runs half of
|
||||
the calculations on the coprocessor. Setting the balance to -1 (the
|
||||
default) will enable dynamic load balancing that continously adjusts
|
||||
the fraction of offloaded work throughout the simulation. This option
|
||||
typically produces results within 5 to 10 percent of the optimal fixed
|
||||
balance. :l
|
||||
|
||||
When using offload with CPU hyperthreading disabled, it may help
|
||||
performance to use fewer MPI tasks and OpenMP threads than available
|
||||
cores. This is due to the fact that additional threads are generated
|
||||
internally to handle the asynchronous offload tasks. :l
|
||||
|
||||
If running short benchmark runs with dynamic load balancing, adding a
|
||||
short warm-up run (10-20 steps) will allow the load-balancer to find a
|
||||
near-optimal setting that will carry over to additional runs. :l
|
||||
|
||||
If pair computations are being offloaded to an Intel(R) Xeon Phi(TM)
|
||||
coprocessor, a diagnostic line is printed to the screen (not to the
|
||||
log file), during the setup phase of a run, indicating that offload
|
||||
mode is being used and indicating the number of coprocessor threads
|
||||
per MPI task. Additionally, an offload timing summary is printed at
|
||||
the end of each run. When offloading, the frequency for "atom
|
||||
sorting"_atom_modify.html is changed to 1 so that the per-atom data is
|
||||
effectively sorted at every rebuild of the neighbor lists. :l
|
||||
|
||||
For simulations with long-range electrostatics or bond, angle,
|
||||
dihedral, improper calculations, computation and data transfer to the
|
||||
coprocessor will run concurrently with computations and MPI
|
||||
communications for these calculations on the host CPU. The USER-INTEL
|
||||
package has two modes for deciding which atoms will be handled by the
|
||||
coprocessor. This choice is controlled with the {ghost} keyword of
|
||||
the "package intel"_package.html command. When set to 0, ghost atoms
|
||||
(atoms at the borders between MPI tasks) are not offloaded to the
|
||||
card. This allows for overlap of MPI communication of forces with
|
||||
computation on the coprocessor when the "newton"_newton.html setting
|
||||
is "on". The default is dependent on the style being used, however,
|
||||
better performance may be achieved by setting this option
|
||||
explictly. :l,ule
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
When offloading to a coprocessor, "hybrid"_pair_hybrid.html styles
|
||||
that require skip lists for neighbor builds cannot be offloaded.
|
||||
Using "hybrid/overlay"_pair_hybrid.html is allowed. Only one intel
|
||||
accelerated style may be used with hybrid styles.
|
||||
"Special_bonds"_special_bonds.html exclusion lists are not currently
|
||||
supported with offload, however, the same effect can often be
|
||||
accomplished by setting cutoffs for excluded atom types to 0. None of
|
||||
the pair styles in the USER-INTEL package currently support the
|
||||
"inner", "middle", "outer" options for rRESPA integration via the
|
||||
"run_style respa"_run_style.html command; only the "pair" option is
|
||||
supported.
|
||||
@ -1,626 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>5.KOKKOS package — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>5.KOKKOS package</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<p><a class="reference internal" href="Section_accelerate.html"><em>Return to Section accelerate overview</em></a></p>
|
||||
<div class="section" id="kokkos-package">
|
||||
<h1>5.KOKKOS package<a class="headerlink" href="#kokkos-package" title="Permalink to this headline">¶</a></h1>
|
||||
<p>The KOKKOS package was developed primarily by Christian Trott (Sandia)
|
||||
with contributions of various styles by others, including Sikandar
|
||||
Mashayak (UIUC), Stan Moore (Sandia), and Ray Shan (Sandia). The
|
||||
underlying Kokkos library was written primarily by Carter Edwards,
|
||||
Christian Trott, and Dan Sunderland (all Sandia).</p>
|
||||
<p>The KOKKOS package contains versions of pair, fix, and atom styles
|
||||
that use data structures and macros provided by the Kokkos library,
|
||||
which is included with LAMMPS in lib/kokkos.</p>
|
||||
<p>The Kokkos library is part of
|
||||
<a class="reference external" href="http://trilinos.sandia.gov/packages/kokkos">Trilinos</a> and can also be
|
||||
downloaded from <a class="reference external" href="https://github.com/kokkos/kokkos">Github</a>. Kokkos is a
|
||||
templated C++ library that provides two key abstractions for an
|
||||
application like LAMMPS. First, it allows a single implementation of
|
||||
an application kernel (e.g. a pair style) to run efficiently on
|
||||
different kinds of hardware, such as a GPU, Intel Phi, or many-core
|
||||
CPU.</p>
|
||||
<p>The Kokkos library also provides data abstractions to adjust (at
|
||||
compile time) the memory layout of basic data structures like 2d and
|
||||
3d arrays and allow the transparent utilization of special hardware
|
||||
load and store operations. Such data structures are used in LAMMPS to
|
||||
store atom coordinates or forces or neighbor lists. The layout is
|
||||
chosen to optimize performance on different platforms. Again this
|
||||
functionality is hidden from the developer, and does not affect how
|
||||
the kernel is coded.</p>
|
||||
<p>These abstractions are set at build time, when LAMMPS is compiled with
|
||||
the KOKKOS package installed. All Kokkos operations occur within the
|
||||
context of an individual MPI task running on a single node of the
|
||||
machine. The total number of MPI tasks used by LAMMPS (one or
|
||||
multiple per compute node) is set in the usual manner via the mpirun
|
||||
or mpiexec commands, and is independent of Kokkos.</p>
|
||||
<p>Kokkos currently provides support for 3 modes of execution (per MPI
|
||||
task). These are OpenMP (for many-core CPUs), Cuda (for NVIDIA GPUs),
|
||||
and OpenMP (for Intel Phi). Note that the KOKKOS package supports
|
||||
running on the Phi in native mode, not offload mode like the
|
||||
USER-INTEL package supports. You choose the mode at build time to
|
||||
produce an executable compatible with specific hardware.</p>
|
||||
<p>Here is a quick overview of how to use the KOKKOS package
|
||||
for CPU acceleration, assuming one or more 16-core nodes.
|
||||
More details follow.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>use a C++11 compatible compiler
|
||||
make yes-kokkos
|
||||
make mpi KOKKOS_DEVICES=OpenMP # build with the KOKKOS package
|
||||
make kokkos_omp # or Makefile.kokkos_omp already has variable set
|
||||
Make.py -v -p kokkos -kokkos omp -o mpi -a file mpi # or one-line build via Make.py
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>mpirun -np 16 lmp_mpi -k on -sf kk -in in.lj # 1 node, 16 MPI tasks/node, no threads
|
||||
mpirun -np 2 -ppn 1 lmp_mpi -k on t 16 -sf kk -in in.lj # 2 nodes, 1 MPI task/node, 16 threads/task
|
||||
mpirun -np 2 lmp_mpi -k on t 8 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 8 threads/task
|
||||
mpirun -np 32 -ppn 4 lmp_mpi -k on t 4 -sf kk -in in.lj # 8 nodes, 4 MPI tasks/node, 4 threads/task
|
||||
</pre></div>
|
||||
</div>
|
||||
<ul class="simple">
|
||||
<li>specify variables and settings in your Makefile.machine that enable OpenMP, GPU, or Phi support</li>
|
||||
<li>include the KOKKOS package and build LAMMPS</li>
|
||||
<li>enable the KOKKOS package and its hardware options via the “-k on” command-line switch use KOKKOS styles in your input script</li>
|
||||
</ul>
|
||||
<p>Here is a quick overview of how to use the KOKKOS package for GPUs,
|
||||
assuming one or more nodes, each with 16 cores and a GPU. More
|
||||
details follow.</p>
|
||||
<p>discuss use of NVCC, which Makefiles to examine</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>use a C++11 compatible compiler
|
||||
KOKKOS_DEVICES = Cuda, OpenMP
|
||||
KOKKOS_ARCH = Kepler35
|
||||
make yes-kokkos
|
||||
make machine
|
||||
Make.py -p kokkos -kokkos cuda arch=31 -o kokkos_cuda -a file kokkos_cuda
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>mpirun -np 1 lmp_cuda -k on t 6 -sf kk -in in.lj # one MPI task, 6 threads on CPU
|
||||
mpirun -np 4 -ppn 1 lmp_cuda -k on t 6 -sf kk -in in.lj # ditto on 4 nodes
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>mpirun -np 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj # two MPI tasks, 8 threads per CPU
|
||||
mpirun -np 32 -ppn 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj # ditto on 16 nodes
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Here is a quick overview of how to use the KOKKOS package
|
||||
for the Intel Phi:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>use a C++11 compatible compiler
|
||||
KOKKOS_DEVICES = OpenMP
|
||||
KOKKOS_ARCH = KNC
|
||||
make yes-kokkos
|
||||
make machine
|
||||
Make.py -p kokkos -kokkos phi -o kokkos_phi -a file mpi
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>host=MIC, Intel Phi with 61 cores (240 threads/phi via 4x hardware threading):
|
||||
mpirun -np 1 lmp_g++ -k on t 240 -sf kk -in in.lj # 1 MPI task on 1 Phi, 1*240 = 240
|
||||
mpirun -np 30 lmp_g++ -k on t 8 -sf kk -in in.lj # 30 MPI tasks on 1 Phi, 30*8 = 240
|
||||
mpirun -np 12 lmp_g++ -k on t 20 -sf kk -in in.lj # 12 MPI tasks on 1 Phi, 12*20 = 240
|
||||
mpirun -np 96 -ppn 12 lmp_g++ -k on t 20 -sf kk -in in.lj # ditto on 8 Phis
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>Required hardware/software:</strong></p>
|
||||
<p>Kokkos support within LAMMPS must be built with a C++11 compatible
|
||||
compiler. If using gcc, version 4.8.1 or later is required.</p>
|
||||
<p>To build with Kokkos support for CPUs, your compiler must support the
|
||||
OpenMP interface. You should have one or more multi-core CPUs so that
|
||||
multiple threads can be launched by each MPI task running on a CPU.</p>
|
||||
<p>To build with Kokkos support for NVIDIA GPUs, NVIDIA Cuda software
|
||||
version 6.5 or later must be installed on your system. See the
|
||||
discussion for the <a class="reference internal" href="accelerate_cuda.html"><em>USER-CUDA</em></a> and
|
||||
<a class="reference internal" href="accelerate_gpu.html"><em>GPU</em></a> packages for details of how to check and do
|
||||
this.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">For good performance of the KOKKOS package on GPUs, you must
|
||||
have Kepler generation GPUs (or later). The Kokkos library exploits
|
||||
texture cache options not supported by Telsa generation GPUs (or
|
||||
older).</p>
|
||||
</div>
|
||||
<p>To build with Kokkos support for Intel Xeon Phi coprocessors, your
|
||||
sysmte must be configured to use them in “native” mode, not “offload”
|
||||
mode like the USER-INTEL package supports.</p>
|
||||
<p><strong>Building LAMMPS with the KOKKOS package:</strong></p>
|
||||
<p>You must choose at build time whether to build for CPUs (OpenMP),
|
||||
GPUs, or Phi.</p>
|
||||
<p>You can do any of these in one line, using the src/Make.py script,
|
||||
described in <a class="reference internal" href="Section_start.html#start-4"><span>Section 2.4</span></a> of the manual.
|
||||
Type “Make.py -h” for help. If run from the src directory, these
|
||||
commands will create src/lmp_kokkos_omp, lmp_kokkos_cuda, and
|
||||
lmp_kokkos_phi. Note that the OMP and PHI options use
|
||||
src/MAKE/Makefile.mpi as the starting Makefile.machine. The CUDA
|
||||
option uses src/MAKE/OPTIONS/Makefile.kokkos_cuda.</p>
|
||||
<p>The latter two steps can be done using the “-k on”, “-pk kokkos” and
|
||||
“-sf kk” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switches</span></a>
|
||||
respectively. Or the effect of the “-pk” or “-sf” switches can be
|
||||
duplicated by adding the <a class="reference internal" href="package.html"><em>package kokkos</em></a> or <a class="reference internal" href="suffix.html"><em>suffix kk</em></a> commands respectively to your input script.</p>
|
||||
<p>Or you can follow these steps:</p>
|
||||
<p>CPU-only (run all-MPI or with OpenMP threading):</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>cd lammps/src
|
||||
make yes-kokkos
|
||||
make g++ KOKKOS_DEVICES=OpenMP
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Intel Xeon Phi:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>cd lammps/src
|
||||
make yes-kokkos
|
||||
make g++ KOKKOS_DEVICES=OpenMP KOKKOS_ARCH=KNC
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>CPUs and GPUs:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>cd lammps/src
|
||||
make yes-kokkos
|
||||
make cuda KOKKOS_DEVICES=Cuda
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>These examples set the KOKKOS-specific OMP, MIC, CUDA variables on the
|
||||
make command line which requires a GNU-compatible make command. Try
|
||||
“gmake” if your system’s standard make complains.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">If you build using make line variables and re-build LAMMPS twice
|
||||
with different KOKKOS options and the <em>same</em> target, e.g. g++ in the
|
||||
first two examples above, then you <em>must</em> perform a “make clean-all”
|
||||
or “make clean-machine” before each build. This is to force all the
|
||||
KOKKOS-dependent files to be re-compiled with the new options.</p>
|
||||
</div>
|
||||
<p>You can also hardwire these make variables in the specified machine
|
||||
makefile, e.g. src/MAKE/Makefile.g++ in the first two examples above,
|
||||
with a line like:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre><span class="n">KOKKOS_ARCH</span> <span class="o">=</span> <span class="n">KNC</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Note that if you build LAMMPS multiple times in this manner, using
|
||||
different KOKKOS options (defined in different machine makefiles), you
|
||||
do not have to worry about doing a “clean” in between. This is
|
||||
because the targets will be different.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">The 3rd example above for a GPU, uses a different machine
|
||||
makefile, in this case src/MAKE/Makefile.cuda, which is included in
|
||||
the LAMMPS distribution. To build the KOKKOS package for a GPU, this
|
||||
makefile must use the NVIDA “nvcc” compiler. And it must have a
|
||||
KOKKOS_ARCH setting that is appropriate for your NVIDIA hardware and
|
||||
installed software. Typical values for KOKKOS_ARCH are given below,
|
||||
as well as other settings that must be included in the machine
|
||||
makefile, if you create your own.</p>
|
||||
</div>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">Currently, there are no precision options with the KOKKOS
|
||||
package. All compilation and computation is performed in double
|
||||
precision.</p>
|
||||
</div>
|
||||
<p>There are other allowed options when building with the KOKKOS package.
|
||||
As above, they can be set either as variables on the make command line
|
||||
or in Makefile.machine. This is the full list of options, including
|
||||
those discussed above, Each takes a value shown below. The
|
||||
default value is listed, which is set in the
|
||||
lib/kokkos/Makefile.kokkos file.</p>
|
||||
<p>#Default settings specific options
|
||||
#Options: force_uvm,use_ldg,rdc</p>
|
||||
<ul class="simple">
|
||||
<li>KOKKOS_DEVICES, values = <em>OpenMP</em>, <em>Serial</em>, <em>Pthreads</em>, <em>Cuda</em>, default = <em>OpenMP</em></li>
|
||||
<li>KOKKOS_ARCH, values = <em>KNC</em>, <em>SNB</em>, <em>HSW</em>, <em>Kepler</em>, <em>Kepler30</em>, <em>Kepler32</em>, <em>Kepler35</em>, <em>Kepler37</em>, <em>Maxwell</em>, <em>Maxwell50</em>, <em>Maxwell52</em>, <em>Maxwell53</em>, <em>ARMv8</em>, <em>BGQ</em>, <em>Power7</em>, <em>Power8</em>, default = <em>none</em></li>
|
||||
<li>KOKKOS_DEBUG, values = <em>yes</em>, <em>no</em>, default = <em>no</em></li>
|
||||
<li>KOKKOS_USE_TPLS, values = <em>hwloc</em>, <em>librt</em>, default = <em>none</em></li>
|
||||
<li>KOKKOS_CUDA_OPTIONS, values = <em>force_uvm</em>, <em>use_ldg</em>, <em>rdc</em></li>
|
||||
</ul>
|
||||
<p>KOKKOS_DEVICE sets the parallelization method used for Kokkos code
|
||||
(within LAMMPS). KOKKOS_DEVICES=OpenMP means that OpenMP will be
|
||||
used. KOKKOS_DEVICES=Pthreads means that pthreads will be used.
|
||||
KOKKOS_DEVICES=Cuda means an NVIDIA GPU running CUDA will be used.</p>
|
||||
<p>If KOKKOS_DEVICES=Cuda, then the lo-level Makefile in the src/MAKE
|
||||
directory must use “nvcc” as its compiler, via its CC setting. For
|
||||
best performance its CCFLAGS setting should use -O3 and have a
|
||||
KOKKOS_ARCH setting that matches the compute capability of your NVIDIA
|
||||
hardware and software installation, e.g. KOKKOS_ARCH=Kepler30. Note
|
||||
the minimal required compute capability is 2.0, but this will give
|
||||
signicantly reduced performance compared to Kepler generation GPUs
|
||||
with compute capability 3.x. For the LINK setting, “nvcc” should not
|
||||
be used; instead use g++ or another compiler suitable for linking C++
|
||||
applications. Often you will want to use your MPI compiler wrapper
|
||||
for this setting (i.e. mpicxx). Finally, the lo-level Makefile must
|
||||
also have a “Compilation rule” for creating <a href="#id1"><span class="problematic" id="id2">*</span></a>.o files from <a href="#id3"><span class="problematic" id="id4">*</span></a>.cu files.
|
||||
See src/Makefile.cuda for an example of a lo-level Makefile with all
|
||||
of these settings.</p>
|
||||
<p>KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
|
||||
migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
|
||||
used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
|
||||
necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
|
||||
provides alternative methods via environment variables for binding
|
||||
threads to hardware cores. More info on binding threads to cores is
|
||||
given in <span class="xref std std-ref">this section</span>.</p>
|
||||
<p>KOKKOS_ARCH=KNC enables compiler switches needed when compling for an
|
||||
Intel Phi processor.</p>
|
||||
<p>KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
|
||||
on most Unix platforms. This library is not available on all
|
||||
platforms.</p>
|
||||
<p>KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
|
||||
within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
|
||||
debugging information that can be useful. It also enables runtime
|
||||
bounds checking on Kokkos data structures.</p>
|
||||
<p>KOKKOS_CUDA_OPTIONS are additional options for CUDA.</p>
|
||||
<p>For more information on Kokkos see the Kokkos programmers’ guide here:
|
||||
/lib/kokkos/doc/Kokkos_PG.pdf.</p>
|
||||
<p><strong>Run with the KOKKOS package from the command line:</strong></p>
|
||||
<p>The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.</p>
|
||||
<p>When using KOKKOS built with host=OMP, you need to choose how many
|
||||
OpenMP threads per MPI task will be used (via the “-k” command-line
|
||||
switch discussed below). Note that the product of MPI tasks * OpenMP
|
||||
threads/task should not exceed the physical number of cores (on a
|
||||
node), otherwise performance will suffer.</p>
|
||||
<p>When using the KOKKOS package built with device=CUDA, you must use
|
||||
exactly one MPI task per physical GPU.</p>
|
||||
<p>When using the KOKKOS package built with host=MIC for Intel Xeon Phi
|
||||
coprocessor support you need to insure there are one or more MPI tasks
|
||||
per coprocessor, and choose the number of coprocessor threads to use
|
||||
per MPI task (via the “-k” command-line switch discussed below). The
|
||||
product of MPI tasks * coprocessor threads/task should not exceed the
|
||||
maximum number of threads the coproprocessor is designed to run,
|
||||
otherwise performance will suffer. This value is 240 for current
|
||||
generation Xeon Phi(TM) chips, which is 60 physical cores * 4
|
||||
threads/core. Note that with the KOKKOS package you do not need to
|
||||
specify how many Phi coprocessors there are per node; each
|
||||
coprocessors is simply treated as running some number of MPI tasks.</p>
|
||||
<p>You must use the “-k on” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> to enable the KOKKOS package. It
|
||||
takes additional arguments for hardware settings appropriate to your
|
||||
system. Those arguments are <a class="reference internal" href="Section_start.html#start-7"><span>documented here</span></a>. The two most commonly used
|
||||
options are:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>-k on t Nt g Ng
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The “t Nt” option applies to host=OMP (even if device=CUDA) and
|
||||
host=MIC. For host=OMP, it specifies how many OpenMP threads per MPI
|
||||
task to use with a node. For host=MIC, it specifies how many Xeon Phi
|
||||
threads per MPI task to use within a node. The default is Nt = 1.
|
||||
Note that for host=OMP this is effectively MPI-only mode which may be
|
||||
fine. But for host=MIC you will typically end up using far less than
|
||||
all the 240 available threads, which could give very poor performance.</p>
|
||||
<p>The “g Ng” option applies to device=CUDA. It specifies how many GPUs
|
||||
per compute node to use. The default is 1, so this only needs to be
|
||||
specified is you have 2 or more GPUs per compute node.</p>
|
||||
<p>The “-k on” switch also issues a “package kokkos” command (with no
|
||||
additional arguments) which sets various KOKKOS options to default
|
||||
values, as discussed on the <a class="reference internal" href="package.html"><em>package</em></a> command doc page.</p>
|
||||
<p>Use the “-sf kk” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>,
|
||||
which will automatically append “kk” to styles that support it. Use
|
||||
the “-pk kokkos” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> if
|
||||
you wish to change any of the default <a class="reference internal" href="package.html"><em>package kokkos</em></a>
|
||||
optionns set by the “-k on” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>.</p>
|
||||
<p>Note that the default for the <a class="reference internal" href="package.html"><em>package kokkos</em></a> command is
|
||||
to use “full” neighbor lists and set the Newton flag to “off” for both
|
||||
pairwise and bonded interactions. This typically gives fastest
|
||||
performance. If the <a class="reference internal" href="newton.html"><em>newton</em></a> command is used in the input
|
||||
script, it can override the Newton flag defaults.</p>
|
||||
<p>However, when running in MPI-only mode with 1 thread per MPI task, it
|
||||
will typically be faster to use “half” neighbor lists and set the
|
||||
Newton flag to “on”, just as is the case for non-accelerated pair
|
||||
styles. You can do this with the “-pk” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>.</p>
|
||||
<p><strong>Or run with the KOKKOS package by editing an input script:</strong></p>
|
||||
<p>The discussion above for the mpirun/mpiexec command and setting
|
||||
appropriate thread and GPU values for host=OMP or host=MIC or
|
||||
device=CUDA are the same.</p>
|
||||
<p>You must still use the “-k on” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> to enable the KOKKOS package, and
|
||||
specify its additional arguments for hardware options appopriate to
|
||||
your system, as documented above.</p>
|
||||
<p>Use the <a class="reference internal" href="suffix.html"><em>suffix kk</em></a> command, or you can explicitly add a
|
||||
“kk” suffix to individual styles in your input script, e.g.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>pair_style lj/cut/kk 2.5
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>You only need to use the <a class="reference internal" href="package.html"><em>package kokkos</em></a> command if you
|
||||
wish to change any of its option defaults, as set by the “-k on”
|
||||
<a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>.</p>
|
||||
<p><strong>Speed-ups to expect:</strong></p>
|
||||
<p>The performance of KOKKOS running in different modes is a function of
|
||||
your hardware, which KOKKOS-enable styles are used, and the problem
|
||||
size.</p>
|
||||
<p>Generally speaking, the following rules of thumb apply:</p>
|
||||
<ul class="simple">
|
||||
<li>When running on CPUs only, with a single thread per MPI task,
|
||||
performance of a KOKKOS style is somewhere between the standard
|
||||
(un-accelerated) styles (MPI-only mode), and those provided by the
|
||||
USER-OMP package. However the difference between all 3 is small (less
|
||||
than 20%).</li>
|
||||
<li>When running on CPUs only, with multiple threads per MPI task,
|
||||
performance of a KOKKOS style is a bit slower than the USER-OMP
|
||||
package.</li>
|
||||
<li>When running on GPUs, KOKKOS is typically faster than the USER-CUDA
|
||||
and GPU packages.</li>
|
||||
<li>When running on Intel Xeon Phi, KOKKOS is not as fast as
|
||||
the USER-INTEL package, which is optimized for that hardware.</li>
|
||||
</ul>
|
||||
<p>See the <a class="reference external" href="http://lammps.sandia.gov/bench.html">Benchmark page</a> of the
|
||||
LAMMPS web site for performance of the KOKKOS package on different
|
||||
hardware.</p>
|
||||
<p><strong>Guidelines for best performance:</strong></p>
|
||||
<p>Here are guidline for using the KOKKOS package on the different
|
||||
hardware configurations listed above.</p>
|
||||
<p>Many of the guidelines use the <a class="reference internal" href="package.html"><em>package kokkos</em></a> command
|
||||
See its doc page for details and default settings. Experimenting with
|
||||
its options can provide a speed-up for specific calculations.</p>
|
||||
<p><strong>Running on a multi-core CPU:</strong></p>
|
||||
<p>If N is the number of physical cores/node, then the number of MPI
|
||||
tasks/node * number of threads/task should not exceed N, and should
|
||||
typically equal N. Note that the default threads/task is 1, as set by
|
||||
the “t” keyword of the “-k” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>. If you do not change this, no
|
||||
additional parallelism (beyond MPI) will be invoked on the host
|
||||
CPU(s).</p>
|
||||
<p>You can compare the performance running in different modes:</p>
|
||||
<ul class="simple">
|
||||
<li>run with 1 MPI task/node and N threads/task</li>
|
||||
<li>run with N MPI tasks/node and 1 thread/task</li>
|
||||
<li>run with settings in between these extremes</li>
|
||||
</ul>
|
||||
<p>Examples of mpirun commands in these modes are shown above.</p>
|
||||
<p>When using KOKKOS to perform multi-threading, it is important for
|
||||
performance to bind both MPI tasks to physical cores, and threads to
|
||||
physical cores, so they do not migrate during a simulation.</p>
|
||||
<p>If you are not certain MPI tasks are being bound (check the defaults
|
||||
for your MPI installation), binding can be forced with these flags:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>OpenMPI 1.8: mpirun -np 2 -bind-to socket -map-by socket ./lmp_openmpi ...
|
||||
Mvapich2 2.0: mpiexec -np 2 -bind-to socket -map-by socket ./lmp_mvapich ...
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>For binding threads with the KOKKOS OMP option, use thread affinity
|
||||
environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
|
||||
later, intel 12 or later) setting the environment variable
|
||||
OMP_PROC_BIND=true should be sufficient. For binding threads with the
|
||||
KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option, as
|
||||
discussed in <a class="reference internal" href="Section_start.html#start-3-4"><span>Section 2.3.4</span></a> of the
|
||||
manual.</p>
|
||||
<p><strong>Running on GPUs:</strong></p>
|
||||
<p>Insure the -arch setting in the machine makefile you are using,
|
||||
e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
|
||||
(see <a class="reference internal" href="Section_start.html#start-3-4"><span>this section</span></a> of the manual for
|
||||
details).</p>
|
||||
<p>The -np setting of the mpirun command should set the number of MPI
|
||||
tasks/node to be equal to the # of physical GPUs on the node.</p>
|
||||
<p>Use the “-k” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a> to
|
||||
specify the number of GPUs per node, and the number of threads per MPI
|
||||
task. As above for multi-core CPUs (and no GPU), if N is the number
|
||||
of physical cores/node, then the number of MPI tasks/node * number of
|
||||
threads/task should not exceed N. With one GPU (and one MPI task) it
|
||||
may be faster to use less than all the available cores, by setting
|
||||
threads/task to a smaller value. This is because using all the cores
|
||||
on a dual-socket node will incur extra cost to copy memory from the
|
||||
2nd socket to the GPU.</p>
|
||||
<p>Examples of mpirun commands that follow these rules are shown above.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">When using a GPU, you will achieve the best performance if your
|
||||
input script does not use any fix or compute styles which are not yet
|
||||
Kokkos-enabled. This allows data to stay on the GPU for multiple
|
||||
timesteps, without being copied back to the host CPU. Invoking a
|
||||
non-Kokkos fix or compute, or performing I/O for
|
||||
<a class="reference internal" href="thermo_style.html"><em>thermo</em></a> or <a class="reference internal" href="dump.html"><em>dump</em></a> output will cause data
|
||||
to be copied back to the CPU.</p>
|
||||
</div>
|
||||
<p>You cannot yet assign multiple MPI tasks to the same GPU with the
|
||||
KOKKOS package. We plan to support this in the future, similar to the
|
||||
GPU package in LAMMPS.</p>
|
||||
<p>You cannot yet use both the host (multi-threaded) and device (GPU)
|
||||
together to compute pairwise interactions with the KOKKOS package. We
|
||||
hope to support this in the future, similar to the GPU package in
|
||||
LAMMPS.</p>
|
||||
<p><strong>Running on an Intel Phi:</strong></p>
|
||||
<p>Kokkos only uses Intel Phi processors in their “native” mode, i.e.
|
||||
not hosted by a CPU.</p>
|
||||
<p>As illustrated above, build LAMMPS with OMP=yes (the default) and
|
||||
MIC=yes. The latter insures code is correctly compiled for the Intel
|
||||
Phi. The OMP setting means OpenMP will be used for parallelization on
|
||||
the Phi, which is currently the best option within Kokkos. In the
|
||||
future, other options may be added.</p>
|
||||
<p>Current-generation Intel Phi chips have either 61 or 57 cores. One
|
||||
core should be excluded for running the OS, leaving 60 or 56 cores.
|
||||
Each core is hyperthreaded, so there are effectively N = 240 (4*60) or
|
||||
N = 224 (4*56) cores to run on.</p>
|
||||
<p>The -np setting of the mpirun command sets the number of MPI
|
||||
tasks/node. The “-k on t Nt” command-line switch sets the number of
|
||||
threads/task as Nt. The product of these 2 values should be N, i.e.
|
||||
240 or 224. Also, the number of threads/task should be a multiple of
|
||||
4 so that logical threads from more than one MPI task do not run on
|
||||
the same physical core.</p>
|
||||
<p>Examples of mpirun commands that follow these rules are shown above.</p>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>As noted above, if using GPUs, the number of MPI tasks per compute
|
||||
node should equal to the number of GPUs per compute node. In the
|
||||
future Kokkos will support assigning multiple MPI tasks to a single
|
||||
GPU.</p>
|
||||
<p>Currently Kokkos does not support AMD GPUs due to limits in the
|
||||
available backend programming models. Specifically, Kokkos requires
|
||||
extensive C++ support from the Kernel language. This is expected to
|
||||
change in the future.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,510 +0,0 @@
|
||||
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
"Return to Section accelerate overview"_Section_accelerate.html
|
||||
|
||||
5.3.4 KOKKOS package :h4
|
||||
|
||||
The KOKKOS package was developed primarily by Christian Trott (Sandia)
|
||||
with contributions of various styles by others, including Sikandar
|
||||
Mashayak (UIUC), Stan Moore (Sandia), and Ray Shan (Sandia). The
|
||||
underlying Kokkos library was written primarily by Carter Edwards,
|
||||
Christian Trott, and Dan Sunderland (all Sandia).
|
||||
|
||||
The KOKKOS package contains versions of pair, fix, and atom styles
|
||||
that use data structures and macros provided by the Kokkos library,
|
||||
which is included with LAMMPS in lib/kokkos.
|
||||
|
||||
The Kokkos library is part of
|
||||
"Trilinos"_http://trilinos.sandia.gov/packages/kokkos and can also be
|
||||
downloaded from "Github"_https://github.com/kokkos/kokkos. Kokkos is a
|
||||
templated C++ library that provides two key abstractions for an
|
||||
application like LAMMPS. First, it allows a single implementation of
|
||||
an application kernel (e.g. a pair style) to run efficiently on
|
||||
different kinds of hardware, such as a GPU, Intel Phi, or many-core
|
||||
CPU.
|
||||
|
||||
The Kokkos library also provides data abstractions to adjust (at
|
||||
compile time) the memory layout of basic data structures like 2d and
|
||||
3d arrays and allow the transparent utilization of special hardware
|
||||
load and store operations. Such data structures are used in LAMMPS to
|
||||
store atom coordinates or forces or neighbor lists. The layout is
|
||||
chosen to optimize performance on different platforms. Again this
|
||||
functionality is hidden from the developer, and does not affect how
|
||||
the kernel is coded.
|
||||
|
||||
These abstractions are set at build time, when LAMMPS is compiled with
|
||||
the KOKKOS package installed. All Kokkos operations occur within the
|
||||
context of an individual MPI task running on a single node of the
|
||||
machine. The total number of MPI tasks used by LAMMPS (one or
|
||||
multiple per compute node) is set in the usual manner via the mpirun
|
||||
or mpiexec commands, and is independent of Kokkos.
|
||||
|
||||
Kokkos currently provides support for 3 modes of execution (per MPI
|
||||
task). These are OpenMP (for many-core CPUs), Cuda (for NVIDIA GPUs),
|
||||
and OpenMP (for Intel Phi). Note that the KOKKOS package supports
|
||||
running on the Phi in native mode, not offload mode like the
|
||||
USER-INTEL package supports. You choose the mode at build time to
|
||||
produce an executable compatible with specific hardware.
|
||||
|
||||
Here is a quick overview of how to use the KOKKOS package
|
||||
for CPU acceleration, assuming one or more 16-core nodes.
|
||||
More details follow.
|
||||
|
||||
use a C++11 compatible compiler
|
||||
make yes-kokkos
|
||||
make mpi KOKKOS_DEVICES=OpenMP # build with the KOKKOS package
|
||||
make kokkos_omp # or Makefile.kokkos_omp already has variable set
|
||||
Make.py -v -p kokkos -kokkos omp -o mpi -a file mpi # or one-line build via Make.py :pre
|
||||
|
||||
mpirun -np 16 lmp_mpi -k on -sf kk -in in.lj # 1 node, 16 MPI tasks/node, no threads
|
||||
mpirun -np 2 -ppn 1 lmp_mpi -k on t 16 -sf kk -in in.lj # 2 nodes, 1 MPI task/node, 16 threads/task
|
||||
mpirun -np 2 lmp_mpi -k on t 8 -sf kk -in in.lj # 1 node, 2 MPI tasks/node, 8 threads/task
|
||||
mpirun -np 32 -ppn 4 lmp_mpi -k on t 4 -sf kk -in in.lj # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
|
||||
|
||||
specify variables and settings in your Makefile.machine that enable OpenMP, GPU, or Phi support
|
||||
include the KOKKOS package and build LAMMPS
|
||||
enable the KOKKOS package and its hardware options via the "-k on" command-line switch use KOKKOS styles in your input script :ul
|
||||
|
||||
Here is a quick overview of how to use the KOKKOS package for GPUs,
|
||||
assuming one or more nodes, each with 16 cores and a GPU. More
|
||||
details follow.
|
||||
|
||||
discuss use of NVCC, which Makefiles to examine
|
||||
|
||||
use a C++11 compatible compiler
|
||||
KOKKOS_DEVICES = Cuda, OpenMP
|
||||
KOKKOS_ARCH = Kepler35
|
||||
make yes-kokkos
|
||||
make machine
|
||||
Make.py -p kokkos -kokkos cuda arch=31 -o kokkos_cuda -a file kokkos_cuda :pre
|
||||
|
||||
mpirun -np 1 lmp_cuda -k on t 6 -sf kk -in in.lj # one MPI task, 6 threads on CPU
|
||||
mpirun -np 4 -ppn 1 lmp_cuda -k on t 6 -sf kk -in in.lj # ditto on 4 nodes :pre
|
||||
|
||||
mpirun -np 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj # two MPI tasks, 8 threads per CPU
|
||||
mpirun -np 32 -ppn 2 lmp_cuda -k on t 8 g 2 -sf kk -in in.lj # ditto on 16 nodes :pre
|
||||
|
||||
Here is a quick overview of how to use the KOKKOS package
|
||||
for the Intel Phi:
|
||||
|
||||
use a C++11 compatible compiler
|
||||
KOKKOS_DEVICES = OpenMP
|
||||
KOKKOS_ARCH = KNC
|
||||
make yes-kokkos
|
||||
make machine
|
||||
Make.py -p kokkos -kokkos phi -o kokkos_phi -a file mpi :pre
|
||||
|
||||
host=MIC, Intel Phi with 61 cores (240 threads/phi via 4x hardware threading):
|
||||
mpirun -np 1 lmp_g++ -k on t 240 -sf kk -in in.lj # 1 MPI task on 1 Phi, 1*240 = 240
|
||||
mpirun -np 30 lmp_g++ -k on t 8 -sf kk -in in.lj # 30 MPI tasks on 1 Phi, 30*8 = 240
|
||||
mpirun -np 12 lmp_g++ -k on t 20 -sf kk -in in.lj # 12 MPI tasks on 1 Phi, 12*20 = 240
|
||||
mpirun -np 96 -ppn 12 lmp_g++ -k on t 20 -sf kk -in in.lj # ditto on 8 Phis :pre
|
||||
|
||||
[Required hardware/software:]
|
||||
|
||||
Kokkos support within LAMMPS must be built with a C++11 compatible
|
||||
compiler. If using gcc, version 4.8.1 or later is required.
|
||||
|
||||
To build with Kokkos support for CPUs, your compiler must support the
|
||||
OpenMP interface. You should have one or more multi-core CPUs so that
|
||||
multiple threads can be launched by each MPI task running on a CPU.
|
||||
|
||||
To build with Kokkos support for NVIDIA GPUs, NVIDIA Cuda software
|
||||
version 6.5 or later must be installed on your system. See the
|
||||
discussion for the "USER-CUDA"_accelerate_cuda.html and
|
||||
"GPU"_accelerate_gpu.html packages for details of how to check and do
|
||||
this.
|
||||
|
||||
NOTE: For good performance of the KOKKOS package on GPUs, you must
|
||||
have Kepler generation GPUs (or later). The Kokkos library exploits
|
||||
texture cache options not supported by Telsa generation GPUs (or
|
||||
older).
|
||||
|
||||
To build with Kokkos support for Intel Xeon Phi coprocessors, your
|
||||
sysmte must be configured to use them in "native" mode, not "offload"
|
||||
mode like the USER-INTEL package supports.
|
||||
|
||||
[Building LAMMPS with the KOKKOS package:]
|
||||
|
||||
You must choose at build time whether to build for CPUs (OpenMP),
|
||||
GPUs, or Phi.
|
||||
|
||||
You can do any of these in one line, using the src/Make.py script,
|
||||
described in "Section 2.4"_Section_start.html#start_4 of the manual.
|
||||
Type "Make.py -h" for help. If run from the src directory, these
|
||||
commands will create src/lmp_kokkos_omp, lmp_kokkos_cuda, and
|
||||
lmp_kokkos_phi. Note that the OMP and PHI options use
|
||||
src/MAKE/Makefile.mpi as the starting Makefile.machine. The CUDA
|
||||
option uses src/MAKE/OPTIONS/Makefile.kokkos_cuda.
|
||||
|
||||
The latter two steps can be done using the "-k on", "-pk kokkos" and
|
||||
"-sf kk" "command-line switches"_Section_start.html#start_7
|
||||
respectively. Or the effect of the "-pk" or "-sf" switches can be
|
||||
duplicated by adding the "package kokkos"_package.html or "suffix
|
||||
kk"_suffix.html commands respectively to your input script.
|
||||
|
||||
|
||||
Or you can follow these steps:
|
||||
|
||||
CPU-only (run all-MPI or with OpenMP threading):
|
||||
|
||||
cd lammps/src
|
||||
make yes-kokkos
|
||||
make g++ KOKKOS_DEVICES=OpenMP :pre
|
||||
|
||||
Intel Xeon Phi:
|
||||
|
||||
cd lammps/src
|
||||
make yes-kokkos
|
||||
make g++ KOKKOS_DEVICES=OpenMP KOKKOS_ARCH=KNC :pre
|
||||
|
||||
CPUs and GPUs:
|
||||
|
||||
cd lammps/src
|
||||
make yes-kokkos
|
||||
make cuda KOKKOS_DEVICES=Cuda :pre
|
||||
|
||||
These examples set the KOKKOS-specific OMP, MIC, CUDA variables on the
|
||||
make command line which requires a GNU-compatible make command. Try
|
||||
"gmake" if your system's standard make complains.
|
||||
|
||||
NOTE: If you build using make line variables and re-build LAMMPS twice
|
||||
with different KOKKOS options and the *same* target, e.g. g++ in the
|
||||
first two examples above, then you *must* perform a "make clean-all"
|
||||
or "make clean-machine" before each build. This is to force all the
|
||||
KOKKOS-dependent files to be re-compiled with the new options.
|
||||
|
||||
You can also hardwire these make variables in the specified machine
|
||||
makefile, e.g. src/MAKE/Makefile.g++ in the first two examples above,
|
||||
with a line like:
|
||||
|
||||
KOKKOS_ARCH = KNC :pre
|
||||
|
||||
Note that if you build LAMMPS multiple times in this manner, using
|
||||
different KOKKOS options (defined in different machine makefiles), you
|
||||
do not have to worry about doing a "clean" in between. This is
|
||||
because the targets will be different.
|
||||
|
||||
NOTE: The 3rd example above for a GPU, uses a different machine
|
||||
makefile, in this case src/MAKE/Makefile.cuda, which is included in
|
||||
the LAMMPS distribution. To build the KOKKOS package for a GPU, this
|
||||
makefile must use the NVIDA "nvcc" compiler. And it must have a
|
||||
KOKKOS_ARCH setting that is appropriate for your NVIDIA hardware and
|
||||
installed software. Typical values for KOKKOS_ARCH are given below,
|
||||
as well as other settings that must be included in the machine
|
||||
makefile, if you create your own.
|
||||
|
||||
NOTE: Currently, there are no precision options with the KOKKOS
|
||||
package. All compilation and computation is performed in double
|
||||
precision.
|
||||
|
||||
There are other allowed options when building with the KOKKOS package.
|
||||
As above, they can be set either as variables on the make command line
|
||||
or in Makefile.machine. This is the full list of options, including
|
||||
those discussed above, Each takes a value shown below. The
|
||||
default value is listed, which is set in the
|
||||
lib/kokkos/Makefile.kokkos file.
|
||||
|
||||
#Default settings specific options
|
||||
#Options: force_uvm,use_ldg,rdc
|
||||
|
||||
KOKKOS_DEVICES, values = {OpenMP}, {Serial}, {Pthreads}, {Cuda}, default = {OpenMP}
|
||||
KOKKOS_ARCH, values = {KNC}, {SNB}, {HSW}, {Kepler}, {Kepler30}, {Kepler32}, {Kepler35}, {Kepler37}, {Maxwell}, {Maxwell50}, {Maxwell52}, {Maxwell53}, {ARMv8}, {BGQ}, {Power7}, {Power8}, default = {none}
|
||||
KOKKOS_DEBUG, values = {yes}, {no}, default = {no}
|
||||
KOKKOS_USE_TPLS, values = {hwloc}, {librt}, default = {none}
|
||||
KOKKOS_CUDA_OPTIONS, values = {force_uvm}, {use_ldg}, {rdc} :ul
|
||||
|
||||
KOKKOS_DEVICE sets the parallelization method used for Kokkos code
|
||||
(within LAMMPS). KOKKOS_DEVICES=OpenMP means that OpenMP will be
|
||||
used. KOKKOS_DEVICES=Pthreads means that pthreads will be used.
|
||||
KOKKOS_DEVICES=Cuda means an NVIDIA GPU running CUDA will be used.
|
||||
|
||||
If KOKKOS_DEVICES=Cuda, then the lo-level Makefile in the src/MAKE
|
||||
directory must use "nvcc" as its compiler, via its CC setting. For
|
||||
best performance its CCFLAGS setting should use -O3 and have a
|
||||
KOKKOS_ARCH setting that matches the compute capability of your NVIDIA
|
||||
hardware and software installation, e.g. KOKKOS_ARCH=Kepler30. Note
|
||||
the minimal required compute capability is 2.0, but this will give
|
||||
signicantly reduced performance compared to Kepler generation GPUs
|
||||
with compute capability 3.x. For the LINK setting, "nvcc" should not
|
||||
be used; instead use g++ or another compiler suitable for linking C++
|
||||
applications. Often you will want to use your MPI compiler wrapper
|
||||
for this setting (i.e. mpicxx). Finally, the lo-level Makefile must
|
||||
also have a "Compilation rule" for creating *.o files from *.cu files.
|
||||
See src/Makefile.cuda for an example of a lo-level Makefile with all
|
||||
of these settings.
|
||||
|
||||
KOKKOS_USE_TPLS=hwloc binds threads to hardware cores, so they do not
|
||||
migrate during a simulation. KOKKOS_USE_TPLS=hwloc should always be
|
||||
used if running with KOKKOS_DEVICES=Pthreads for pthreads. It is not
|
||||
necessary for KOKKOS_DEVICES=OpenMP for OpenMP, because OpenMP
|
||||
provides alternative methods via environment variables for binding
|
||||
threads to hardware cores. More info on binding threads to cores is
|
||||
given in "this section"_Section_accelerate.html#acc_8.
|
||||
|
||||
KOKKOS_ARCH=KNC enables compiler switches needed when compling for an
|
||||
Intel Phi processor.
|
||||
|
||||
KOKKOS_USE_TPLS=librt enables use of a more accurate timer mechanism
|
||||
on most Unix platforms. This library is not available on all
|
||||
platforms.
|
||||
|
||||
KOKKOS_DEBUG is only useful when developing a Kokkos-enabled style
|
||||
within LAMMPS. KOKKOS_DEBUG=yes enables printing of run-time
|
||||
debugging information that can be useful. It also enables runtime
|
||||
bounds checking on Kokkos data structures.
|
||||
|
||||
KOKKOS_CUDA_OPTIONS are additional options for CUDA.
|
||||
|
||||
For more information on Kokkos see the Kokkos programmers' guide here:
|
||||
/lib/kokkos/doc/Kokkos_PG.pdf.
|
||||
|
||||
[Run with the KOKKOS package from the command line:]
|
||||
|
||||
The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
|
||||
|
||||
When using KOKKOS built with host=OMP, you need to choose how many
|
||||
OpenMP threads per MPI task will be used (via the "-k" command-line
|
||||
switch discussed below). Note that the product of MPI tasks * OpenMP
|
||||
threads/task should not exceed the physical number of cores (on a
|
||||
node), otherwise performance will suffer.
|
||||
|
||||
When using the KOKKOS package built with device=CUDA, you must use
|
||||
exactly one MPI task per physical GPU.
|
||||
|
||||
When using the KOKKOS package built with host=MIC for Intel Xeon Phi
|
||||
coprocessor support you need to insure there are one or more MPI tasks
|
||||
per coprocessor, and choose the number of coprocessor threads to use
|
||||
per MPI task (via the "-k" command-line switch discussed below). The
|
||||
product of MPI tasks * coprocessor threads/task should not exceed the
|
||||
maximum number of threads the coproprocessor is designed to run,
|
||||
otherwise performance will suffer. This value is 240 for current
|
||||
generation Xeon Phi(TM) chips, which is 60 physical cores * 4
|
||||
threads/core. Note that with the KOKKOS package you do not need to
|
||||
specify how many Phi coprocessors there are per node; each
|
||||
coprocessors is simply treated as running some number of MPI tasks.
|
||||
|
||||
You must use the "-k on" "command-line
|
||||
switch"_Section_start.html#start_7 to enable the KOKKOS package. It
|
||||
takes additional arguments for hardware settings appropriate to your
|
||||
system. Those arguments are "documented
|
||||
here"_Section_start.html#start_7. The two most commonly used
|
||||
options are:
|
||||
|
||||
-k on t Nt g Ng :pre
|
||||
|
||||
The "t Nt" option applies to host=OMP (even if device=CUDA) and
|
||||
host=MIC. For host=OMP, it specifies how many OpenMP threads per MPI
|
||||
task to use with a node. For host=MIC, it specifies how many Xeon Phi
|
||||
threads per MPI task to use within a node. The default is Nt = 1.
|
||||
Note that for host=OMP this is effectively MPI-only mode which may be
|
||||
fine. But for host=MIC you will typically end up using far less than
|
||||
all the 240 available threads, which could give very poor performance.
|
||||
|
||||
The "g Ng" option applies to device=CUDA. It specifies how many GPUs
|
||||
per compute node to use. The default is 1, so this only needs to be
|
||||
specified is you have 2 or more GPUs per compute node.
|
||||
|
||||
The "-k on" switch also issues a "package kokkos" command (with no
|
||||
additional arguments) which sets various KOKKOS options to default
|
||||
values, as discussed on the "package"_package.html command doc page.
|
||||
|
||||
Use the "-sf kk" "command-line switch"_Section_start.html#start_7,
|
||||
which will automatically append "kk" to styles that support it. Use
|
||||
the "-pk kokkos" "command-line switch"_Section_start.html#start_7 if
|
||||
you wish to change any of the default "package kokkos"_package.html
|
||||
optionns set by the "-k on" "command-line
|
||||
switch"_Section_start.html#start_7.
|
||||
|
||||
|
||||
|
||||
Note that the default for the "package kokkos"_package.html command is
|
||||
to use "full" neighbor lists and set the Newton flag to "off" for both
|
||||
pairwise and bonded interactions. This typically gives fastest
|
||||
performance. If the "newton"_newton.html command is used in the input
|
||||
script, it can override the Newton flag defaults.
|
||||
|
||||
However, when running in MPI-only mode with 1 thread per MPI task, it
|
||||
will typically be faster to use "half" neighbor lists and set the
|
||||
Newton flag to "on", just as is the case for non-accelerated pair
|
||||
styles. You can do this with the "-pk" "command-line
|
||||
switch"_Section_start.html#start_7.
|
||||
|
||||
[Or run with the KOKKOS package by editing an input script:]
|
||||
|
||||
The discussion above for the mpirun/mpiexec command and setting
|
||||
appropriate thread and GPU values for host=OMP or host=MIC or
|
||||
device=CUDA are the same.
|
||||
|
||||
You must still use the "-k on" "command-line
|
||||
switch"_Section_start.html#start_7 to enable the KOKKOS package, and
|
||||
specify its additional arguments for hardware options appopriate to
|
||||
your system, as documented above.
|
||||
|
||||
Use the "suffix kk"_suffix.html command, or you can explicitly add a
|
||||
"kk" suffix to individual styles in your input script, e.g.
|
||||
|
||||
pair_style lj/cut/kk 2.5 :pre
|
||||
|
||||
You only need to use the "package kokkos"_package.html command if you
|
||||
wish to change any of its option defaults, as set by the "-k on"
|
||||
"command-line switch"_Section_start.html#start_7.
|
||||
|
||||
[Speed-ups to expect:]
|
||||
|
||||
The performance of KOKKOS running in different modes is a function of
|
||||
your hardware, which KOKKOS-enable styles are used, and the problem
|
||||
size.
|
||||
|
||||
Generally speaking, the following rules of thumb apply:
|
||||
|
||||
When running on CPUs only, with a single thread per MPI task,
|
||||
performance of a KOKKOS style is somewhere between the standard
|
||||
(un-accelerated) styles (MPI-only mode), and those provided by the
|
||||
USER-OMP package. However the difference between all 3 is small (less
|
||||
than 20%). :ulb,l
|
||||
|
||||
When running on CPUs only, with multiple threads per MPI task,
|
||||
performance of a KOKKOS style is a bit slower than the USER-OMP
|
||||
package. :l
|
||||
|
||||
When running on GPUs, KOKKOS is typically faster than the USER-CUDA
|
||||
and GPU packages. :l
|
||||
|
||||
When running on Intel Xeon Phi, KOKKOS is not as fast as
|
||||
the USER-INTEL package, which is optimized for that hardware. :l,ule
|
||||
|
||||
See the "Benchmark page"_http://lammps.sandia.gov/bench.html of the
|
||||
LAMMPS web site for performance of the KOKKOS package on different
|
||||
hardware.
|
||||
|
||||
[Guidelines for best performance:]
|
||||
|
||||
Here are guidline for using the KOKKOS package on the different
|
||||
hardware configurations listed above.
|
||||
|
||||
Many of the guidelines use the "package kokkos"_package.html command
|
||||
See its doc page for details and default settings. Experimenting with
|
||||
its options can provide a speed-up for specific calculations.
|
||||
|
||||
[Running on a multi-core CPU:]
|
||||
|
||||
If N is the number of physical cores/node, then the number of MPI
|
||||
tasks/node * number of threads/task should not exceed N, and should
|
||||
typically equal N. Note that the default threads/task is 1, as set by
|
||||
the "t" keyword of the "-k" "command-line
|
||||
switch"_Section_start.html#start_7. If you do not change this, no
|
||||
additional parallelism (beyond MPI) will be invoked on the host
|
||||
CPU(s).
|
||||
|
||||
You can compare the performance running in different modes:
|
||||
|
||||
run with 1 MPI task/node and N threads/task
|
||||
run with N MPI tasks/node and 1 thread/task
|
||||
run with settings in between these extremes :ul
|
||||
|
||||
Examples of mpirun commands in these modes are shown above.
|
||||
|
||||
When using KOKKOS to perform multi-threading, it is important for
|
||||
performance to bind both MPI tasks to physical cores, and threads to
|
||||
physical cores, so they do not migrate during a simulation.
|
||||
|
||||
If you are not certain MPI tasks are being bound (check the defaults
|
||||
for your MPI installation), binding can be forced with these flags:
|
||||
|
||||
OpenMPI 1.8: mpirun -np 2 -bind-to socket -map-by socket ./lmp_openmpi ...
|
||||
Mvapich2 2.0: mpiexec -np 2 -bind-to socket -map-by socket ./lmp_mvapich ... :pre
|
||||
|
||||
For binding threads with the KOKKOS OMP option, use thread affinity
|
||||
environment variables to force binding. With OpenMP 3.1 (gcc 4.7 or
|
||||
later, intel 12 or later) setting the environment variable
|
||||
OMP_PROC_BIND=true should be sufficient. For binding threads with the
|
||||
KOKKOS pthreads option, compile LAMMPS the KOKKOS HWLOC=yes option, as
|
||||
discussed in "Section 2.3.4"_Sections_start.html#start_3_4 of the
|
||||
manual.
|
||||
|
||||
[Running on GPUs:]
|
||||
|
||||
Insure the -arch setting in the machine makefile you are using,
|
||||
e.g. src/MAKE/Makefile.cuda, is correct for your GPU hardware/software
|
||||
(see "this section"_Section_start.html#start_3_4 of the manual for
|
||||
details).
|
||||
|
||||
The -np setting of the mpirun command should set the number of MPI
|
||||
tasks/node to be equal to the # of physical GPUs on the node.
|
||||
|
||||
Use the "-k" "command-line switch"_Section_commands.html#start_7 to
|
||||
specify the number of GPUs per node, and the number of threads per MPI
|
||||
task. As above for multi-core CPUs (and no GPU), if N is the number
|
||||
of physical cores/node, then the number of MPI tasks/node * number of
|
||||
threads/task should not exceed N. With one GPU (and one MPI task) it
|
||||
may be faster to use less than all the available cores, by setting
|
||||
threads/task to a smaller value. This is because using all the cores
|
||||
on a dual-socket node will incur extra cost to copy memory from the
|
||||
2nd socket to the GPU.
|
||||
|
||||
Examples of mpirun commands that follow these rules are shown above.
|
||||
|
||||
NOTE: When using a GPU, you will achieve the best performance if your
|
||||
input script does not use any fix or compute styles which are not yet
|
||||
Kokkos-enabled. This allows data to stay on the GPU for multiple
|
||||
timesteps, without being copied back to the host CPU. Invoking a
|
||||
non-Kokkos fix or compute, or performing I/O for
|
||||
"thermo"_thermo_style.html or "dump"_dump.html output will cause data
|
||||
to be copied back to the CPU.
|
||||
|
||||
You cannot yet assign multiple MPI tasks to the same GPU with the
|
||||
KOKKOS package. We plan to support this in the future, similar to the
|
||||
GPU package in LAMMPS.
|
||||
|
||||
You cannot yet use both the host (multi-threaded) and device (GPU)
|
||||
together to compute pairwise interactions with the KOKKOS package. We
|
||||
hope to support this in the future, similar to the GPU package in
|
||||
LAMMPS.
|
||||
|
||||
[Running on an Intel Phi:]
|
||||
|
||||
Kokkos only uses Intel Phi processors in their "native" mode, i.e.
|
||||
not hosted by a CPU.
|
||||
|
||||
As illustrated above, build LAMMPS with OMP=yes (the default) and
|
||||
MIC=yes. The latter insures code is correctly compiled for the Intel
|
||||
Phi. The OMP setting means OpenMP will be used for parallelization on
|
||||
the Phi, which is currently the best option within Kokkos. In the
|
||||
future, other options may be added.
|
||||
|
||||
Current-generation Intel Phi chips have either 61 or 57 cores. One
|
||||
core should be excluded for running the OS, leaving 60 or 56 cores.
|
||||
Each core is hyperthreaded, so there are effectively N = 240 (4*60) or
|
||||
N = 224 (4*56) cores to run on.
|
||||
|
||||
The -np setting of the mpirun command sets the number of MPI
|
||||
tasks/node. The "-k on t Nt" command-line switch sets the number of
|
||||
threads/task as Nt. The product of these 2 values should be N, i.e.
|
||||
240 or 224. Also, the number of threads/task should be a multiple of
|
||||
4 so that logical threads from more than one MPI task do not run on
|
||||
the same physical core.
|
||||
|
||||
Examples of mpirun commands that follow these rules are shown above.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
As noted above, if using GPUs, the number of MPI tasks per compute
|
||||
node should equal to the number of GPUs per compute node. In the
|
||||
future Kokkos will support assigning multiple MPI tasks to a single
|
||||
GPU.
|
||||
|
||||
Currently Kokkos does not support AMD GPUs due to limits in the
|
||||
available backend programming models. Specifically, Kokkos requires
|
||||
extensive C++ support from the Kernel language. This is expected to
|
||||
change in the future.
|
||||
@ -1,337 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>5.USER-OMP package — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>5.USER-OMP package</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<p><a class="reference internal" href="Section_accelerate.html"><em>Return to Section accelerate overview</em></a></p>
|
||||
<div class="section" id="user-omp-package">
|
||||
<h1>5.USER-OMP package<a class="headerlink" href="#user-omp-package" title="Permalink to this headline">¶</a></h1>
|
||||
<p>The USER-OMP package was developed by Axel Kohlmeyer at Temple
|
||||
University. It provides multi-threaded versions of most pair styles,
|
||||
nearly all bonded styles (bond, angle, dihedral, improper), several
|
||||
Kspace styles, and a few fix styles. The package currently uses the
|
||||
OpenMP interface for multi-threading.</p>
|
||||
<p>Here is a quick overview of how to use the USER-OMP package, assuming
|
||||
one or more 16-core nodes. More details follow.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>use -fopenmp with CCFLAGS and LINKFLAGS in Makefile.machine
|
||||
make yes-user-omp
|
||||
make mpi # build with USER-OMP package, if settings added to Makefile.mpi
|
||||
make omp # or Makefile.omp already has settings
|
||||
Make.py -v -p omp -o mpi -a file mpi # or one-line build via Make.py
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>lmp_mpi -sf omp -pk omp 16 < in.script # 1 MPI task, 16 threads
|
||||
mpirun -np 4 lmp_mpi -sf omp -pk omp 4 -in in.script # 4 MPI tasks, 4 threads/task
|
||||
mpirun -np 32 -ppn 4 lmp_mpi -sf omp -pk omp 4 -in in.script # 8 nodes, 4 MPI tasks/node, 4 threads/task
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>Required hardware/software:</strong></p>
|
||||
<p>Your compiler must support the OpenMP interface. You should have one
|
||||
or more multi-core CPUs so that multiple threads can be launched by
|
||||
each MPI task running on a CPU.</p>
|
||||
<p><strong>Building LAMMPS with the USER-OMP package:</strong></p>
|
||||
<p>The lines above illustrate how to include/build with the USER-OMP
|
||||
package in two steps, using the “make” command. Or how to do it with
|
||||
one command via the src/Make.py script, described in <a class="reference internal" href="Section_start.html#start-4"><span>Section 2.4</span></a> of the manual. Type “Make.py -h” for
|
||||
help.</p>
|
||||
<p>Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
|
||||
include “-fopenmp”. Likewise, if you use an Intel compiler, the
|
||||
CCFLAGS setting must include “-restrict”. The Make.py command will
|
||||
add these automatically.</p>
|
||||
<p><strong>Run with the USER-OMP package from the command line:</strong></p>
|
||||
<p>The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.</p>
|
||||
<p>You need to choose how many OpenMP threads per MPI task will be used
|
||||
by the USER-OMP package. Note that the product of MPI tasks *
|
||||
threads/task should not exceed the physical number of cores (on a
|
||||
node), otherwise performance will suffer.</p>
|
||||
<p>As in the lines above, use the “-sf omp” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>, which will automatically append
|
||||
“omp” to styles that support it. The “-sf omp” switch also issues a
|
||||
default <a class="reference internal" href="package.html"><em>package omp 0</em></a> command, which will set the
|
||||
number of threads per MPI task via the OMP_NUM_THREADS environment
|
||||
variable.</p>
|
||||
<p>You can also use the “-pk omp Nt” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>, to explicitly set Nt = # of OpenMP
|
||||
threads per MPI task to use, as well as additional options. Its
|
||||
syntax is the same as the <a class="reference internal" href="package.html"><em>package omp</em></a> command whose doc
|
||||
page gives details, including the default values used if it is not
|
||||
specified. It also gives more details on how to set the number of
|
||||
threads via the OMP_NUM_THREADS environment variable.</p>
|
||||
<p><strong>Or run with the USER-OMP package by editing an input script:</strong></p>
|
||||
<p>The discussion above for the mpirun/mpiexec command, MPI tasks/node,
|
||||
and threads/MPI task is the same.</p>
|
||||
<p>Use the <a class="reference internal" href="suffix.html"><em>suffix omp</em></a> command, or you can explicitly add an
|
||||
“omp” suffix to individual styles in your input script, e.g.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>pair_style lj/cut/omp 2.5
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>You must also use the <a class="reference internal" href="package.html"><em>package omp</em></a> command to enable the
|
||||
USER-OMP package. When you do this you also specify how many threads
|
||||
per MPI task to use. The command doc page explains other options and
|
||||
how to set the number of threads via the OMP_NUM_THREADS environment
|
||||
variable.</p>
|
||||
<p><strong>Speed-ups to expect:</strong></p>
|
||||
<p>Depending on which styles are accelerated, you should look for a
|
||||
reduction in the “Pair time”, “Bond time”, “KSpace time”, and “Loop
|
||||
time” values printed at the end of a run.</p>
|
||||
<p>You may see a small performance advantage (5 to 20%) when running a
|
||||
USER-OMP style (in serial or parallel) with a single thread per MPI
|
||||
task, versus running standard LAMMPS with its standard un-accelerated
|
||||
styles (in serial or all-MPI parallelization with 1 task/core). This
|
||||
is because many of the USER-OMP styles contain similar optimizations
|
||||
to those used in the OPT package, described in <a class="reference internal" href="accelerate_opt.html"><em>Section accelerate 5.3.6</em></a>.</p>
|
||||
<p>With multiple threads/task, the optimal choice of number of MPI
|
||||
tasks/node and OpenMP threads/task can vary a lot and should always be
|
||||
tested via benchmark runs for a specific simulation running on a
|
||||
specific machine, paying attention to guidelines discussed in the next
|
||||
sub-section.</p>
|
||||
<p>A description of the multi-threading strategy used in the USER-OMP
|
||||
package and some performance examples are <a class="reference external" href="http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1">presented here</a></p>
|
||||
<p><strong>Guidelines for best performance:</strong></p>
|
||||
<p>For many problems on current generation CPUs, running the USER-OMP
|
||||
package with a single thread/task is faster than running with multiple
|
||||
threads/task. This is because the MPI parallelization in LAMMPS is
|
||||
often more efficient than multi-threading as implemented in the
|
||||
USER-OMP package. The parallel efficiency (in a threaded sense) also
|
||||
varies for different USER-OMP styles.</p>
|
||||
<p>Using multiple threads/task can be more effective under the following
|
||||
circumstances:</p>
|
||||
<ul class="simple">
|
||||
<li>Individual compute nodes have a significant number of CPU cores but
|
||||
the CPU itself has limited memory bandwidth, e.g. for Intel Xeon 53xx
|
||||
(Clovertown) and 54xx (Harpertown) quad-core processors. Running one
|
||||
MPI task per CPU core will result in significant performance
|
||||
degradation, so that running with 4 or even only 2 MPI tasks per node
|
||||
is faster. Running in hybrid MPI+OpenMP mode will reduce the
|
||||
inter-node communication bandwidth contention in the same way, but
|
||||
offers an additional speedup by utilizing the otherwise idle CPU
|
||||
cores.</li>
|
||||
<li>The interconnect used for MPI communication does not provide
|
||||
sufficient bandwidth for a large number of MPI tasks per node. For
|
||||
example, this applies to running over gigabit ethernet or on Cray XT4
|
||||
or XT5 series supercomputers. As in the aforementioned case, this
|
||||
effect worsens when using an increasing number of nodes.</li>
|
||||
<li>The system has a spatially inhomogeneous particle density which does
|
||||
not map well to the <a class="reference internal" href="processors.html"><em>domain decomposition scheme</em></a> or
|
||||
<a class="reference internal" href="balance.html"><em>load-balancing</em></a> options that LAMMPS provides. This is
|
||||
because multi-threading achives parallelism over the number of
|
||||
particles, not via their distribution in space.</li>
|
||||
<li>A machine is being used in “capability mode”, i.e. near the point
|
||||
where MPI parallelism is maxed out. For example, this can happen when
|
||||
using the <a class="reference internal" href="kspace_style.html"><em>PPPM solver</em></a> for long-range
|
||||
electrostatics on large numbers of nodes. The scaling of the KSpace
|
||||
calculation (see the <a class="reference internal" href="kspace_style.html"><em>kspace_style</em></a> command) becomes
|
||||
the performance-limiting factor. Using multi-threading allows less
|
||||
MPI tasks to be invoked and can speed-up the long-range solver, while
|
||||
increasing overall performance by parallelizing the pairwise and
|
||||
bonded calculations via OpenMP. Likewise additional speedup can be
|
||||
sometimes be achived by increasing the length of the Coulombic cutoff
|
||||
and thus reducing the work done by the long-range solver. Using the
|
||||
<a class="reference internal" href="run_style.html"><em>run_style verlet/split</em></a> command, which is compatible
|
||||
with the USER-OMP package, is an alternative way to reduce the number
|
||||
of MPI tasks assigned to the KSpace calculation.</li>
|
||||
</ul>
|
||||
<p>Additional performance tips are as follows:</p>
|
||||
<ul class="simple">
|
||||
<li>The best parallel efficiency from <em>omp</em> styles is typically achieved
|
||||
when there is at least one MPI task per physical CPU chip, i.e. socket
|
||||
or die.</li>
|
||||
<li>It is usually most efficient to restrict threading to a single
|
||||
socket, i.e. use one or more MPI task per socket.</li>
|
||||
<li>NOTE: By default, several current MPI implementations use a processor
|
||||
affinity setting that restricts each MPI task to a single CPU core.
|
||||
Using multi-threading in this mode will force all threads to share the
|
||||
one core and thus is likely to be counterproductive. Instead, binding
|
||||
MPI tasks to a (multi-core) socket, should solve this issue.</li>
|
||||
</ul>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>None.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,185 +0,0 @@
|
||||
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
"Return to Section accelerate overview"_Section_accelerate.html
|
||||
|
||||
5.3.5 USER-OMP package :h4
|
||||
|
||||
The USER-OMP package was developed by Axel Kohlmeyer at Temple
|
||||
University. It provides multi-threaded versions of most pair styles,
|
||||
nearly all bonded styles (bond, angle, dihedral, improper), several
|
||||
Kspace styles, and a few fix styles. The package currently uses the
|
||||
OpenMP interface for multi-threading.
|
||||
|
||||
Here is a quick overview of how to use the USER-OMP package, assuming
|
||||
one or more 16-core nodes. More details follow.
|
||||
|
||||
use -fopenmp with CCFLAGS and LINKFLAGS in Makefile.machine
|
||||
make yes-user-omp
|
||||
make mpi # build with USER-OMP package, if settings added to Makefile.mpi
|
||||
make omp # or Makefile.omp already has settings
|
||||
Make.py -v -p omp -o mpi -a file mpi # or one-line build via Make.py :pre
|
||||
|
||||
lmp_mpi -sf omp -pk omp 16 < in.script # 1 MPI task, 16 threads
|
||||
mpirun -np 4 lmp_mpi -sf omp -pk omp 4 -in in.script # 4 MPI tasks, 4 threads/task
|
||||
mpirun -np 32 -ppn 4 lmp_mpi -sf omp -pk omp 4 -in in.script # 8 nodes, 4 MPI tasks/node, 4 threads/task :pre
|
||||
|
||||
[Required hardware/software:]
|
||||
|
||||
Your compiler must support the OpenMP interface. You should have one
|
||||
or more multi-core CPUs so that multiple threads can be launched by
|
||||
each MPI task running on a CPU.
|
||||
|
||||
[Building LAMMPS with the USER-OMP package:]
|
||||
|
||||
The lines above illustrate how to include/build with the USER-OMP
|
||||
package in two steps, using the "make" command. Or how to do it with
|
||||
one command via the src/Make.py script, described in "Section
|
||||
2.4"_Section_start.html#start_4 of the manual. Type "Make.py -h" for
|
||||
help.
|
||||
|
||||
Note that the CCFLAGS and LINKFLAGS settings in Makefile.machine must
|
||||
include "-fopenmp". Likewise, if you use an Intel compiler, the
|
||||
CCFLAGS setting must include "-restrict". The Make.py command will
|
||||
add these automatically.
|
||||
|
||||
[Run with the USER-OMP package from the command line:]
|
||||
|
||||
The mpirun or mpiexec command sets the total number of MPI tasks used
|
||||
by LAMMPS (one or multiple per compute node) and the number of MPI
|
||||
tasks used per node. E.g. the mpirun command in MPICH does this via
|
||||
its -np and -ppn switches. Ditto for OpenMPI via -np and -npernode.
|
||||
|
||||
You need to choose how many OpenMP threads per MPI task will be used
|
||||
by the USER-OMP package. Note that the product of MPI tasks *
|
||||
threads/task should not exceed the physical number of cores (on a
|
||||
node), otherwise performance will suffer.
|
||||
|
||||
As in the lines above, use the "-sf omp" "command-line
|
||||
switch"_Section_start.html#start_7, which will automatically append
|
||||
"omp" to styles that support it. The "-sf omp" switch also issues a
|
||||
default "package omp 0"_package.html command, which will set the
|
||||
number of threads per MPI task via the OMP_NUM_THREADS environment
|
||||
variable.
|
||||
|
||||
You can also use the "-pk omp Nt" "command-line
|
||||
switch"_Section_start.html#start_7, to explicitly set Nt = # of OpenMP
|
||||
threads per MPI task to use, as well as additional options. Its
|
||||
syntax is the same as the "package omp"_package.html command whose doc
|
||||
page gives details, including the default values used if it is not
|
||||
specified. It also gives more details on how to set the number of
|
||||
threads via the OMP_NUM_THREADS environment variable.
|
||||
|
||||
[Or run with the USER-OMP package by editing an input script:]
|
||||
|
||||
The discussion above for the mpirun/mpiexec command, MPI tasks/node,
|
||||
and threads/MPI task is the same.
|
||||
|
||||
Use the "suffix omp"_suffix.html command, or you can explicitly add an
|
||||
"omp" suffix to individual styles in your input script, e.g.
|
||||
|
||||
pair_style lj/cut/omp 2.5 :pre
|
||||
|
||||
You must also use the "package omp"_package.html command to enable the
|
||||
USER-OMP package. When you do this you also specify how many threads
|
||||
per MPI task to use. The command doc page explains other options and
|
||||
how to set the number of threads via the OMP_NUM_THREADS environment
|
||||
variable.
|
||||
|
||||
[Speed-ups to expect:]
|
||||
|
||||
Depending on which styles are accelerated, you should look for a
|
||||
reduction in the "Pair time", "Bond time", "KSpace time", and "Loop
|
||||
time" values printed at the end of a run.
|
||||
|
||||
You may see a small performance advantage (5 to 20%) when running a
|
||||
USER-OMP style (in serial or parallel) with a single thread per MPI
|
||||
task, versus running standard LAMMPS with its standard un-accelerated
|
||||
styles (in serial or all-MPI parallelization with 1 task/core). This
|
||||
is because many of the USER-OMP styles contain similar optimizations
|
||||
to those used in the OPT package, described in "Section accelerate
|
||||
5.3.6"_accelerate_opt.html.
|
||||
|
||||
With multiple threads/task, the optimal choice of number of MPI
|
||||
tasks/node and OpenMP threads/task can vary a lot and should always be
|
||||
tested via benchmark runs for a specific simulation running on a
|
||||
specific machine, paying attention to guidelines discussed in the next
|
||||
sub-section.
|
||||
|
||||
A description of the multi-threading strategy used in the USER-OMP
|
||||
package and some performance examples are "presented
|
||||
here"_http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1
|
||||
|
||||
[Guidelines for best performance:]
|
||||
|
||||
For many problems on current generation CPUs, running the USER-OMP
|
||||
package with a single thread/task is faster than running with multiple
|
||||
threads/task. This is because the MPI parallelization in LAMMPS is
|
||||
often more efficient than multi-threading as implemented in the
|
||||
USER-OMP package. The parallel efficiency (in a threaded sense) also
|
||||
varies for different USER-OMP styles.
|
||||
|
||||
Using multiple threads/task can be more effective under the following
|
||||
circumstances:
|
||||
|
||||
Individual compute nodes have a significant number of CPU cores but
|
||||
the CPU itself has limited memory bandwidth, e.g. for Intel Xeon 53xx
|
||||
(Clovertown) and 54xx (Harpertown) quad-core processors. Running one
|
||||
MPI task per CPU core will result in significant performance
|
||||
degradation, so that running with 4 or even only 2 MPI tasks per node
|
||||
is faster. Running in hybrid MPI+OpenMP mode will reduce the
|
||||
inter-node communication bandwidth contention in the same way, but
|
||||
offers an additional speedup by utilizing the otherwise idle CPU
|
||||
cores. :ulb,l
|
||||
|
||||
The interconnect used for MPI communication does not provide
|
||||
sufficient bandwidth for a large number of MPI tasks per node. For
|
||||
example, this applies to running over gigabit ethernet or on Cray XT4
|
||||
or XT5 series supercomputers. As in the aforementioned case, this
|
||||
effect worsens when using an increasing number of nodes. :l
|
||||
|
||||
The system has a spatially inhomogeneous particle density which does
|
||||
not map well to the "domain decomposition scheme"_processors.html or
|
||||
"load-balancing"_balance.html options that LAMMPS provides. This is
|
||||
because multi-threading achives parallelism over the number of
|
||||
particles, not via their distribution in space. :l
|
||||
|
||||
A machine is being used in "capability mode", i.e. near the point
|
||||
where MPI parallelism is maxed out. For example, this can happen when
|
||||
using the "PPPM solver"_kspace_style.html for long-range
|
||||
electrostatics on large numbers of nodes. The scaling of the KSpace
|
||||
calculation (see the "kspace_style"_kspace_style.html command) becomes
|
||||
the performance-limiting factor. Using multi-threading allows less
|
||||
MPI tasks to be invoked and can speed-up the long-range solver, while
|
||||
increasing overall performance by parallelizing the pairwise and
|
||||
bonded calculations via OpenMP. Likewise additional speedup can be
|
||||
sometimes be achived by increasing the length of the Coulombic cutoff
|
||||
and thus reducing the work done by the long-range solver. Using the
|
||||
"run_style verlet/split"_run_style.html command, which is compatible
|
||||
with the USER-OMP package, is an alternative way to reduce the number
|
||||
of MPI tasks assigned to the KSpace calculation. :l,ule
|
||||
|
||||
Additional performance tips are as follows:
|
||||
|
||||
The best parallel efficiency from {omp} styles is typically achieved
|
||||
when there is at least one MPI task per physical CPU chip, i.e. socket
|
||||
or die. :ulb,l
|
||||
|
||||
It is usually most efficient to restrict threading to a single
|
||||
socket, i.e. use one or more MPI task per socket. :l
|
||||
|
||||
NOTE: By default, several current MPI implementations use a processor
|
||||
affinity setting that restricts each MPI task to a single CPU core.
|
||||
Using multi-threading in this mode will force all threads to share the
|
||||
one core and thus is likely to be counterproductive. Instead, binding
|
||||
MPI tasks to a (multi-core) socket, should solve this issue. :l,ule
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
None.
|
||||
@ -1,239 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>5.OPT package — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>5.OPT package</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<p><a class="reference internal" href="Section_accelerate.html"><em>Return to Section accelerate overview</em></a></p>
|
||||
<div class="section" id="opt-package">
|
||||
<h1>5.OPT package<a class="headerlink" href="#opt-package" title="Permalink to this headline">¶</a></h1>
|
||||
<p>The OPT package was developed by James Fischer (High Performance
|
||||
Technologies), David Richie, and Vincent Natoli (Stone Ridge
|
||||
Technologies). It contains a handful of pair styles whose compute()
|
||||
methods were rewritten in C++ templated form to reduce the overhead
|
||||
due to if tests and other conditional code.</p>
|
||||
<p>Here is a quick overview of how to use the OPT package. More details
|
||||
follow.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>make yes-opt
|
||||
make mpi # build with the OPT package
|
||||
Make.py -v -p opt -o mpi -a file mpi # or one-line build via Make.py
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>lmp_mpi -sf opt -in in.script # run in serial
|
||||
mpirun -np 4 lmp_mpi -sf opt -in in.script # run in parallel
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>Required hardware/software:</strong></p>
|
||||
<p>None.</p>
|
||||
<p><strong>Building LAMMPS with the OPT package:</strong></p>
|
||||
<p>The lines above illustrate how to build LAMMPS with the OPT package in
|
||||
two steps, using the “make” command. Or how to do it with one command
|
||||
via the src/Make.py script, described in <a class="reference internal" href="Section_start.html#start-4"><span>Section 2.4</span></a> of the manual. Type “Make.py -h” for
|
||||
help.</p>
|
||||
<p>Note that if you use an Intel compiler to build with the OPT package,
|
||||
the CCFLAGS setting in your Makefile.machine must include “-restrict”.
|
||||
The Make.py command will add this automatically.</p>
|
||||
<p><strong>Run with the OPT package from the command line:</strong></p>
|
||||
<p>As in the lines above, use the “-sf opt” <a class="reference internal" href="Section_start.html#start-7"><span>command-line switch</span></a>, which will automatically append
|
||||
“opt” to styles that support it.</p>
|
||||
<p><strong>Or run with the OPT package by editing an input script:</strong></p>
|
||||
<p>Use the <a class="reference internal" href="suffix.html"><em>suffix opt</em></a> command, or you can explicitly add an
|
||||
“opt” suffix to individual styles in your input script, e.g.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>pair_style lj/cut/opt 2.5
|
||||
</pre></div>
|
||||
</div>
|
||||
<p><strong>Speed-ups to expect:</strong></p>
|
||||
<p>You should see a reduction in the “Pair time” value printed at the end
|
||||
of a run. On most machines for reasonable problem sizes, it will be a
|
||||
5 to 20% savings.</p>
|
||||
<p><strong>Guidelines for best performance:</strong></p>
|
||||
<p>Just try out an OPT pair style to see how it performs.</p>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>None.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,71 +0,0 @@
|
||||
"Previous Section"_Section_packages.html - "LAMMPS WWW Site"_lws -
|
||||
"LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
"Return to Section accelerate overview"_Section_accelerate.html
|
||||
|
||||
5.3.6 OPT package :h4
|
||||
|
||||
The OPT package was developed by James Fischer (High Performance
|
||||
Technologies), David Richie, and Vincent Natoli (Stone Ridge
|
||||
Technologies). It contains a handful of pair styles whose compute()
|
||||
methods were rewritten in C++ templated form to reduce the overhead
|
||||
due to if tests and other conditional code.
|
||||
|
||||
Here is a quick overview of how to use the OPT package. More details
|
||||
follow.
|
||||
|
||||
make yes-opt
|
||||
make mpi # build with the OPT package
|
||||
Make.py -v -p opt -o mpi -a file mpi # or one-line build via Make.py :pre
|
||||
|
||||
lmp_mpi -sf opt -in in.script # run in serial
|
||||
mpirun -np 4 lmp_mpi -sf opt -in in.script # run in parallel :pre
|
||||
|
||||
[Required hardware/software:]
|
||||
|
||||
None.
|
||||
|
||||
[Building LAMMPS with the OPT package:]
|
||||
|
||||
The lines above illustrate how to build LAMMPS with the OPT package in
|
||||
two steps, using the "make" command. Or how to do it with one command
|
||||
via the src/Make.py script, described in "Section
|
||||
2.4"_Section_start.html#start_4 of the manual. Type "Make.py -h" for
|
||||
help.
|
||||
|
||||
Note that if you use an Intel compiler to build with the OPT package,
|
||||
the CCFLAGS setting in your Makefile.machine must include "-restrict".
|
||||
The Make.py command will add this automatically.
|
||||
|
||||
[Run with the OPT package from the command line:]
|
||||
|
||||
As in the lines above, use the "-sf opt" "command-line
|
||||
switch"_Section_start.html#start_7, which will automatically append
|
||||
"opt" to styles that support it.
|
||||
|
||||
[Or run with the OPT package by editing an input script:]
|
||||
|
||||
Use the "suffix opt"_suffix.html command, or you can explicitly add an
|
||||
"opt" suffix to individual styles in your input script, e.g.
|
||||
|
||||
pair_style lj/cut/opt 2.5 :pre
|
||||
|
||||
[Speed-ups to expect:]
|
||||
|
||||
You should see a reduction in the "Pair time" value printed at the end
|
||||
of a run. On most machines for reasonable problem sizes, it will be a
|
||||
5 to 20% savings.
|
||||
|
||||
[Guidelines for best performance:]
|
||||
|
||||
Just try out an OPT pair style to see how it performs.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
None.
|
||||
@ -1,267 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style charmm command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style charmm command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-charmm-command">
|
||||
<span id="index-0"></span><h1>angle_style charmm command<a class="headerlink" href="#angle-style-charmm-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-charmm-intel-command">
|
||||
<h1>angle_style charmm/intel command<a class="headerlink" href="#angle-style-charmm-intel-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-charmm-kk-command">
|
||||
<h1>angle_style charmm/kk command<a class="headerlink" href="#angle-style-charmm-kk-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-charmm-omp-command">
|
||||
<h1>angle_style charmm/omp command<a class="headerlink" href="#angle-style-charmm-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style charmm
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style charmm
|
||||
angle_coeff 1 300.0 107.0 50.0 3.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>charmm</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_charmm.jpg" class="align-center" src="_images/angle_charmm.jpg" />
|
||||
<p>with an additional Urey_Bradley term based on the distance <em>r</em> between
|
||||
the 1st and 3rd atoms in the angle. K, theta0, Kub, and Rub are
|
||||
coefficients defined for each angle type.</p>
|
||||
<p>See <a class="reference internal" href="special_bonds.html#mackerell"><span>(MacKerell)</span></a> for a description of the CHARMM force
|
||||
field.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy/radian^2)</li>
|
||||
<li>theta0 (degrees)</li>
|
||||
<li>K_ub (energy/distance^2)</li>
|
||||
<li>r_ub (distance)</li>
|
||||
</ul>
|
||||
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
<hr class="docutils" />
|
||||
<p id="mackerell"><strong>(MacKerell)</strong> MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
||||
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,90 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style charmm command :h3
|
||||
angle_style charmm/intel command :h3
|
||||
angle_style charmm/kk command :h3
|
||||
angle_style charmm/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style charmm :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style charmm
|
||||
angle_coeff 1 300.0 107.0 50.0 3.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {charmm} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_charmm.jpg)
|
||||
|
||||
with an additional Urey_Bradley term based on the distance {r} between
|
||||
the 1st and 3rd atoms in the angle. K, theta0, Kub, and Rub are
|
||||
coefficients defined for each angle type.
|
||||
|
||||
See "(MacKerell)"_#MacKerell for a description of the CHARMM force
|
||||
field.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy/radian^2)
|
||||
theta0 (degrees)
|
||||
K_ub (energy/distance^2)
|
||||
r_ub (distance) :ul
|
||||
|
||||
Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
:line
|
||||
|
||||
:link(MacKerell)
|
||||
[(MacKerell)] MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field,
|
||||
Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
|
||||
@ -1,291 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style class2 command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style class2 command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-class2-command">
|
||||
<span id="index-0"></span><h1>angle_style class2 command<a class="headerlink" href="#angle-style-class2-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-class2-omp-command">
|
||||
<h1>angle_style class2/omp command<a class="headerlink" href="#angle-style-class2-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style class2
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style class2
|
||||
angle_coeff * 75.0
|
||||
angle_coeff 1 bb 10.5872 1.0119 1.5228
|
||||
angle_coeff * ba 3.6551 24.895 1.0119 1.5228
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>class2</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_class2.jpg" class="align-center" src="_images/angle_class2.jpg" />
|
||||
<p>where Ea is the angle term, Ebb is a bond-bond term, and Eba is a
|
||||
bond-angle term. Theta0 is the equilibrium angle and r1 and r2 are
|
||||
the equilibrium bond lengths.</p>
|
||||
<p>See <a class="reference internal" href="pair_modify.html#sun"><span>(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
|
||||
<p>Coefficients for the Ea, Ebb, and Eba formulas must be defined for
|
||||
each angle type via the <a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in
|
||||
the example above, or in the data file or restart files read by the
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a> or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a>
|
||||
commands.</p>
|
||||
<p>These are the 4 coefficients for the Ea formula:</p>
|
||||
<ul class="simple">
|
||||
<li>theta0 (degrees)</li>
|
||||
<li>K2 (energy/radian^2)</li>
|
||||
<li>K3 (energy/radian^3)</li>
|
||||
<li>K4 (energy/radian^4)</li>
|
||||
</ul>
|
||||
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of the various K are in per-radian.</p>
|
||||
<p>For the Ebb formula, each line in a <a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>
|
||||
command in the input script lists 4 coefficients, the first of which
|
||||
is “bb” to indicate they are BondBond coefficients. In a data file,
|
||||
these coefficients should be listed under a “BondBond Coeffs” heading
|
||||
and you must leave out the “bb”, i.e. only list 3 coefficients after
|
||||
the angle type.</p>
|
||||
<ul class="simple">
|
||||
<li>bb</li>
|
||||
<li>M (energy/distance^2)</li>
|
||||
<li>r1 (distance)</li>
|
||||
<li>r2 (distance)</li>
|
||||
</ul>
|
||||
<p>For the Eba formula, each line in a <a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>
|
||||
command in the input script lists 5 coefficients, the first of which
|
||||
is “ba” to indicate they are BondAngle coefficients. In a data file,
|
||||
these coefficients should be listed under a “BondAngle Coeffs” heading
|
||||
and you must leave out the “ba”, i.e. only list 4 coefficients after
|
||||
the angle type.</p>
|
||||
<ul class="simple">
|
||||
<li>ba</li>
|
||||
<li>N1 (energy/distance^2)</li>
|
||||
<li>N2 (energy/distance^2)</li>
|
||||
<li>r1 (distance)</li>
|
||||
<li>r2 (distance)</li>
|
||||
</ul>
|
||||
<p>The theta0 value in the Eba formula is not specified, since it is the
|
||||
same value from the Ea formula.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the CLASS2
|
||||
package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section
|
||||
for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
<hr class="docutils" />
|
||||
<p id="sun"><strong>(Sun)</strong> Sun, J Phys Chem B 102, 7338-7364 (1998).</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,119 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style class2 command :h3
|
||||
angle_style class2/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style class2 :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style class2
|
||||
angle_coeff * 75.0
|
||||
angle_coeff 1 bb 10.5872 1.0119 1.5228
|
||||
angle_coeff * ba 3.6551 24.895 1.0119 1.5228 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {class2} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_class2.jpg)
|
||||
|
||||
where Ea is the angle term, Ebb is a bond-bond term, and Eba is a
|
||||
bond-angle term. Theta0 is the equilibrium angle and r1 and r2 are
|
||||
the equilibrium bond lengths.
|
||||
|
||||
See "(Sun)"_#Sun for a description of the COMPASS class2 force field.
|
||||
|
||||
Coefficients for the Ea, Ebb, and Eba formulas must be defined for
|
||||
each angle type via the "angle_coeff"_angle_coeff.html command as in
|
||||
the example above, or in the data file or restart files read by the
|
||||
"read_data"_read_data.html or "read_restart"_read_restart.html
|
||||
commands.
|
||||
|
||||
These are the 4 coefficients for the Ea formula:
|
||||
|
||||
theta0 (degrees)
|
||||
K2 (energy/radian^2)
|
||||
K3 (energy/radian^3)
|
||||
K4 (energy/radian^4) :ul
|
||||
|
||||
Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of the various K are in per-radian.
|
||||
|
||||
For the Ebb formula, each line in a "angle_coeff"_angle_coeff.html
|
||||
command in the input script lists 4 coefficients, the first of which
|
||||
is "bb" to indicate they are BondBond coefficients. In a data file,
|
||||
these coefficients should be listed under a "BondBond Coeffs" heading
|
||||
and you must leave out the "bb", i.e. only list 3 coefficients after
|
||||
the angle type.
|
||||
|
||||
bb
|
||||
M (energy/distance^2)
|
||||
r1 (distance)
|
||||
r2 (distance) :ul
|
||||
|
||||
For the Eba formula, each line in a "angle_coeff"_angle_coeff.html
|
||||
command in the input script lists 5 coefficients, the first of which
|
||||
is "ba" to indicate they are BondAngle coefficients. In a data file,
|
||||
these coefficients should be listed under a "BondAngle Coeffs" heading
|
||||
and you must leave out the "ba", i.e. only list 4 coefficients after
|
||||
the angle type.
|
||||
|
||||
ba
|
||||
N1 (energy/distance^2)
|
||||
N2 (energy/distance^2)
|
||||
r1 (distance)
|
||||
r2 (distance) :ul
|
||||
|
||||
The theta0 value in the Eba formula is not specified, since it is the
|
||||
same value from the Ea formula.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the CLASS2
|
||||
package. See the "Making LAMMPS"_Section_start.html#start_3 section
|
||||
for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
:line
|
||||
|
||||
:link(Sun)
|
||||
[(Sun)] Sun, J Phys Chem B 102, 7338-7364 (1998).
|
||||
@ -1,279 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_coeff command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_coeff command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-coeff-command">
|
||||
<span id="index-0"></span><h1>angle_coeff command<a class="headerlink" href="#angle-coeff-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_coeff N args
|
||||
</pre></div>
|
||||
</div>
|
||||
<ul class="simple">
|
||||
<li>N = angle type (see asterisk form below)</li>
|
||||
<li>args = coefficients for one or more angle types</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_coeff 1 300.0 107.0
|
||||
angle_coeff * 5.0
|
||||
angle_coeff 2*10 5.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Specify the angle force field coefficients for one or more angle types.
|
||||
The number and meaning of the coefficients depends on the angle style.
|
||||
Angle coefficients can also be set in the data file read by the
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a> command or in a restart file.</p>
|
||||
<p>N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple angle types. This takes the
|
||||
form “*” or “<em>n” or “n</em>” or “m*n”. If N = the number of angle types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
leading asterisk means all types from 1 to n (inclusive). A trailing
|
||||
asterisk means all types from n to N (inclusive). A middle asterisk
|
||||
means all types from m to n (inclusive).</p>
|
||||
<p>Note that using an angle_coeff command can override a previous setting
|
||||
for the same angle type. For example, these commands set the coeffs
|
||||
for all angle types, then overwrite the coeffs for just angle type 2:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_coeff * 200.0 107.0 1.2
|
||||
angle_coeff 2 50.0 107.0
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>A line in a data file that specifies angle coefficients uses the exact
|
||||
same format as the arguments of the angle_coeff command in an input
|
||||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the “Angle Coeffs” section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>1 300.0 107.0
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The <a class="reference internal" href="angle_class2.html"><em>angle_style class2</em></a> is an exception to this
|
||||
rule, in that an additional argument is used in the input script to
|
||||
allow specification of the cross-term coefficients. See its
|
||||
doc page for details.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Here is an alphabetic list of angle styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated <a class="reference internal" href=""><em>angle_coeff</em></a> command.</p>
|
||||
<p>Note that there are also additional angle styles submitted by users
|
||||
which are included in the LAMMPS distribution. The list of these with
|
||||
links to the individual styles are given in the angle section of <a class="reference internal" href="Section_commands.html#cmd-5"><span>this page</span></a>.</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference internal" href="angle_none.html"><em>angle_style none</em></a> - turn off angle interactions</li>
|
||||
<li><a class="reference internal" href="angle_hybrid.html"><em>angle_style hybrid</em></a> - define multiple styles of angle interactions</li>
|
||||
<li><a class="reference internal" href="angle_charmm.html"><em>angle_style charmm</em></a> - CHARMM angle</li>
|
||||
<li><a class="reference internal" href="angle_class2.html"><em>angle_style class2</em></a> - COMPASS (class 2) angle</li>
|
||||
<li><a class="reference internal" href="angle_cosine.html"><em>angle_style cosine</em></a> - cosine angle potential</li>
|
||||
<li><a class="reference internal" href="angle_cosine_delta.html"><em>angle_style cosine/delta</em></a> - difference of cosines angle potential</li>
|
||||
<li><a class="reference internal" href="angle_cosine_periodic.html"><em>angle_style cosine/periodic</em></a> - DREIDING angle</li>
|
||||
<li><a class="reference internal" href="angle_cosine_squared.html"><em>angle_style cosine/squared</em></a> - cosine squared angle potential</li>
|
||||
<li><a class="reference internal" href="angle_harmonic.html"><em>angle_style harmonic</em></a> - harmonic angle</li>
|
||||
<li><a class="reference internal" href="angle_table.html"><em>angle_style table</em></a> - tabulated by angle</li>
|
||||
</ul>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This command must come after the simulation box is defined by a
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a>, <a class="reference internal" href="read_restart.html"><em>read_restart</em></a>, or
|
||||
<a class="reference internal" href="create_box.html"><em>create_box</em></a> command.</p>
|
||||
<p>An angle style must be defined before any angle coefficients are
|
||||
set, either in the input script or in a data file.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_style.html"><em>angle_style</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,99 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_coeff command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_coeff N args :pre
|
||||
|
||||
N = angle type (see asterisk form below)
|
||||
args = coefficients for one or more angle types :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_coeff 1 300.0 107.0
|
||||
angle_coeff * 5.0
|
||||
angle_coeff 2*10 5.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Specify the angle force field coefficients for one or more angle types.
|
||||
The number and meaning of the coefficients depends on the angle style.
|
||||
Angle coefficients can also be set in the data file read by the
|
||||
"read_data"_read_data.html command or in a restart file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple angle types. This takes the
|
||||
form "*" or "*n" or "n*" or "m*n". If N = the number of angle types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
leading asterisk means all types from 1 to n (inclusive). A trailing
|
||||
asterisk means all types from n to N (inclusive). A middle asterisk
|
||||
means all types from m to n (inclusive).
|
||||
|
||||
Note that using an angle_coeff command can override a previous setting
|
||||
for the same angle type. For example, these commands set the coeffs
|
||||
for all angle types, then overwrite the coeffs for just angle type 2:
|
||||
|
||||
angle_coeff * 200.0 107.0 1.2
|
||||
angle_coeff 2 50.0 107.0 :pre
|
||||
|
||||
A line in a data file that specifies angle coefficients uses the exact
|
||||
same format as the arguments of the angle_coeff command in an input
|
||||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Angle Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
|
||||
1 300.0 107.0 :pre
|
||||
|
||||
The "angle_style class2"_angle_class2.html is an exception to this
|
||||
rule, in that an additional argument is used in the input script to
|
||||
allow specification of the cross-term coefficients. See its
|
||||
doc page for details.
|
||||
|
||||
:line
|
||||
|
||||
Here is an alphabetic list of angle styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated "angle_coeff"_angle_coeff.html command.
|
||||
|
||||
Note that there are also additional angle styles submitted by users
|
||||
which are included in the LAMMPS distribution. The list of these with
|
||||
links to the individual styles are given in the angle section of "this
|
||||
page"_Section_commands.html#cmd_5.
|
||||
|
||||
"angle_style none"_angle_none.html - turn off angle interactions
|
||||
"angle_style hybrid"_angle_hybrid.html - define multiple styles of angle interactions :ul
|
||||
|
||||
"angle_style charmm"_angle_charmm.html - CHARMM angle
|
||||
"angle_style class2"_angle_class2.html - COMPASS (class 2) angle
|
||||
"angle_style cosine"_angle_cosine.html - cosine angle potential
|
||||
"angle_style cosine/delta"_angle_cosine_delta.html - difference of cosines angle potential
|
||||
"angle_style cosine/periodic"_angle_cosine_periodic.html - DREIDING angle
|
||||
"angle_style cosine/squared"_angle_cosine_squared.html - cosine squared angle potential
|
||||
"angle_style harmonic"_angle_harmonic.html - harmonic angle
|
||||
"angle_style table"_angle_table.html - tabulated by angle :ul
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This command must come after the simulation box is defined by a
|
||||
"read_data"_read_data.html, "read_restart"_read_restart.html, or
|
||||
"create_box"_create_box.html command.
|
||||
|
||||
An angle style must be defined before any angle coefficients are
|
||||
set, either in the input script or in a data file.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_style"_angle_style.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,249 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style cosine command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style cosine command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-cosine-command">
|
||||
<span id="index-0"></span><h1>angle_style cosine command<a class="headerlink" href="#angle-style-cosine-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-cosine-omp-command">
|
||||
<h1>angle_style cosine/omp command<a class="headerlink" href="#angle-style-cosine-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine
|
||||
angle_coeff * 75.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>cosine</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_cosine.jpg" class="align-center" src="_images/angle_cosine.jpg" />
|
||||
<p>where K is defined for each angle type.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,71 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style cosine command :h3
|
||||
angle_style cosine/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style cosine :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style cosine
|
||||
angle_coeff * 75.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {cosine} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_cosine.jpg)
|
||||
|
||||
where K is defined for each angle type.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,253 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style cosine/delta command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style cosine/delta command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-cosine-delta-command">
|
||||
<span id="index-0"></span><h1>angle_style cosine/delta command<a class="headerlink" href="#angle-style-cosine-delta-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-cosine-delta-omp-command">
|
||||
<h1>angle_style cosine/delta/omp command<a class="headerlink" href="#angle-style-cosine-delta-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/delta
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/delta
|
||||
angle_coeff 2*4 75.0 100.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>cosine/delta</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_cosine_delta.jpg" class="align-center" src="_images/angle_cosine_delta.jpg" />
|
||||
<p>where theta0 is the equilibrium value of the angle, and K is a
|
||||
prefactor. Note that the usual 1/2 factor is included in K.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy)</li>
|
||||
<li>theta0 (degrees)</li>
|
||||
</ul>
|
||||
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>, <a class="reference internal" href="angle_cosine_squared.html"><em>angle_style cosine/squared</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,77 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style cosine/delta command :h3
|
||||
angle_style cosine/delta/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style cosine/delta :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style cosine/delta
|
||||
angle_coeff 2*4 75.0 100.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {cosine/delta} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_cosine_delta.jpg)
|
||||
|
||||
where theta0 is the equilibrium value of the angle, and K is a
|
||||
prefactor. Note that the usual 1/2 factor is included in K.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy)
|
||||
theta0 (degrees) :ul
|
||||
|
||||
Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html, "angle_style
|
||||
cosine/squared"_angle_cosine_squared.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,263 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style cosine/periodic command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style cosine/periodic command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-cosine-periodic-command">
|
||||
<span id="index-0"></span><h1>angle_style cosine/periodic command<a class="headerlink" href="#angle-style-cosine-periodic-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-cosine-periodic-omp-command">
|
||||
<h1>angle_style cosine/periodic/omp command<a class="headerlink" href="#angle-style-cosine-periodic-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/periodic
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/periodic
|
||||
angle_coeff * 75.0 1 6
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>cosine/periodic</em> angle style uses the following potential, which
|
||||
is commonly used in the <a class="reference internal" href="Section_howto.html#howto-4"><span>DREIDING</span></a> force
|
||||
field, particularly for organometallic systems where <em>n</em> = 4 might be
|
||||
used for an octahedral complex and <em>n</em> = 3 might be used for a
|
||||
trigonal center:</p>
|
||||
<img alt="_images/angle_cosine_periodic.jpg" class="align-center" src="_images/angle_cosine_periodic.jpg" />
|
||||
<p>where C, B and n are coefficients defined for each angle type.</p>
|
||||
<p>See <a class="reference internal" href="special_bonds.html#mayo"><span>(Mayo)</span></a> for a description of the DREIDING force field</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>C (energy)</li>
|
||||
<li>B = 1 or -1</li>
|
||||
<li>n = 1, 2, 3, 4, 5 or 6 for periodicity</li>
|
||||
</ul>
|
||||
<p>Note that the prefactor C is specified and not the overall force
|
||||
constant K = C / n^2. When B = 1, it leads to a minimum for the
|
||||
linear geometry. When B = -1, it leads to a maximum for the linear
|
||||
geometry.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
<hr class="docutils" />
|
||||
<p id="mayo"><strong>(Mayo)</strong> Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
|
||||
(1990).</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,90 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style cosine/periodic command :h3
|
||||
angle_style cosine/periodic/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style cosine/periodic :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style cosine/periodic
|
||||
angle_coeff * 75.0 1 6 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {cosine/periodic} angle style uses the following potential, which
|
||||
is commonly used in the "DREIDING"_Section_howto.html#howto_4 force
|
||||
field, particularly for organometallic systems where {n} = 4 might be
|
||||
used for an octahedral complex and {n} = 3 might be used for a
|
||||
trigonal center:
|
||||
|
||||
:c,image(Eqs/angle_cosine_periodic.jpg)
|
||||
|
||||
where C, B and n are coefficients defined for each angle type.
|
||||
|
||||
See "(Mayo)"_#Mayo for a description of the DREIDING force field
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
C (energy)
|
||||
B = 1 or -1
|
||||
n = 1, 2, 3, 4, 5 or 6 for periodicity :ul
|
||||
|
||||
Note that the prefactor C is specified and not the overall force
|
||||
constant K = C / n^2. When B = 1, it leads to a minimum for the
|
||||
linear geometry. When B = -1, it leads to a maximum for the linear
|
||||
geometry.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
:line
|
||||
|
||||
:link(Mayo)
|
||||
[(Mayo)] Mayo, Olfason, Goddard III, J Phys Chem, 94, 8897-8909
|
||||
(1990).
|
||||
@ -1,254 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style cosine/shift command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style cosine/shift command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-cosine-shift-command">
|
||||
<span id="index-0"></span><h1>angle_style cosine/shift command<a class="headerlink" href="#angle-style-cosine-shift-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-cosine-shift-omp-command">
|
||||
<h1>angle_style cosine/shift/omp command<a class="headerlink" href="#angle-style-cosine-shift-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/shift
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/shift
|
||||
angle_coeff * 10.0 45.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>cosine/shift</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_cosine_shift.jpg" class="align-center" src="_images/angle_cosine_shift.jpg" />
|
||||
<p>where theta0 is the equilibrium angle. The potential is bounded
|
||||
between -Umin and zero. In the neighborhood of the minimum E=- Umin +
|
||||
Umin/4(theta-theta0)^2 hence the spring constant is umin/2.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>umin (energy)</li>
|
||||
<li>theta (angle)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a>
|
||||
section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>,
|
||||
<code class="xref doc docutils literal"><span class="pre">angle_cosineshiftexp</span></code></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,75 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style cosine/shift command :h3
|
||||
angle_style cosine/shift/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style cosine/shift :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style cosine/shift
|
||||
angle_coeff * 10.0 45.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {cosine/shift} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_cosine_shift.jpg)
|
||||
|
||||
where theta0 is the equilibrium angle. The potential is bounded
|
||||
between -Umin and zero. In the neighborhood of the minimum E=- Umin +
|
||||
Umin/4(theta-theta0)^2 hence the spring constant is umin/2.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
umin (energy)
|
||||
theta (angle) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
|
||||
section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html,
|
||||
"angle_cosineshiftexp"_angle_cosineshiftexp.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,265 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style cosine/shift/exp command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style cosine/shift/exp command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-cosine-shift-exp-command">
|
||||
<span id="index-0"></span><h1>angle_style cosine/shift/exp command<a class="headerlink" href="#angle-style-cosine-shift-exp-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-cosine-shift-exp-omp-command">
|
||||
<h1>angle_style cosine/shift/exp/omp command<a class="headerlink" href="#angle-style-cosine-shift-exp-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/shift/exp
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/shift/exp
|
||||
angle_coeff * 10.0 45.0 2.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>cosine/shift/exp</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_cosine_shift_exp.jpg" class="align-center" src="_images/angle_cosine_shift_exp.jpg" />
|
||||
<p>where Umin, theta, and a are defined for each angle type.</p>
|
||||
<p>The potential is bounded between [-Umin:0] and the minimum is
|
||||
located at the angle theta0. The a parameter can be both positive or
|
||||
negative and is used to control the spring constant at the
|
||||
equilibrium.</p>
|
||||
<p>The spring constant is given by k = A exp(A) Umin / [2 (Exp(a)-1)].
|
||||
For a > 3, k/Umin = a/2 to better than 5% relative error. For negative
|
||||
values of the a parameter, the spring constant is essentially zero,
|
||||
and anharmonic terms takes over. The potential is furthermore well
|
||||
behaved in the limit a -> 0, where it has been implemented to linear
|
||||
order in a for a < 0.001. In this limit the potential reduces to the
|
||||
cosineshifted potential.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>umin (energy)</li>
|
||||
<li>theta (angle)</li>
|
||||
<li>A (real number)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a>
|
||||
section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>,
|
||||
<code class="xref doc docutils literal"><span class="pre">angle_cosineshift</span></code>,
|
||||
<code class="xref doc docutils literal"><span class="pre">dihedral_cosineshift</span></code></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,88 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style cosine/shift/exp command :h3
|
||||
angle_style cosine/shift/exp/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style cosine/shift/exp :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style cosine/shift/exp
|
||||
angle_coeff * 10.0 45.0 2.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {cosine/shift/exp} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_cosine_shift_exp.jpg)
|
||||
|
||||
where Umin, theta, and a are defined for each angle type.
|
||||
|
||||
The potential is bounded between \[-Umin:0\] and the minimum is
|
||||
located at the angle theta0. The a parameter can be both positive or
|
||||
negative and is used to control the spring constant at the
|
||||
equilibrium.
|
||||
|
||||
The spring constant is given by k = A exp(A) Umin / \[2 (Exp(a)-1)\].
|
||||
For a > 3, k/Umin = a/2 to better than 5% relative error. For negative
|
||||
values of the a parameter, the spring constant is essentially zero,
|
||||
and anharmonic terms takes over. The potential is furthermore well
|
||||
behaved in the limit a -> 0, where it has been implemented to linear
|
||||
order in a for a < 0.001. In this limit the potential reduces to the
|
||||
cosineshifted potential.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
umin (energy)
|
||||
theta (angle)
|
||||
A (real number) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
|
||||
section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html,
|
||||
"angle_cosineshift"_angle_cosineshift.html,
|
||||
"dihedral_cosineshift"_dihedral_cosineshift.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,253 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style cosine/squared command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style cosine/squared command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-cosine-squared-command">
|
||||
<span id="index-0"></span><h1>angle_style cosine/squared command<a class="headerlink" href="#angle-style-cosine-squared-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-cosine-squared-omp-command">
|
||||
<h1>angle_style cosine/squared/omp command<a class="headerlink" href="#angle-style-cosine-squared-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/squared
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style cosine/squared
|
||||
angle_coeff 2*4 75.0 100.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>cosine/squared</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_cosine_squared.jpg" class="align-center" src="_images/angle_cosine_squared.jpg" />
|
||||
<p>where theta0 is the equilibrium value of the angle, and K is a
|
||||
prefactor. Note that the usual 1/2 factor is included in K.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy)</li>
|
||||
<li>theta0 (degrees)</li>
|
||||
</ul>
|
||||
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,76 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style cosine/squared command :h3
|
||||
angle_style cosine/squared/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style cosine/squared :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style cosine/squared
|
||||
angle_coeff 2*4 75.0 100.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {cosine/squared} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_cosine_squared.jpg)
|
||||
|
||||
where theta0 is the equilibrium value of the angle, and K is a
|
||||
prefactor. Note that the usual 1/2 factor is included in K.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy)
|
||||
theta0 (degrees) :ul
|
||||
|
||||
Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,292 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style dipole command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style dipole command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-dipole-command">
|
||||
<span id="index-0"></span><h1>angle_style dipole command<a class="headerlink" href="#angle-style-dipole-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-dipole-omp-command">
|
||||
<h1>angle_style dipole/omp command<a class="headerlink" href="#angle-style-dipole-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style dipole
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style dipole
|
||||
angle_coeff 6 2.1 180.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>dipole</em> angle style is used to control the orientation of a dipolar
|
||||
atom within a molecule <a class="reference internal" href="#orsi"><span>(Orsi)</span></a>. Specifically, the <em>dipole</em> angle
|
||||
style restrains the orientation of a point dipole mu_j (embedded in atom
|
||||
‘j’) with respect to a reference (bond) vector r_ij = r_i - r_j, where ‘i’
|
||||
is another atom of the same molecule (typically, ‘i’ and ‘j’ are also
|
||||
covalently bonded).</p>
|
||||
<p>It is convenient to define an angle gamma between the ‘free’ vector mu_j
|
||||
and the reference (bond) vector r_ij:</p>
|
||||
<img alt="_images/angle_dipole_gamma.jpg" class="align-center" src="_images/angle_dipole_gamma.jpg" />
|
||||
<p>The <em>dipole</em> angle style uses the potential:</p>
|
||||
<img alt="_images/angle_dipole_potential.jpg" class="align-center" src="_images/angle_dipole_potential.jpg" />
|
||||
<p>where K is a rigidity constant and gamma0 is an equilibrium (reference)
|
||||
angle.</p>
|
||||
<p>The torque on the dipole can be obtained by differentiating the
|
||||
potential using the ‘chain rule’ as in appendix C.3 of
|
||||
<a class="reference internal" href="pair_gayberne.html#allen"><span>(Allen)</span></a>:</p>
|
||||
<img alt="_images/angle_dipole_torque.jpg" class="align-center" src="_images/angle_dipole_torque.jpg" />
|
||||
<p>Example: if gamma0 is set to 0 degrees, the torque generated by
|
||||
the potential will tend to align the dipole along the reference
|
||||
direction defined by the (bond) vector r_ij (in other words, mu_j is
|
||||
restrained to point towards atom ‘i’).</p>
|
||||
<p>The dipolar torque T_j must be counterbalanced in order to conserve
|
||||
the local angular momentum. This is achieved via an additional force
|
||||
couple generating a torque equivalent to the opposite of T_j:</p>
|
||||
<img alt="_images/angle_dipole_couple.jpg" class="align-center" src="_images/angle_dipole_couple.jpg" />
|
||||
<p>where F_i and F_j are applied on atoms i and j, respectively.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy)</li>
|
||||
<li>gamma0 (degrees)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-6"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the <span class="xref std std-ref">Making LAMMPS</span>
|
||||
section for more info on packages.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">In the “Angles” section of the data file, the atom ID ‘j’
|
||||
corresponding to the dipole to restrain must come before the atom ID
|
||||
of the reference atom ‘i’. A third atom ID ‘k’ must also be provided,
|
||||
although ‘k’ is just a ‘dummy’ atom which can be any atom; it may be
|
||||
useful to choose a convention (e.g., ‘k’=’i’) and adhere to it. For
|
||||
example, if ID=1 for the dipolar atom to restrain, and ID=2 for the
|
||||
reference atom, the corresponding line in the “Angles” section of the
|
||||
data file would read: X X 1 2 2</p>
|
||||
</div>
|
||||
<p>The “newton” command for intramolecular interactions must be “on”
|
||||
(which is the default).</p>
|
||||
<p>This angle style should not be used with SHAKE.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>, <a class="reference internal" href="angle_hybrid.html"><em>angle_hybrid</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
<hr class="docutils" />
|
||||
<p id="orsi"><strong>(Orsi)</strong> Orsi & Essex, The ELBA force field for coarse-grain modeling of
|
||||
lipid membranes, PloS ONE 6(12): e28637, 2011.</p>
|
||||
<p id="allen"><strong>(Allen)</strong> Allen & Tildesley, Computer Simulation of Liquids,
|
||||
Clarendon Press, Oxford, 1987.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,126 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style dipole command :h3
|
||||
angle_style dipole/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style dipole :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style dipole
|
||||
angle_coeff 6 2.1 180.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {dipole} angle style is used to control the orientation of a dipolar
|
||||
atom within a molecule "(Orsi)"_#Orsi. Specifically, the {dipole} angle
|
||||
style restrains the orientation of a point dipole mu_j (embedded in atom
|
||||
'j') with respect to a reference (bond) vector r_ij = r_i - r_j, where 'i'
|
||||
is another atom of the same molecule (typically, 'i' and 'j' are also
|
||||
covalently bonded).
|
||||
|
||||
It is convenient to define an angle gamma between the 'free' vector mu_j
|
||||
and the reference (bond) vector r_ij:
|
||||
|
||||
:c,image(Eqs/angle_dipole_gamma.jpg)
|
||||
|
||||
The {dipole} angle style uses the potential:
|
||||
|
||||
:c,image(Eqs/angle_dipole_potential.jpg)
|
||||
|
||||
where K is a rigidity constant and gamma0 is an equilibrium (reference)
|
||||
angle.
|
||||
|
||||
The torque on the dipole can be obtained by differentiating the
|
||||
potential using the 'chain rule' as in appendix C.3 of
|
||||
"(Allen)"_#Allen:
|
||||
|
||||
:c,image(Eqs/angle_dipole_torque.jpg)
|
||||
|
||||
Example: if gamma0 is set to 0 degrees, the torque generated by
|
||||
the potential will tend to align the dipole along the reference
|
||||
direction defined by the (bond) vector r_ij (in other words, mu_j is
|
||||
restrained to point towards atom 'i').
|
||||
|
||||
The dipolar torque T_j must be counterbalanced in order to conserve
|
||||
the local angular momentum. This is achieved via an additional force
|
||||
couple generating a torque equivalent to the opposite of T_j:
|
||||
|
||||
:c,image(Eqs/angle_dipole_couple.jpg)
|
||||
|
||||
where F_i and F_j are applied on atoms i and j, respectively.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy)
|
||||
gamma0 (degrees) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_6 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the "Making LAMMPS"_Section_start.html#2_3
|
||||
section for more info on packages.
|
||||
|
||||
NOTE: In the "Angles" section of the data file, the atom ID 'j'
|
||||
corresponding to the dipole to restrain must come before the atom ID
|
||||
of the reference atom 'i'. A third atom ID 'k' must also be provided,
|
||||
although 'k' is just a 'dummy' atom which can be any atom; it may be
|
||||
useful to choose a convention (e.g., 'k'='i') and adhere to it. For
|
||||
example, if ID=1 for the dipolar atom to restrain, and ID=2 for the
|
||||
reference atom, the corresponding line in the "Angles" section of the
|
||||
data file would read: X X 1 2 2
|
||||
|
||||
The "newton" command for intramolecular interactions must be "on"
|
||||
(which is the default).
|
||||
|
||||
This angle style should not be used with SHAKE.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html, "angle_hybrid"_angle_hybrid.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
:line
|
||||
|
||||
:link(Orsi)
|
||||
[(Orsi)] Orsi & Essex, The ELBA force field for coarse-grain modeling of
|
||||
lipid membranes, PloS ONE 6(12): e28637, 2011.
|
||||
|
||||
:link(Allen)
|
||||
[(Allen)] Allen & Tildesley, Computer Simulation of Liquids,
|
||||
Clarendon Press, Oxford, 1987.
|
||||
@ -1,250 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style fourier command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style fourier command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-fourier-command">
|
||||
<span id="index-0"></span><h1>angle_style fourier command<a class="headerlink" href="#angle-style-fourier-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-fourier-omp-command">
|
||||
<h1>angle_style fourier/omp command<a class="headerlink" href="#angle-style-fourier-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style fourier
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<p>angle_style fourier
|
||||
angle_coeff 75.0 1.0 1.0 1.0</p>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>fourier</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_fourier.jpg" class="align-center" src="_images/angle_fourier.jpg" />
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy)</li>
|
||||
<li>C0 (real)</li>
|
||||
<li>C1 (real)</li>
|
||||
<li>C2 (real)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a>
|
||||
section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,72 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style fourier command :h3
|
||||
angle_style fourier/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style fourier :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style fourier
|
||||
angle_coeff 75.0 1.0 1.0 1.0
|
||||
|
||||
[Description:]
|
||||
|
||||
The {fourier} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_fourier.jpg)
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy)
|
||||
C0 (real)
|
||||
C1 (real)
|
||||
C2 (real) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
|
||||
section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,249 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style fourier/simple command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style fourier/simple command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-fourier-simple-command">
|
||||
<span id="index-0"></span><h1>angle_style fourier/simple command<a class="headerlink" href="#angle-style-fourier-simple-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-fourier-simple-omp-command">
|
||||
<h1>angle_style fourier/simple/omp command<a class="headerlink" href="#angle-style-fourier-simple-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style fourier/simple
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<p>angle_style fourier/simple
|
||||
angle_coeff 100.0 -1.0 1.0</p>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>fourier/simple</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_fourier_simple.jpg" class="align-center" src="_images/angle_fourier_simple.jpg" />
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy)</li>
|
||||
<li>c (real)</li>
|
||||
<li>n (real)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a>
|
||||
section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,71 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style fourier/simple command :h3
|
||||
angle_style fourier/simple/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style fourier/simple :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style fourier/simple
|
||||
angle_coeff 100.0 -1.0 1.0
|
||||
|
||||
[Description:]
|
||||
|
||||
The {fourier/simple} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_fourier_simple.jpg)
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy)
|
||||
c (real)
|
||||
n (real) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
|
||||
section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,261 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style harmonic command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style harmonic command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-harmonic-command">
|
||||
<span id="index-0"></span><h1>angle_style harmonic command<a class="headerlink" href="#angle-style-harmonic-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-harmonic-intel-command">
|
||||
<h1>angle_style harmonic/intel command<a class="headerlink" href="#angle-style-harmonic-intel-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-harmonic-kk-command">
|
||||
<h1>angle_style harmonic/kk command<a class="headerlink" href="#angle-style-harmonic-kk-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-harmonic-omp-command">
|
||||
<h1>angle_style harmonic/omp command<a class="headerlink" href="#angle-style-harmonic-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style harmonic
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style harmonic
|
||||
angle_coeff 1 300.0 107.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>harmonic</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_harmonic.jpg" class="align-center" src="_images/angle_harmonic.jpg" />
|
||||
<p>where theta0 is the equilibrium value of the angle, and K is a
|
||||
prefactor. Note that the usual 1/2 factor is included in K.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy/radian^2)</li>
|
||||
<li>theta0 (degrees)</li>
|
||||
</ul>
|
||||
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<blockquote>
|
||||
<div>none</div></blockquote>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,78 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style harmonic command :h3
|
||||
angle_style harmonic/intel command :h3
|
||||
angle_style harmonic/kk command :h3
|
||||
angle_style harmonic/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style harmonic :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style harmonic
|
||||
angle_coeff 1 300.0 107.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {harmonic} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_harmonic.jpg)
|
||||
|
||||
where theta0 is the equilibrium value of the angle, and K is a
|
||||
prefactor. Note that the usual 1/2 factor is included in K.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy/radian^2)
|
||||
theta0 (degrees) :ul
|
||||
|
||||
Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,274 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style hybrid command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style hybrid command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-hybrid-command">
|
||||
<span id="index-0"></span><h1>angle_style hybrid command<a class="headerlink" href="#angle-style-hybrid-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style hybrid style1 style2 ...
|
||||
</pre></div>
|
||||
</div>
|
||||
<ul class="simple">
|
||||
<li>style1,style2 = list of one or more angle styles</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style hybrid harmonic cosine
|
||||
angle_coeff 1 harmonic 80.0 30.0
|
||||
angle_coeff 2* cosine 50.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>hybrid</em> style enables the use of multiple angle styles in one
|
||||
simulation. An angle style is assigned to each angle type. For
|
||||
example, angles in a polymer flow (of angle type 1) could be computed
|
||||
with a <em>harmonic</em> potential and angles in the wall boundary (of angle
|
||||
type 2) could be computed with a <em>cosine</em> potential. The assignment
|
||||
of angle type to style is made via the <a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>
|
||||
command or in the data file.</p>
|
||||
<p>In the angle_coeff commands, the name of an angle style must be added
|
||||
after the angle type, with the remaining coefficients being those
|
||||
appropriate to that style. In the example above, the 2 angle_coeff
|
||||
commands set angles of angle type 1 to be computed with a <em>harmonic</em>
|
||||
potential with coefficients 80.0, 30.0 for K, theta0. All other angle
|
||||
types (2-N) are computed with a <em>cosine</em> potential with coefficient
|
||||
50.0 for K.</p>
|
||||
<p>If angle coefficients are specified in the data file read via the
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a> command, then the same rule applies.
|
||||
E.g. “harmonic” or “cosine”, must be added after the angle type, for each
|
||||
line in the “Angle Coeffs” section, e.g.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>Angle Coeffs
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>1 harmonic 80.0 30.0
|
||||
2 cosine 50.0
|
||||
...
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>If <em>class2</em> is one of the angle hybrid styles, the same rule holds for
|
||||
specifying additional BondBond (and BondAngle) coefficients either via
|
||||
the input script or in the data file. I.e. <em>class2</em> must be added to
|
||||
each line after the angle type. For lines in the BondBond (or
|
||||
BondAngle) section of the data file for angle types that are not
|
||||
<em>class2</em>, you must use an angle style of <em>skip</em> as a placeholder, e.g.</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>BondBond Coeffs
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>1 skip
|
||||
2 class2 3.6512 1.0119 1.0119
|
||||
...
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>Note that it is not necessary to use the angle style <em>skip</em> in the
|
||||
input script, since BondBond (or BondAngle) coefficients need not be
|
||||
specified at all for angle types that are not <em>class2</em>.</p>
|
||||
<p>An angle style of <em>none</em> with no additional coefficients can be used
|
||||
in place of an angle style, either in a input script angle_coeff
|
||||
command or in the data file, if you desire to turn off interactions
|
||||
for specific angle types.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
<p>Unlike other angle styles, the hybrid angle style does not store angle
|
||||
coefficient info for individual sub-styles in a <a class="reference internal" href="restart.html"><em>binary restart files</em></a>. Thus when retarting a simulation from a restart
|
||||
file, you need to re-specify angle_coeff commands.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,91 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style hybrid command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style hybrid style1 style2 ... :pre
|
||||
|
||||
style1,style2 = list of one or more angle styles :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style hybrid harmonic cosine
|
||||
angle_coeff 1 harmonic 80.0 30.0
|
||||
angle_coeff 2* cosine 50.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {hybrid} style enables the use of multiple angle styles in one
|
||||
simulation. An angle style is assigned to each angle type. For
|
||||
example, angles in a polymer flow (of angle type 1) could be computed
|
||||
with a {harmonic} potential and angles in the wall boundary (of angle
|
||||
type 2) could be computed with a {cosine} potential. The assignment
|
||||
of angle type to style is made via the "angle_coeff"_angle_coeff.html
|
||||
command or in the data file.
|
||||
|
||||
In the angle_coeff commands, the name of an angle style must be added
|
||||
after the angle type, with the remaining coefficients being those
|
||||
appropriate to that style. In the example above, the 2 angle_coeff
|
||||
commands set angles of angle type 1 to be computed with a {harmonic}
|
||||
potential with coefficients 80.0, 30.0 for K, theta0. All other angle
|
||||
types (2-N) are computed with a {cosine} potential with coefficient
|
||||
50.0 for K.
|
||||
|
||||
If angle coefficients are specified in the data file read via the
|
||||
"read_data"_read_data.html command, then the same rule applies.
|
||||
E.g. "harmonic" or "cosine", must be added after the angle type, for each
|
||||
line in the "Angle Coeffs" section, e.g.
|
||||
|
||||
Angle Coeffs :pre
|
||||
|
||||
1 harmonic 80.0 30.0
|
||||
2 cosine 50.0
|
||||
... :pre
|
||||
|
||||
If {class2} is one of the angle hybrid styles, the same rule holds for
|
||||
specifying additional BondBond (and BondAngle) coefficients either via
|
||||
the input script or in the data file. I.e. {class2} must be added to
|
||||
each line after the angle type. For lines in the BondBond (or
|
||||
BondAngle) section of the data file for angle types that are not
|
||||
{class2}, you must use an angle style of {skip} as a placeholder, e.g.
|
||||
|
||||
BondBond Coeffs :pre
|
||||
|
||||
1 skip
|
||||
2 class2 3.6512 1.0119 1.0119
|
||||
... :pre
|
||||
|
||||
Note that it is not necessary to use the angle style {skip} in the
|
||||
input script, since BondBond (or BondAngle) coefficients need not be
|
||||
specified at all for angle types that are not {class2}.
|
||||
|
||||
An angle style of {none} with no additional coefficients can be used
|
||||
in place of an angle style, either in a input script angle_coeff
|
||||
command or in the data file, if you desire to turn off interactions
|
||||
for specific angle types.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
Unlike other angle styles, the hybrid angle style does not store angle
|
||||
coefficient info for individual sub-styles in a "binary restart
|
||||
files"_restart.html. Thus when retarting a simulation from a restart
|
||||
file, you need to re-specify angle_coeff commands.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,223 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style none command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style none command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-none-command">
|
||||
<span id="index-0"></span><h1>angle_style none command<a class="headerlink" href="#angle-style-none-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style none
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style none
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Using an angle style of none means angle forces and energies are not
|
||||
computed, even if triplets of angle atoms were listed in the data file
|
||||
read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a> command.</p>
|
||||
<p>See the <a class="reference internal" href="angle_zero.html"><em>angle_style zero</em></a> command for a way to
|
||||
calculate angle statistics, but compute no angle interactions.</p>
|
||||
</div>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<blockquote>
|
||||
<div>none</div></blockquote>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_zero.html"><em>angle_style zero</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,34 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style none command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style none :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style none :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Using an angle style of none means angle forces and energies are not
|
||||
computed, even if triplets of angle atoms were listed in the data file
|
||||
read by the "read_data"_read_data.html command.
|
||||
|
||||
See the "angle_style zero"_angle_zero.html command for a way to
|
||||
calculate angle statistics, but compute no angle interactions.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_style zero"_angle_zero.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,256 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style quartic command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style quartic command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-quartic-command">
|
||||
<span id="index-0"></span><h1>angle_style quartic command<a class="headerlink" href="#angle-style-quartic-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-quartic-omp-command">
|
||||
<h1>angle_style quartic/omp command<a class="headerlink" href="#angle-style-quartic-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style quartic
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style quartic
|
||||
angle_coeff 1 129.1948 56.8726 -25.9442 -14.2221
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>quartic</em> angle style uses the potential</p>
|
||||
<img alt="_images/angle_quartic.jpg" class="align-center" src="_images/angle_quartic.jpg" />
|
||||
<p>where theta0 is the equilibrium value of the angle, and K is a
|
||||
prefactor. Note that the usual 1/2 factor is included in K.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>theta0 (degrees)</li>
|
||||
<li>K2 (energy/radian^2)</li>
|
||||
<li>K3 (energy/radian^3)</li>
|
||||
<li>K4 (energy/radian^4)</li>
|
||||
</ul>
|
||||
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
USER_MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a>
|
||||
section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,78 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style quartic command :h3
|
||||
angle_style quartic/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style quartic :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style quartic
|
||||
angle_coeff 1 129.1948 56.8726 -25.9442 -14.2221 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {quartic} angle style uses the potential
|
||||
|
||||
:c,image(Eqs/angle_quartic.jpg)
|
||||
|
||||
where theta0 is the equilibrium value of the angle, and K is a
|
||||
prefactor. Note that the usual 1/2 factor is included in K.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
theta0 (degrees)
|
||||
K2 (energy/radian^2)
|
||||
K3 (energy/radian^3)
|
||||
K4 (energy/radian^4) :ul
|
||||
|
||||
Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER_MISC package. See the "Making LAMMPS"_Section_start.html#start_3
|
||||
section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,242 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style sdk command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style sdk command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-sdk-command">
|
||||
<span id="index-0"></span><h1>angle_style sdk command<a class="headerlink" href="#angle-style-sdk-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style sdk
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style sdk/omp
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style sdk
|
||||
angle_coeff 1 300.0 107.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>sdk</em> angle style is a combination of the harmonic angle potential,</p>
|
||||
<img alt="_images/angle_harmonic.jpg" class="align-center" src="_images/angle_harmonic.jpg" />
|
||||
<p>where theta0 is the equilibrium value of the angle and K a prefactor,
|
||||
with the <em>repulsive</em> part of the non-bonded <em>lj/sdk</em> pair style
|
||||
between the atoms 1 and 3. This angle potential is intended for
|
||||
coarse grained MD simulations with the CMM parametrization using the
|
||||
<a class="reference internal" href="pair_sdk.html"><em>pair_style lj/sdk</em></a>. Relative to the pair_style
|
||||
<em>lj/sdk</em>, however, the energy is shifted by <em>epsilon</em>, to avoid sudden
|
||||
jumps. Note that the usual 1/2 factor is included in K.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy/radian^2)</li>
|
||||
<li>theta0 (degrees)</li>
|
||||
</ul>
|
||||
<p>Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.
|
||||
The also required <em>lj/sdk</em> parameters will be extracted automatically
|
||||
from the pair_style.</p>
|
||||
</div>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
USER-CG-CMM package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>, <a class="reference internal" href="angle_harmonic.html"><em>angle_style harmonic</em></a>, <a class="reference internal" href="pair_sdk.html"><em>pair_style lj/sdk</em></a>,
|
||||
<a class="reference internal" href="pair_sdk.html"><em>pair_style lj/sdk/coul/long</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,58 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style sdk command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style sdk :pre
|
||||
angle_style sdk/omp :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style sdk
|
||||
angle_coeff 1 300.0 107.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {sdk} angle style is a combination of the harmonic angle potential,
|
||||
|
||||
:c,image(Eqs/angle_harmonic.jpg)
|
||||
|
||||
where theta0 is the equilibrium value of the angle and K a prefactor,
|
||||
with the {repulsive} part of the non-bonded {lj/sdk} pair style
|
||||
between the atoms 1 and 3. This angle potential is intended for
|
||||
coarse grained MD simulations with the CMM parametrization using the
|
||||
"pair_style lj/sdk"_pair_sdk.html. Relative to the pair_style
|
||||
{lj/sdk}, however, the energy is shifted by {epsilon}, to avoid sudden
|
||||
jumps. Note that the usual 1/2 factor is included in K.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above:
|
||||
|
||||
K (energy/radian^2)
|
||||
theta0 (degrees) :ul
|
||||
|
||||
Theta0 is specified in degrees, but LAMMPS converts it to radians
|
||||
internally; hence the units of K are in energy/radian^2.
|
||||
The also required {lj/sdk} parameters will be extracted automatically
|
||||
from the pair_style.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
USER-CG-CMM package. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html, "angle_style
|
||||
harmonic"_angle_harmonic.html, "pair_style lj/sdk"_pair_sdk.html,
|
||||
"pair_style lj/sdk/coul/long"_pair_sdk.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,278 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-command">
|
||||
<span id="index-0"></span><h1>angle_style command<a class="headerlink" href="#angle-style-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style style
|
||||
</pre></div>
|
||||
</div>
|
||||
<ul class="simple">
|
||||
<li>style = <em>none</em> or <em>hybrid</em> or <em>charmm</em> or <em>class2</em> or <em>cosine</em> or <em>cosine/squared</em> or <em>harmonic</em></li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style harmonic
|
||||
angle_style charmm
|
||||
angle_style hybrid harmonic cosine
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Set the formula(s) LAMMPS uses to compute angle interactions between
|
||||
triplets of atoms, which remain in force for the duration of the
|
||||
simulation. The list of angle triplets is read in by a
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a> or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> command
|
||||
from a data or restart file.</p>
|
||||
<p>Hybrid models where angles are computed using different angle
|
||||
potentials can be setup using the <em>hybrid</em> angle style.</p>
|
||||
<p>The coefficients associated with a angle style can be specified in a
|
||||
data or restart file or via the <a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command.</p>
|
||||
<p>All angle potentials store their coefficient data in binary restart
|
||||
files which means angle_style and <a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>
|
||||
commands do not need to be re-specified in an input script that
|
||||
restarts a simulation. See the <a class="reference internal" href="read_restart.html"><em>read_restart</em></a>
|
||||
command for details on how to do this. The one exception is that
|
||||
angle_style <em>hybrid</em> only stores the list of sub-styles in the restart
|
||||
file; angle coefficients need to be re-specified.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">When both an angle and pair style is defined, the
|
||||
<a class="reference internal" href="special_bonds.html"><em>special_bonds</em></a> command often needs to be used to
|
||||
turn off (or weight) the pairwise interaction that would otherwise
|
||||
exist between 3 bonded atoms.</p>
|
||||
</div>
|
||||
<p>In the formulas listed for each angle style, <em>theta</em> is the angle
|
||||
between the 3 atoms in the angle.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Here is an alphabetic list of angle styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated <a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command.</p>
|
||||
<p>Note that there are also additional angle styles submitted by users
|
||||
which are included in the LAMMPS distribution. The list of these with
|
||||
links to the individual styles are given in the angle section of <a class="reference internal" href="Section_commands.html#cmd-5"><span>this page</span></a>.</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference internal" href="angle_none.html"><em>angle_style none</em></a> - turn off angle interactions</li>
|
||||
<li><a class="reference internal" href="angle_zero.html"><em>angle_style zero</em></a> - topology but no interactions</li>
|
||||
<li><a class="reference internal" href="angle_hybrid.html"><em>angle_style hybrid</em></a> - define multiple styles of angle interactions</li>
|
||||
<li><a class="reference internal" href="angle_charmm.html"><em>angle_style charmm</em></a> - CHARMM angle</li>
|
||||
<li><a class="reference internal" href="angle_class2.html"><em>angle_style class2</em></a> - COMPASS (class 2) angle</li>
|
||||
<li><a class="reference internal" href="angle_cosine.html"><em>angle_style cosine</em></a> - cosine angle potential</li>
|
||||
<li><a class="reference internal" href="angle_cosine_delta.html"><em>angle_style cosine/delta</em></a> - difference of cosines angle potential</li>
|
||||
<li><a class="reference internal" href="angle_cosine_periodic.html"><em>angle_style cosine/periodic</em></a> - DREIDING angle</li>
|
||||
<li><a class="reference internal" href="angle_cosine_squared.html"><em>angle_style cosine/squared</em></a> - cosine squared angle potential</li>
|
||||
<li><a class="reference internal" href="angle_harmonic.html"><em>angle_style harmonic</em></a> - harmonic angle</li>
|
||||
<li><a class="reference internal" href="angle_table.html"><em>angle_style table</em></a> - tabulated by angle</li>
|
||||
</ul>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Angle styles can only be set for atom_styles that allow angles to be
|
||||
defined.</p>
|
||||
<p>Most angle styles are part of the MOLECULE package. They are only
|
||||
enabled if LAMMPS was built with that package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.
|
||||
The doc pages for individual bond potentials tell if it is part of a
|
||||
package.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
</div>
|
||||
<div class="section" id="default">
|
||||
<h2>Default<a class="headerlink" href="#default" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style none
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,97 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style style :pre
|
||||
|
||||
style = {none} or {hybrid} or {charmm} or {class2} or {cosine} or \
|
||||
{cosine/squared} or {harmonic} :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style harmonic
|
||||
angle_style charmm
|
||||
angle_style hybrid harmonic cosine :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Set the formula(s) LAMMPS uses to compute angle interactions between
|
||||
triplets of atoms, which remain in force for the duration of the
|
||||
simulation. The list of angle triplets is read in by a
|
||||
"read_data"_read_data.html or "read_restart"_read_restart.html command
|
||||
from a data or restart file.
|
||||
|
||||
Hybrid models where angles are computed using different angle
|
||||
potentials can be setup using the {hybrid} angle style.
|
||||
|
||||
The coefficients associated with a angle style can be specified in a
|
||||
data or restart file or via the "angle_coeff"_angle_coeff.html command.
|
||||
|
||||
All angle potentials store their coefficient data in binary restart
|
||||
files which means angle_style and "angle_coeff"_angle_coeff.html
|
||||
commands do not need to be re-specified in an input script that
|
||||
restarts a simulation. See the "read_restart"_read_restart.html
|
||||
command for details on how to do this. The one exception is that
|
||||
angle_style {hybrid} only stores the list of sub-styles in the restart
|
||||
file; angle coefficients need to be re-specified.
|
||||
|
||||
NOTE: When both an angle and pair style is defined, the
|
||||
"special_bonds"_special_bonds.html command often needs to be used to
|
||||
turn off (or weight) the pairwise interaction that would otherwise
|
||||
exist between 3 bonded atoms.
|
||||
|
||||
In the formulas listed for each angle style, {theta} is the angle
|
||||
between the 3 atoms in the angle.
|
||||
|
||||
:line
|
||||
|
||||
Here is an alphabetic list of angle styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated "angle_coeff"_angle_coeff.html command.
|
||||
|
||||
Note that there are also additional angle styles submitted by users
|
||||
which are included in the LAMMPS distribution. The list of these with
|
||||
links to the individual styles are given in the angle section of "this
|
||||
page"_Section_commands.html#cmd_5.
|
||||
|
||||
"angle_style none"_angle_none.html - turn off angle interactions
|
||||
"angle_style zero"_angle_zero.html - topology but no interactions
|
||||
"angle_style hybrid"_angle_hybrid.html - define multiple styles of angle interactions :ul
|
||||
|
||||
"angle_style charmm"_angle_charmm.html - CHARMM angle
|
||||
"angle_style class2"_angle_class2.html - COMPASS (class 2) angle
|
||||
"angle_style cosine"_angle_cosine.html - cosine angle potential
|
||||
"angle_style cosine/delta"_angle_cosine_delta.html - difference of cosines angle potential
|
||||
"angle_style cosine/periodic"_angle_cosine_periodic.html - DREIDING angle
|
||||
"angle_style cosine/squared"_angle_cosine_squared.html - cosine squared angle potential
|
||||
"angle_style harmonic"_angle_harmonic.html - harmonic angle
|
||||
"angle_style table"_angle_table.html - tabulated by angle :ul
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
Angle styles can only be set for atom_styles that allow angles to be
|
||||
defined.
|
||||
|
||||
Most angle styles are part of the MOLECULE package. They are only
|
||||
enabled if LAMMPS was built with that package. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
The doc pages for individual bond potentials tell if it is part of a
|
||||
package.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:]
|
||||
|
||||
angle_style none :pre
|
||||
@ -1,327 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style table command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style table command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-table-command">
|
||||
<span id="index-0"></span><h1>angle_style table command<a class="headerlink" href="#angle-style-table-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="angle-style-table-omp-command">
|
||||
<h1>angle_style table/omp command<a class="headerlink" href="#angle-style-table-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style table style N
|
||||
</pre></div>
|
||||
</div>
|
||||
<ul class="simple">
|
||||
<li>style = <em>linear</em> or <em>spline</em> = method of interpolation</li>
|
||||
<li>N = use N values in table</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style table linear 1000
|
||||
angle_coeff 3 file.table ENTRY1
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Style <em>table</em> creates interpolation tables of length <em>N</em> from angle
|
||||
potential and derivative values listed in a file(s) as a function of
|
||||
angle The files are read by the <a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a>
|
||||
command.</p>
|
||||
<p>The interpolation tables are created by fitting cubic splines to the
|
||||
file values and interpolating energy and derivative values at each of
|
||||
<em>N</em> angles. During a simulation, these tables are used to interpolate
|
||||
energy and force values on individual atoms as needed. The
|
||||
interpolation is done in one of 2 styles: <em>linear</em> or <em>spline</em>.</p>
|
||||
<p>For the <em>linear</em> style, the angle is used to find 2 surrounding table
|
||||
values from which an energy or its derivative is computed by linear
|
||||
interpolation.</p>
|
||||
<p>For the <em>spline</em> style, a cubic spline coefficients are computed and
|
||||
stored at each of the <em>N</em> values in the table. The angle is used to
|
||||
find the appropriate set of coefficients which are used to evaluate a
|
||||
cubic polynomial which computes the energy or derivative.</p>
|
||||
<p>The following coefficients must be defined for each angle type via the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command as in the example above.</p>
|
||||
<ul class="simple">
|
||||
<li>filename</li>
|
||||
<li>keyword</li>
|
||||
</ul>
|
||||
<p>The filename specifies a file containing tabulated energy and
|
||||
derivative values. The keyword specifies a section of the file. The
|
||||
format of this file is described below.</p>
|
||||
<hr class="docutils" />
|
||||
<p>The format of a tabulated file is as follows (without the
|
||||
parenthesized comments):</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre><span class="c"># Angle potential for harmonic (one or more comment or blank lines)</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<div class="highlight-python"><div class="highlight"><pre>HAM (keyword is the first text on line)
|
||||
N 181 FP 0 0 EQ 90.0 (N, FP, EQ parameters)
|
||||
(blank line)
|
||||
N 181 FP 0 0 (N, FP parameters)
|
||||
1 0.0 200.5 2.5 (index, angle, energy, derivative)
|
||||
2 1.0 198.0 2.5
|
||||
...
|
||||
181 180.0 0.0 0.0
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>A section begins with a non-blank line whose 1st character is not a
|
||||
“#”; blank lines or lines starting with “#” can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
initial text must match the argument specified in the
|
||||
<a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command. The next line lists (in any
|
||||
order) one or more parameters for the table. Each parameter is a
|
||||
keyword followed by one or more numeric values.</p>
|
||||
<p>The parameter “N” is required and its value is the number of table
|
||||
entries that follow. Note that this may be different than the <em>N</em>
|
||||
specified in the <a class="reference internal" href="angle_style.html"><em>angle_style table</em></a> command. Let
|
||||
Ntable = <em>N</em> in the angle_style command, and Nfile = “N” in the
|
||||
tabulated file. What LAMMPS does is a preliminary interpolation by
|
||||
creating splines using the Nfile tabulated values as nodal points. It
|
||||
uses these to interpolate as needed to generate energy and derivative
|
||||
values at Ntable different points. The resulting tables of length
|
||||
Ntable are then used as described above, when computing energy and
|
||||
force for individual angles and their atoms. This means that if you
|
||||
want the interpolation tables of length Ntable to match exactly what
|
||||
is in the tabulated file (with effectively no preliminary
|
||||
interpolation), you should set Ntable = Nfile.</p>
|
||||
<p>The “FP” parameter is optional. If used, it is followed by two values
|
||||
fplo and fphi, which are the 2nd derivatives at the innermost and
|
||||
outermost angle settings. These values are needed by the spline
|
||||
construction routines. If not specified by the “FP” parameter, they
|
||||
are estimated (less accurately) by the first two and last two
|
||||
derivative values in the table.</p>
|
||||
<p>The “EQ” parameter is also optional. If used, it is followed by a the
|
||||
equilibrium angle value, which is used, for example, by the <a class="reference internal" href="fix_shake.html"><em>fix shake</em></a> command. If not used, the equilibrium angle is
|
||||
set to 180.0.</p>
|
||||
<p>Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the angle value (in degrees), the 3rd value is the energy (in energy
|
||||
units), and the 4th is -dE/d(theta) (also in energy units). The 3rd
|
||||
term is the energy of the 3-atom configuration for the specified
|
||||
angle. The last term is the derivative of the energy with respect to
|
||||
the angle (in degrees, not radians). Thus the units of the last term
|
||||
are still energy, not force. The angle values must increase from one
|
||||
line to the next. The angle values must also begin with 0.0 and end
|
||||
with 180.0, i.e. span the full range of possible angles.</p>
|
||||
<p>Note that one file can contain many sections, each with a tabulated
|
||||
potential. LAMMPS reads the file section by section until it finds
|
||||
one that matches the specified keyword.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,157 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style table command :h3
|
||||
angle_style table/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style table style N :pre
|
||||
|
||||
style = {linear} or {spline} = method of interpolation
|
||||
N = use N values in table :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style table linear 1000
|
||||
angle_coeff 3 file.table ENTRY1 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Style {table} creates interpolation tables of length {N} from angle
|
||||
potential and derivative values listed in a file(s) as a function of
|
||||
angle The files are read by the "angle_coeff"_angle_coeff.html
|
||||
command.
|
||||
|
||||
The interpolation tables are created by fitting cubic splines to the
|
||||
file values and interpolating energy and derivative values at each of
|
||||
{N} angles. During a simulation, these tables are used to interpolate
|
||||
energy and force values on individual atoms as needed. The
|
||||
interpolation is done in one of 2 styles: {linear} or {spline}.
|
||||
|
||||
For the {linear} style, the angle is used to find 2 surrounding table
|
||||
values from which an energy or its derivative is computed by linear
|
||||
interpolation.
|
||||
|
||||
For the {spline} style, a cubic spline coefficients are computed and
|
||||
stored at each of the {N} values in the table. The angle is used to
|
||||
find the appropriate set of coefficients which are used to evaluate a
|
||||
cubic polynomial which computes the energy or derivative.
|
||||
|
||||
The following coefficients must be defined for each angle type via the
|
||||
"angle_coeff"_angle_coeff.html command as in the example above.
|
||||
|
||||
filename
|
||||
keyword :ul
|
||||
|
||||
The filename specifies a file containing tabulated energy and
|
||||
derivative values. The keyword specifies a section of the file. The
|
||||
format of this file is described below.
|
||||
|
||||
:line
|
||||
|
||||
The format of a tabulated file is as follows (without the
|
||||
parenthesized comments):
|
||||
|
||||
# Angle potential for harmonic (one or more comment or blank lines) :pre
|
||||
|
||||
HAM (keyword is the first text on line)
|
||||
N 181 FP 0 0 EQ 90.0 (N, FP, EQ parameters)
|
||||
(blank line)
|
||||
N 181 FP 0 0 (N, FP parameters)
|
||||
1 0.0 200.5 2.5 (index, angle, energy, derivative)
|
||||
2 1.0 198.0 2.5
|
||||
...
|
||||
181 180.0 0.0 0.0 :pre
|
||||
|
||||
A section begins with a non-blank line whose 1st character is not a
|
||||
"#"; blank lines or lines starting with "#" can be used as comments
|
||||
between sections. The first line begins with a keyword which
|
||||
identifies the section. The line can contain additional text, but the
|
||||
initial text must match the argument specified in the
|
||||
"angle_coeff"_angle_coeff.html command. The next line lists (in any
|
||||
order) one or more parameters for the table. Each parameter is a
|
||||
keyword followed by one or more numeric values.
|
||||
|
||||
The parameter "N" is required and its value is the number of table
|
||||
entries that follow. Note that this may be different than the {N}
|
||||
specified in the "angle_style table"_angle_style.html command. Let
|
||||
Ntable = {N} in the angle_style command, and Nfile = "N" in the
|
||||
tabulated file. What LAMMPS does is a preliminary interpolation by
|
||||
creating splines using the Nfile tabulated values as nodal points. It
|
||||
uses these to interpolate as needed to generate energy and derivative
|
||||
values at Ntable different points. The resulting tables of length
|
||||
Ntable are then used as described above, when computing energy and
|
||||
force for individual angles and their atoms. This means that if you
|
||||
want the interpolation tables of length Ntable to match exactly what
|
||||
is in the tabulated file (with effectively no preliminary
|
||||
interpolation), you should set Ntable = Nfile.
|
||||
|
||||
The "FP" parameter is optional. If used, it is followed by two values
|
||||
fplo and fphi, which are the 2nd derivatives at the innermost and
|
||||
outermost angle settings. These values are needed by the spline
|
||||
construction routines. If not specified by the "FP" parameter, they
|
||||
are estimated (less accurately) by the first two and last two
|
||||
derivative values in the table.
|
||||
|
||||
The "EQ" parameter is also optional. If used, it is followed by a the
|
||||
equilibrium angle value, which is used, for example, by the "fix
|
||||
shake"_fix_shake.html command. If not used, the equilibrium angle is
|
||||
set to 180.0.
|
||||
|
||||
Following a blank line, the next N lines list the tabulated values.
|
||||
On each line, the 1st value is the index from 1 to N, the 2nd value is
|
||||
the angle value (in degrees), the 3rd value is the energy (in energy
|
||||
units), and the 4th is -dE/d(theta) (also in energy units). The 3rd
|
||||
term is the energy of the 3-atom configuration for the specified
|
||||
angle. The last term is the derivative of the energy with respect to
|
||||
the angle (in degrees, not radians). Thus the units of the last term
|
||||
are still energy, not force. The angle values must increase from one
|
||||
line to the next. The angle values must also begin with 0.0 and end
|
||||
with 180.0, i.e. span the full range of possible angles.
|
||||
|
||||
Note that one file can contain many sections, each with a tabulated
|
||||
potential. LAMMPS reads the file section by section until it finds
|
||||
one that matches the specified keyword.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This angle style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_coeff"_angle_coeff.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,236 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>angle_style zero command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>angle_style zero command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="angle-style-zero-command">
|
||||
<span id="index-0"></span><h1>angle_style zero command<a class="headerlink" href="#angle-style-zero-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<pre class="literal-block">
|
||||
angle_style zero <em>nocoeff</em>
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>angle_style zero
|
||||
angle_style zero nocoeff
|
||||
angle_coeff *
|
||||
angle_coeff * 120.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Using an angle style of zero means angle forces and energies are not
|
||||
computed, but the geometry of angle triplets is still accessible to
|
||||
other commands.</p>
|
||||
<p>As an example, the <a class="reference internal" href="compute_angle_local.html"><em>compute angle/local</em></a>
|
||||
command can be used to compute the theta values for the list of
|
||||
triplets of angle atoms listed in the data file read by the
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a> command. If no angle style is defined,
|
||||
this command cannot be used.</p>
|
||||
<p>The optional <em>nocoeff</em> flag allows to read data files with AngleCoeff
|
||||
section for any angle style. Similarly, any angle_coeff commands
|
||||
will only be checked for the angle type number and the rest ignored.</p>
|
||||
<p>Note that the <a class="reference internal" href="angle_coeff.html"><em>angle_coeff</em></a> command must be used for
|
||||
all angle types. If specified, there can be only one value, which is
|
||||
going to be used to assign an equilibrium angle, e.g. for use with
|
||||
<a class="reference internal" href="fix_shake.html"><em>fix shake</em></a>.</p>
|
||||
</div>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<blockquote>
|
||||
<div>none</div></blockquote>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="angle_none.html"><em>angle_style none</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,49 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
angle_style zero command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
angle_style zero {nocoeff} :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
angle_style zero
|
||||
angle_style zero nocoeff
|
||||
angle_coeff *
|
||||
angle_coeff * 120.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Using an angle style of zero means angle forces and energies are not
|
||||
computed, but the geometry of angle triplets is still accessible to
|
||||
other commands.
|
||||
|
||||
As an example, the "compute angle/local"_compute_angle_local.html
|
||||
command can be used to compute the theta values for the list of
|
||||
triplets of angle atoms listed in the data file read by the
|
||||
"read_data"_read_data.html command. If no angle style is defined,
|
||||
this command cannot be used.
|
||||
|
||||
The optional {nocoeff} flag allows to read data files with AngleCoeff
|
||||
section for any angle style. Similarly, any angle_coeff commands
|
||||
will only be checked for the angle type number and the rest ignored.
|
||||
|
||||
Note that the "angle_coeff"_angle_coeff.html command must be used for
|
||||
all angle types. If specified, there can be only one value, which is
|
||||
going to be used to assign an equilibrium angle, e.g. for use with
|
||||
"fix shake"_fix_shake.html.
|
||||
|
||||
[Restrictions:] none
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"angle_style none"_angle_none.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,343 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>atom_modify command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>atom_modify command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="atom-modify-command">
|
||||
<span id="index-0"></span><h1>atom_modify command<a class="headerlink" href="#atom-modify-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>atom_modify keyword values ...
|
||||
</pre></div>
|
||||
</div>
|
||||
<ul class="simple">
|
||||
<li>one or more keyword/value pairs may be appended</li>
|
||||
<li>keyword = <em>id</em> or <em>map</em> or <em>first</em> or <em>sort</em></li>
|
||||
</ul>
|
||||
<pre class="literal-block">
|
||||
<em>id</em> value = <em>yes</em> or <em>no</em>
|
||||
<em>map</em> value = <em>array</em> or <em>hash</em>
|
||||
<em>first</em> value = group-ID = group whose atoms will appear first in internal atom lists
|
||||
<em>sort</em> values = Nfreq binsize
|
||||
Nfreq = sort atoms spatially every this many time steps
|
||||
binsize = bin size for spatial sorting (distance units)
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>atom_modify map hash
|
||||
atom_modify map array sort 10000 2.0
|
||||
atom_modify first colloid
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Modify certain attributes of atoms defined and stored within LAMMPS,
|
||||
in addition to what is specified by the <a class="reference internal" href="atom_style.html"><em>atom_style</em></a>
|
||||
command. The <em>id</em> and <em>map</em> keywords must be specified before a
|
||||
simulation box is defined; other keywords can be specified any time.</p>
|
||||
<p>The <em>id</em> keyword determines whether non-zero atom IDs can be assigned
|
||||
to each atom. If the value is <em>yes</em>, which is the default, IDs are
|
||||
assigned, whether you use the <a class="reference internal" href="create_atoms.html"><em>create atoms</em></a> or
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a> or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a>
|
||||
commands to initialize atoms. If the value is <em>no</em> the IDs for all
|
||||
atoms are assumed to be 0.</p>
|
||||
<p>If atom IDs are used, they must all be positive integers. They should
|
||||
also be unique, though LAMMPS does not check for this. Typically they
|
||||
should also be consecutively numbered (from 1 to Natoms), though this
|
||||
is not required. Molecular <a class="reference internal" href="atom_style.html"><em>atom styles</em></a> are those
|
||||
that store bond topology information (styles bond, angle, molecular,
|
||||
full). These styles require atom IDs since the IDs are used to encode
|
||||
the topology. Some other LAMMPS commands also require the use of atom
|
||||
IDs. E.g. some many-body pair styles use them to avoid double
|
||||
computation of the I-J interaction between two atoms.</p>
|
||||
<p>The only reason not to use atom IDs is if you are running an atomic
|
||||
simulation so large that IDs cannot be uniquely assigned. For a
|
||||
default LAMMPS build this limit is 2^31 or about 2 billion atoms.
|
||||
However, even in this case, you can use 64-bit atom IDs, allowing 2^63
|
||||
or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG
|
||||
switch. This is described in <a class="reference internal" href="Section_start.html#start-2"><span>Section 2.2</span></a>
|
||||
of the manual. If atom IDs are not used, they must be specified as 0
|
||||
for all atoms, e.g. in a data or restart file.</p>
|
||||
<p>The <em>map</em> keyword determines how atom ID lookup is done for molecular
|
||||
atom styles. Lookups are performed by bond (angle, etc) routines in
|
||||
LAMMPS to find the local atom index associated with a global atom ID.</p>
|
||||
<p>When the <em>array</em> value is used, each processor stores a lookup table
|
||||
of length N, where N is the largest atom ID in the system. This is a
|
||||
fast, simple method for many simulations, but requires too much memory
|
||||
for large simulations. The <em>hash</em> value uses a hash table to perform
|
||||
the lookups. This can be slightly slower than the <em>array</em> method, but
|
||||
its memory cost is proportional to the number of atoms owned by a
|
||||
processor, i.e. N/P when N is the total number of atoms in the system
|
||||
and P is the number of processors.</p>
|
||||
<p>When this setting is not specified in your input script, LAMMPS
|
||||
creates a map, if one is needed, as an array or hash. See the
|
||||
discussion of default values below for how LAMMPS chooses which kind
|
||||
of map to build. Note that atomic systems do not normally need to
|
||||
create a map. However, even in this case some LAMMPS commands will
|
||||
create a map to find atoms (and then destroy it), or require a
|
||||
permanent map. An example of the former is the <a class="reference internal" href="velocity.html"><em>velocity loop all</em></a> command, which uses a map when looping over all
|
||||
atoms and insuring the same velocity values are assigned to an atom
|
||||
ID, no matter which processor owns it.</p>
|
||||
<p>The <em>first</em> keyword allows a <a class="reference internal" href="group.html"><em>group</em></a> to be specified whose
|
||||
atoms will be maintained as the first atoms in each processor’s list
|
||||
of owned atoms. This in only useful when the specified group is a
|
||||
small fraction of all the atoms, and there are other operations LAMMPS
|
||||
is performing that will be sped-up significantly by being able to loop
|
||||
over the smaller set of atoms. Otherwise the reordering required by
|
||||
this option will be a net slow-down. The <a class="reference internal" href="neigh_modify.html"><em>neigh_modify include</em></a> and <a class="reference internal" href="comm_modify.html"><em>comm_modify group</em></a>
|
||||
commands are two examples of commands that require this setting to
|
||||
work efficiently. Several <a class="reference internal" href="fix.html"><em>fixes</em></a>, most notably time
|
||||
integration fixes like <a class="reference internal" href="fix_nve.html"><em>fix nve</em></a>, also take advantage of
|
||||
this setting if the group they operate on is the group specified by
|
||||
this command. Note that specifying “all” as the group-ID effectively
|
||||
turns off the <em>first</em> option.</p>
|
||||
<p>It is OK to use the <em>first</em> keyword with a group that has not yet been
|
||||
defined, e.g. to use the atom_modify first command at the beginning of
|
||||
your input script. LAMMPS does not use the group until a simullation
|
||||
is run.</p>
|
||||
<p>The <em>sort</em> keyword turns on a spatial sorting or reordering of atoms
|
||||
within each processor’s sub-domain every <em>Nfreq</em> timesteps. If
|
||||
<em>Nfreq</em> is set to 0, then sorting is turned off. Sorting can improve
|
||||
cache performance and thus speed-up a LAMMPS simulation, as discussed
|
||||
in a paper by <a class="reference internal" href="#meloni"><span>(Meloni)</span></a>. Its efficacy depends on the problem
|
||||
size (atoms/processor), how quickly the system becomes disordered, and
|
||||
various other factors. As a general rule, sorting is typically more
|
||||
effective at speeding up simulations of liquids as opposed to solids.
|
||||
In tests we have done, the speed-up can range from zero to 3-4x.</p>
|
||||
<p>Reordering is peformed every <em>Nfreq</em> timesteps during a dynamics run
|
||||
or iterations during a minimization. More precisely, reordering
|
||||
occurs at the first reneighboring that occurs after the target
|
||||
timestep. The reordering is performed locally by each processor,
|
||||
using bins of the specified <em>binsize</em>. If <em>binsize</em> is set to 0.0,
|
||||
then a binsize equal to half the <a class="reference internal" href="neighbor.html"><em>neighbor</em></a> cutoff
|
||||
distance (force cutoff plus skin distance) is used, which is a
|
||||
reasonable value. After the atoms have been binned, they are
|
||||
reordered so that atoms in the same bin are adjacent to each other in
|
||||
the processor’s 1d list of atoms.</p>
|
||||
<p>The goal of this procedure is for atoms to put atoms close to each
|
||||
other in the processor’s one-dimensional list of atoms that are also
|
||||
near to each other spatially. This can improve cache performance when
|
||||
pairwise intereractions and neighbor lists are computed. Note that if
|
||||
bins are too small, there will be few atoms/bin. Likewise if bins are
|
||||
too large, there will be many atoms/bin. In both cases, the goal of
|
||||
cache locality will be undermined.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">Running a simulation with sorting on versus off should not
|
||||
change the simulation results in a statistical sense. However, a
|
||||
different ordering will induce round-off differences, which will lead
|
||||
to diverging trajectories over time when comparing two simluations.
|
||||
Various commands, particularly those which use random numbers
|
||||
(e.g. <a class="reference internal" href="velocity.html"><em>velocity create</em></a>, and <a class="reference internal" href="fix_langevin.html"><em>fix langevin</em></a>), may generate (statistically identical)
|
||||
results which depend on the order in which atoms are processed. The
|
||||
order of atoms in a <a class="reference internal" href="dump.html"><em>dump</em></a> file will also typically change
|
||||
if sorting is enabled.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>first</em> and <em>sort</em> options cannot be used together. Since sorting
|
||||
is on by default, it will be turned off if the <em>first</em> keyword is
|
||||
used with a group-ID that is not “all”.</p>
|
||||
<p><strong>Related commands:</strong> none</p>
|
||||
</div>
|
||||
<div class="section" id="default">
|
||||
<h2>Default<a class="headerlink" href="#default" title="Permalink to this headline">¶</a></h2>
|
||||
<p>By default, <em>id</em> is yes. By default, atomic systems (no bond topology
|
||||
info) do not use a map. For molecular systems (with bond topology
|
||||
info), a map is used. The default map style is array if no atom ID is
|
||||
larger than 1 million, otherwise the default is hash. By default, a
|
||||
“first” group is not defined. By default, sorting is enabled with a
|
||||
frequency of 1000 and a binsize of 0.0, which means the neighbor
|
||||
cutoff will be used to set the bin size.</p>
|
||||
<hr class="docutils" />
|
||||
<p id="meloni"><strong>(Meloni)</strong> Meloni, Rosati and Colombo, J Chem Phys, 126, 121102 (2007).</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,170 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS
|
||||
Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
atom_modify command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
atom_modify keyword values ... :pre
|
||||
|
||||
one or more keyword/value pairs may be appended :ulb,l
|
||||
keyword = {id} or {map} or {first} or {sort} :l
|
||||
{id} value = {yes} or {no}
|
||||
{map} value = {array} or {hash}
|
||||
{first} value = group-ID = group whose atoms will appear first in internal atom lists
|
||||
{sort} values = Nfreq binsize
|
||||
Nfreq = sort atoms spatially every this many time steps
|
||||
binsize = bin size for spatial sorting (distance units) :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
atom_modify map hash
|
||||
atom_modify map array sort 10000 2.0
|
||||
atom_modify first colloid :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Modify certain attributes of atoms defined and stored within LAMMPS,
|
||||
in addition to what is specified by the "atom_style"_atom_style.html
|
||||
command. The {id} and {map} keywords must be specified before a
|
||||
simulation box is defined; other keywords can be specified any time.
|
||||
|
||||
The {id} keyword determines whether non-zero atom IDs can be assigned
|
||||
to each atom. If the value is {yes}, which is the default, IDs are
|
||||
assigned, whether you use the "create atoms"_create_atoms.html or
|
||||
"read_data"_read_data.html or "read_restart"_read_restart.html
|
||||
commands to initialize atoms. If the value is {no} the IDs for all
|
||||
atoms are assumed to be 0.
|
||||
|
||||
If atom IDs are used, they must all be positive integers. They should
|
||||
also be unique, though LAMMPS does not check for this. Typically they
|
||||
should also be consecutively numbered (from 1 to Natoms), though this
|
||||
is not required. Molecular "atom styles"_atom_style.html are those
|
||||
that store bond topology information (styles bond, angle, molecular,
|
||||
full). These styles require atom IDs since the IDs are used to encode
|
||||
the topology. Some other LAMMPS commands also require the use of atom
|
||||
IDs. E.g. some many-body pair styles use them to avoid double
|
||||
computation of the I-J interaction between two atoms.
|
||||
|
||||
The only reason not to use atom IDs is if you are running an atomic
|
||||
simulation so large that IDs cannot be uniquely assigned. For a
|
||||
default LAMMPS build this limit is 2^31 or about 2 billion atoms.
|
||||
However, even in this case, you can use 64-bit atom IDs, allowing 2^63
|
||||
or about 9e18 atoms, if you build LAMMPS with the - DLAMMPS_BIGBIG
|
||||
switch. This is described in "Section 2.2"_Section_start.html#start_2
|
||||
of the manual. If atom IDs are not used, they must be specified as 0
|
||||
for all atoms, e.g. in a data or restart file.
|
||||
|
||||
The {map} keyword determines how atom ID lookup is done for molecular
|
||||
atom styles. Lookups are performed by bond (angle, etc) routines in
|
||||
LAMMPS to find the local atom index associated with a global atom ID.
|
||||
|
||||
When the {array} value is used, each processor stores a lookup table
|
||||
of length N, where N is the largest atom ID in the system. This is a
|
||||
fast, simple method for many simulations, but requires too much memory
|
||||
for large simulations. The {hash} value uses a hash table to perform
|
||||
the lookups. This can be slightly slower than the {array} method, but
|
||||
its memory cost is proportional to the number of atoms owned by a
|
||||
processor, i.e. N/P when N is the total number of atoms in the system
|
||||
and P is the number of processors.
|
||||
|
||||
When this setting is not specified in your input script, LAMMPS
|
||||
creates a map, if one is needed, as an array or hash. See the
|
||||
discussion of default values below for how LAMMPS chooses which kind
|
||||
of map to build. Note that atomic systems do not normally need to
|
||||
create a map. However, even in this case some LAMMPS commands will
|
||||
create a map to find atoms (and then destroy it), or require a
|
||||
permanent map. An example of the former is the "velocity loop
|
||||
all"_velocity.html command, which uses a map when looping over all
|
||||
atoms and insuring the same velocity values are assigned to an atom
|
||||
ID, no matter which processor owns it.
|
||||
|
||||
The {first} keyword allows a "group"_group.html to be specified whose
|
||||
atoms will be maintained as the first atoms in each processor's list
|
||||
of owned atoms. This in only useful when the specified group is a
|
||||
small fraction of all the atoms, and there are other operations LAMMPS
|
||||
is performing that will be sped-up significantly by being able to loop
|
||||
over the smaller set of atoms. Otherwise the reordering required by
|
||||
this option will be a net slow-down. The "neigh_modify
|
||||
include"_neigh_modify.html and "comm_modify group"_comm_modify.html
|
||||
commands are two examples of commands that require this setting to
|
||||
work efficiently. Several "fixes"_fix.html, most notably time
|
||||
integration fixes like "fix nve"_fix_nve.html, also take advantage of
|
||||
this setting if the group they operate on is the group specified by
|
||||
this command. Note that specifying "all" as the group-ID effectively
|
||||
turns off the {first} option.
|
||||
|
||||
It is OK to use the {first} keyword with a group that has not yet been
|
||||
defined, e.g. to use the atom_modify first command at the beginning of
|
||||
your input script. LAMMPS does not use the group until a simullation
|
||||
is run.
|
||||
|
||||
The {sort} keyword turns on a spatial sorting or reordering of atoms
|
||||
within each processor's sub-domain every {Nfreq} timesteps. If
|
||||
{Nfreq} is set to 0, then sorting is turned off. Sorting can improve
|
||||
cache performance and thus speed-up a LAMMPS simulation, as discussed
|
||||
in a paper by "(Meloni)"_#Meloni. Its efficacy depends on the problem
|
||||
size (atoms/processor), how quickly the system becomes disordered, and
|
||||
various other factors. As a general rule, sorting is typically more
|
||||
effective at speeding up simulations of liquids as opposed to solids.
|
||||
In tests we have done, the speed-up can range from zero to 3-4x.
|
||||
|
||||
Reordering is peformed every {Nfreq} timesteps during a dynamics run
|
||||
or iterations during a minimization. More precisely, reordering
|
||||
occurs at the first reneighboring that occurs after the target
|
||||
timestep. The reordering is performed locally by each processor,
|
||||
using bins of the specified {binsize}. If {binsize} is set to 0.0,
|
||||
then a binsize equal to half the "neighbor"_neighbor.html cutoff
|
||||
distance (force cutoff plus skin distance) is used, which is a
|
||||
reasonable value. After the atoms have been binned, they are
|
||||
reordered so that atoms in the same bin are adjacent to each other in
|
||||
the processor's 1d list of atoms.
|
||||
|
||||
The goal of this procedure is for atoms to put atoms close to each
|
||||
other in the processor's one-dimensional list of atoms that are also
|
||||
near to each other spatially. This can improve cache performance when
|
||||
pairwise intereractions and neighbor lists are computed. Note that if
|
||||
bins are too small, there will be few atoms/bin. Likewise if bins are
|
||||
too large, there will be many atoms/bin. In both cases, the goal of
|
||||
cache locality will be undermined.
|
||||
|
||||
NOTE: Running a simulation with sorting on versus off should not
|
||||
change the simulation results in a statistical sense. However, a
|
||||
different ordering will induce round-off differences, which will lead
|
||||
to diverging trajectories over time when comparing two simluations.
|
||||
Various commands, particularly those which use random numbers
|
||||
(e.g. "velocity create"_velocity.html, and "fix
|
||||
langevin"_fix_langevin.html), may generate (statistically identical)
|
||||
results which depend on the order in which atoms are processed. The
|
||||
order of atoms in a "dump"_dump.html file will also typically change
|
||||
if sorting is enabled.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
The {first} and {sort} options cannot be used together. Since sorting
|
||||
is on by default, it will be turned off if the {first} keyword is
|
||||
used with a group-ID that is not "all".
|
||||
|
||||
[Related commands:] none
|
||||
|
||||
[Default:]
|
||||
|
||||
By default, {id} is yes. By default, atomic systems (no bond topology
|
||||
info) do not use a map. For molecular systems (with bond topology
|
||||
info), a map is used. The default map style is array if no atom ID is
|
||||
larger than 1 million, otherwise the default is hash. By default, a
|
||||
"first" group is not defined. By default, sorting is enabled with a
|
||||
frequency of 1000 and a binsize of 0.0, which means the neighbor
|
||||
cutoff will be used to set the bin size.
|
||||
|
||||
:line
|
||||
|
||||
:link(Meloni)
|
||||
[(Meloni)] Meloni, Rosati and Colombo, J Chem Phys, 126, 121102 (2007).
|
||||
@ -1,506 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>atom_style command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>atom_style command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="atom-style-command">
|
||||
<span id="index-0"></span><h1>atom_style command<a class="headerlink" href="#atom-style-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>atom_style style args
|
||||
</pre></div>
|
||||
</div>
|
||||
<ul class="simple">
|
||||
<li>style = <em>angle</em> or <em>atomic</em> or <em>body</em> or <em>bond</em> or <em>charge</em> or <em>dipole</em> or <em>dpd</em> or <em>electron</em> or <em>ellipsoid</em> or <em>full</em> or <em>line</em> or <em>meso</em> or <em>molecular</em> or <em>peri</em> or <em>smd</em> or <em>sphere</em> or <em>tri</em> or <em>template</em> or <em>hybrid</em></li>
|
||||
</ul>
|
||||
<pre class="literal-block">
|
||||
args = none for any style except the following
|
||||
<em>body</em> args = bstyle bstyle-args
|
||||
bstyle = style of body particles
|
||||
bstyle-args = additional arguments specific to the bstyle
|
||||
see the <a class="reference internal" href="body.html"><em>body</em></a> doc page for details
|
||||
<em>template</em> args = template-ID
|
||||
template-ID = ID of molecule template specified in a separate <a class="reference internal" href="molecule.html"><em>molecule</em></a> command
|
||||
<em>hybrid</em> args = list of one or more sub-styles, each with their args
|
||||
</pre>
|
||||
<ul class="simple">
|
||||
<li>accelerated styles (with same args) = <em>angle/cuda</em> or <em>angle/kk</em> or <em>atomic/cuda</em> or <em>atomic/kk</em> or <em>bond/kk</em> or <em>charge/cuda</em> or <em>charge/kk</em> or <em>full/cuda</em> or <em>full/kk</em> or <em>molecular/kk</em></li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>atom_style atomic
|
||||
atom_style bond
|
||||
atom_style full
|
||||
atom_style full/cuda
|
||||
atom_style body nparticle 2 10
|
||||
atom_style hybrid charge bond
|
||||
atom_style hybrid charge body nparticle 2 5
|
||||
atom_style template myMols
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Define what style of atoms to use in a simulation. This determines
|
||||
what attributes are associated with the atoms. This command must be
|
||||
used before a simulation is setup via a <a class="reference internal" href="read_data.html"><em>read_data</em></a>,
|
||||
<a class="reference internal" href="read_restart.html"><em>read_restart</em></a>, or <a class="reference internal" href="create_box.html"><em>create_box</em></a>
|
||||
command.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">Many of the atom styles discussed here are only enabled if
|
||||
LAMMPS was built with a specific package, as listed below in the
|
||||
Restrictions section.</p>
|
||||
</div>
|
||||
<p>Once a style is assigned, it cannot be changed, so use a style general
|
||||
enough to encompass all attributes. E.g. with style <em>bond</em>, angular
|
||||
terms cannot be used or added later to the model. It is OK to use a
|
||||
style more general than needed, though it may be slightly inefficient.</p>
|
||||
<p>The choice of style affects what quantities are stored by each atom,
|
||||
what quantities are communicated between processors to enable forces
|
||||
to be computed, and what quantities are listed in the data file read
|
||||
by the <a class="reference internal" href="read_data.html"><em>read_data</em></a> command.</p>
|
||||
<p>These are the additional attributes of each style and the typical
|
||||
kinds of physical systems they are used to model. All styles store
|
||||
coordinates, velocities, atom IDs and types. See the
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a>, <a class="reference internal" href="create_atoms.html"><em>create_atoms</em></a>, and
|
||||
<a class="reference internal" href="set.html"><em>set</em></a> commands for info on how to set these various
|
||||
quantities.</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="13%" />
|
||||
<col width="50%" />
|
||||
<col width="36%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr class="row-odd"><td><em>angle</em></td>
|
||||
<td>bonds and angles</td>
|
||||
<td>bead-spring polymers with stiffness</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>atomic</em></td>
|
||||
<td>only the default values</td>
|
||||
<td>coarse-grain liquids, solids, metals</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><em>body</em></td>
|
||||
<td>mass, inertia moments, quaternion, angular momentum</td>
|
||||
<td>arbitrary bodies</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>bond</em></td>
|
||||
<td>bonds</td>
|
||||
<td>bead-spring polymers</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><em>charge</em></td>
|
||||
<td>charge</td>
|
||||
<td>atomic system with charges</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>dipole</em></td>
|
||||
<td>charge and dipole moment</td>
|
||||
<td>system with dipolar particles</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><em>dpd</em></td>
|
||||
<td>internal temperature and internal energies</td>
|
||||
<td>DPD particles</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>electron</em></td>
|
||||
<td>charge and spin and eradius</td>
|
||||
<td>electronic force field</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><em>ellipsoid</em></td>
|
||||
<td>shape, quaternion, angular momentum</td>
|
||||
<td>aspherical particles</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>full</em></td>
|
||||
<td>molecular + charge</td>
|
||||
<td>bio-molecules</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><em>line</em></td>
|
||||
<td>end points, angular velocity</td>
|
||||
<td>rigid bodies</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>meso</em></td>
|
||||
<td>rho, e, cv</td>
|
||||
<td>SPH particles</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><em>molecular</em></td>
|
||||
<td>bonds, angles, dihedrals, impropers</td>
|
||||
<td>uncharged molecules</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>peri</em></td>
|
||||
<td>mass, volume</td>
|
||||
<td>mesocopic Peridynamic models</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><em>smd</em></td>
|
||||
<td>volume, kernel diameter, contact radius, mass</td>
|
||||
<td>solid and fluid SPH particles</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>sphere</em></td>
|
||||
<td>diameter, mass, angular velocity</td>
|
||||
<td>granular models</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><em>template</em></td>
|
||||
<td>template index, template atom</td>
|
||||
<td>small molecules with fixed topology</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>tri</em></td>
|
||||
<td>corner points, angular momentum</td>
|
||||
<td>rigid bodies</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><em>wavepacket</em></td>
|
||||
<td>charge, spin, eradius, etag, cs_re, cs_im</td>
|
||||
<td>AWPMD</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">It is possible to add some attributes, such as a molecule ID, to
|
||||
atom styles that do not have them via the <a class="reference internal" href="fix_property_atom.html"><em>fix property/atom</em></a> command. This command also
|
||||
allows new custom attributes consisting of extra integer or
|
||||
floating-point values to be added to atoms. See the <a class="reference internal" href="fix_property_atom.html"><em>fix property/atom</em></a> doc page for examples of cases
|
||||
where this is useful and details on how to initialize, access, and
|
||||
output the custom values.</p>
|
||||
</div>
|
||||
<p>All of the above styles define point particles, except the <em>sphere</em>,
|
||||
<em>ellipsoid</em>, <em>electron</em>, <em>peri</em>, <em>wavepacket</em>, <em>line</em>, <em>tri</em>, and
|
||||
<em>body</em> styles, which define finite-size particles. See <a class="reference internal" href="Section_howto.html#howto-14"><span>Section_howto 14</span></a> for an overview of using finite-size
|
||||
particle models with LAMMPS.</p>
|
||||
<p>All of the point-particle styles assign mass to particles on a
|
||||
per-type basis, using the <a class="reference internal" href="mass.html"><em>mass</em></a> command, The finite-size
|
||||
particle styles assign mass to individual particles on a per-particle
|
||||
basis.</p>
|
||||
<p>For the <em>sphere</em> style, the particles are spheres and each stores a
|
||||
per-particle diameter and mass. If the diameter > 0.0, the particle
|
||||
is a finite-size sphere. If the diameter = 0.0, it is a point
|
||||
particle.</p>
|
||||
<p>For the <em>ellipsoid</em> style, the particles are ellipsoids and each
|
||||
stores a flag which indicates whether it is a finite-size ellipsoid or
|
||||
a point particle. If it is an ellipsoid, it also stores a shape
|
||||
vector with the 3 diamters of the ellipsoid and a quaternion 4-vector
|
||||
with its orientation.</p>
|
||||
<p>For the <em>dipole</em> style, a point dipole is defined for each point
|
||||
particle. Note that if you wish the particles to be finite-size
|
||||
spheres as in a Stockmayer potential for a dipolar fluid, so that the
|
||||
particles can rotate due to dipole-dipole interactions, then you need
|
||||
to use atom_style hybrid sphere dipole, which will assign both a
|
||||
diameter and dipole moment to each particle.</p>
|
||||
<p>For the <em>electron</em> style, the particles representing electrons are 3d
|
||||
Gaussians with a specified position and bandwidth or uncertainty in
|
||||
position, which is represented by the eradius = electron size.</p>
|
||||
<p>For the <em>peri</em> style, the particles are spherical and each stores a
|
||||
per-particle mass and volume.</p>
|
||||
<p>The <em>dpd</em> style is for dissipative particle dynamics (DPD) particles
|
||||
which store the particle internal temperature (dpdTheta), internal
|
||||
conductive energy (uCond) and internal mechanical energy (uMech).</p>
|
||||
<p>The <em>meso</em> style is for smoothed particle hydrodynamics (SPH)
|
||||
particles which store a density (rho), energy (e), and heat capacity
|
||||
(cv).</p>
|
||||
<p>The <em>smd</em> style is for a general formulation of Smooth Particle
|
||||
Hydrodynamics. Both fluids and solids can be modeled. Particles
|
||||
store the mass and volume of an integration point, a kernel diameter
|
||||
used for calculating the field variables (e.g. stress and deformation)
|
||||
and a contact radius for calculating repulsive forces which prevent
|
||||
individual physical bodies from penetretating each other.</p>
|
||||
<p>The <em>wavepacket</em> style is similar to <em>electron</em>, but the electrons may
|
||||
consist of several Gaussian wave packets, summed up with coefficients
|
||||
cs= (cs_re,cs_im). Each of the wave packets is treated as a separate
|
||||
particle in LAMMPS, wave packets belonging to the same electron must
|
||||
have identical <em>etag</em> values.</p>
|
||||
<p>For the <em>line</em> style, the particles are idealized line segments and
|
||||
each stores a per-particle mass and length and orientation (i.e. the
|
||||
end points of the line segment).</p>
|
||||
<p>For the <em>tri</em> style, the particles are planar triangles and each
|
||||
stores a per-particle mass and size and orientation (i.e. the corner
|
||||
points of the triangle).</p>
|
||||
<p>The <em>template</em> style allows molecular topolgy (bonds,angles,etc) to be
|
||||
defined via a molecule template using the <a class="reference external" href="molecule.txt">molecule</a>
|
||||
command. The template stores one or more molecules with a single copy
|
||||
of the topology info (bonds,angles,etc) of each. Individual atoms
|
||||
only store a template index and template atom to identify which
|
||||
molecule and which atom-within-the-molecule they represent. Using the
|
||||
<em>template</em> style instead of the <em>bond</em>, <em>angle</em>, <em>molecular</em> styles
|
||||
can save memory for systems comprised of a large number of small
|
||||
molecules, all of a single type (or small number of types). See the
|
||||
paper by Grime and Voth, in <a class="reference internal" href="#grime"><span>(Grime)</span></a>, for examples of how this
|
||||
can be advantageous for large-scale coarse-grained systems.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">When using the <em>template</em> style with a <a class="reference internal" href="molecule.html"><em>molecule template</em></a> that contains multiple molecules, you should
|
||||
insure the atom types, bond types, angle_types, etc in all the
|
||||
molecules are consistent. E.g. if one molecule represents H2O and
|
||||
another CO2, then you probably do not want each molecule file to
|
||||
define 2 atom types and a single bond type, because they will conflict
|
||||
with each other when a mixture system of H2O and CO2 molecules is
|
||||
defined, e.g. by the <a class="reference internal" href="read_data.html"><em>read_data</em></a> command. Rather the
|
||||
H2O molecule should define atom types 1 and 2, and bond type 1. And
|
||||
the CO2 molecule should define atom types 3 and 4 (or atom types 3 and
|
||||
2 if a single oxygen type is desired), and bond type 2.</p>
|
||||
</div>
|
||||
<p>For the <em>body</em> style, the particles are arbitrary bodies with internal
|
||||
attributes defined by the “style” of the bodies, which is specified by
|
||||
the <em>bstyle</em> argument. Body particles can represent complex entities,
|
||||
such as surface meshes of discrete points, collections of
|
||||
sub-particles, deformable objects, etc.</p>
|
||||
<p>The <a class="reference internal" href="body.html"><em>body</em></a> doc page descibes the body styles LAMMPS
|
||||
currently supports, and provides more details as to the kind of body
|
||||
particles they represent. For all styles, each body particle stores
|
||||
moments of inertia and a quaternion 4-vector, so that its orientation
|
||||
and position can be time integrated due to forces and torques.</p>
|
||||
<p>Note that there may be additional arguments required along with the
|
||||
<em>bstyle</em> specification, in the atom_style body command. These
|
||||
arguments are described in the <a class="reference internal" href="body.html"><em>body</em></a> doc page.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Typically, simulations require only a single (non-hybrid) atom style.
|
||||
If some atoms in the simulation do not have all the properties defined
|
||||
by a particular style, use the simplest style that defines all the
|
||||
needed properties by any atom. For example, if some atoms in a
|
||||
simulation are charged, but others are not, use the <em>charge</em> style.
|
||||
If some atoms have bonds, but others do not, use the <em>bond</em> style.</p>
|
||||
<p>The only scenario where the <em>hybrid</em> style is needed is if there is no
|
||||
single style which defines all needed properties of all atoms. For
|
||||
example, as mentioned above, if you want dipolar particles which will
|
||||
rotate due to torque, you need to use “atom_style hybrid sphere
|
||||
dipole”. When a hybrid style is used, atoms store and communicate the
|
||||
union of all quantities implied by the individual styles.</p>
|
||||
<p>When using the <em>hybrid</em> style, you cannot combine the <em>template</em> style
|
||||
with another molecular style that stores bond,angle,etc info on a
|
||||
per-atom basis.</p>
|
||||
<p>LAMMPS can be extended with new atom styles as well as new body
|
||||
styles; see <a class="reference internal" href="Section_modify.html"><em>this section</em></a>.</p>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em> or <em>kk</em> suffix are functionally the same as the
|
||||
corresponding style without the suffix. They have been optimized to
|
||||
run faster, depending on your available hardware, as discussed in
|
||||
<a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual. The
|
||||
accelerated styles take the same arguments and should produce the same
|
||||
results, except for round-off and precision issues.</p>
|
||||
<p>Note that other acceleration packages in LAMMPS, specifically the GPU,
|
||||
USER-INTEL, USER-OMP, and OPT packages do not use accelerated atom
|
||||
styles.</p>
|
||||
<p>The accelerated styles are part of the USER-CUDA and KOKKOS packages
|
||||
respectively. They are only enabled if LAMMPS was built with those
|
||||
packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section
|
||||
for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This command cannot be used after the simulation box is defined by a
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a> or <a class="reference internal" href="create_box.html"><em>create_box</em></a> command.</p>
|
||||
<p>Many of the styles listed above are only enabled if LAMMPS was built
|
||||
with a specific package, as listed below. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>The <em>angle</em>, <em>bond</em>, <em>full</em>, <em>molecular</em>, and <em>template</em> styles are
|
||||
part of the MOLECULE package.</p>
|
||||
<p>The <em>line</em> and <em>tri</em> styles are part of the ASPHERE package.</p>
|
||||
<p>The <em>body</em> style is part of the BODY package.</p>
|
||||
<p>The <em>dipole</em> style is part of the DIPOLE package.</p>
|
||||
<p>The <em>peri</em> style is part of the PERI package for Peridynamics.</p>
|
||||
<p>The <em>electron</em> style is part of the USER-EFF package for <a class="reference internal" href="pair_eff.html"><em>electronic force fields</em></a>.</p>
|
||||
<p>The <em>dpd</em> style is part of the USER-DPD package for dissipative
|
||||
particle dynamics (DPD).</p>
|
||||
<p>The <em>meso</em> style is part of the USER-SPH package for smoothed particle
|
||||
hydrodyanmics (SPH). See <a class="reference external" href="USER/sph/SPH_LAMMPS_userguide.pdf">this PDF guide</a> to using SPH in LAMMPS.</p>
|
||||
<p>The <em>wavepacket</em> style is part of the USER-AWPMD package for the
|
||||
<a class="reference internal" href="pair_awpmd.html"><em>antisymmetrized wave packet MD method</em></a>.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="read_data.html"><em>read_data</em></a>, <a class="reference internal" href="pair_style.html"><em>pair_style</em></a></p>
|
||||
</div>
|
||||
<div class="section" id="default">
|
||||
<h2>Default<a class="headerlink" href="#default" title="Permalink to this headline">¶</a></h2>
|
||||
<p>atom_style atomic</p>
|
||||
<hr class="docutils" />
|
||||
<p id="grime"><strong>(Grime)</strong> Grime and Voth, to appear in J Chem Theory & Computation
|
||||
(2014).</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,299 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
atom_style command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
atom_style style args :pre
|
||||
|
||||
style = {angle} or {atomic} or {body} or {bond} or {charge} or {dipole} or \
|
||||
{dpd} or {electron} or {ellipsoid} or {full} or {line} or {meso} or \
|
||||
{molecular} or {peri} or {smd} or {sphere} or {tri} or \
|
||||
{template} or {hybrid} :ulb,l
|
||||
args = none for any style except the following
|
||||
{body} args = bstyle bstyle-args
|
||||
bstyle = style of body particles
|
||||
bstyle-args = additional arguments specific to the bstyle
|
||||
see the "body"_body.html doc page for details
|
||||
{template} args = template-ID
|
||||
template-ID = ID of molecule template specified in a separate "molecule"_molecule.html command
|
||||
{hybrid} args = list of one or more sub-styles, each with their args :pre
|
||||
|
||||
accelerated styles (with same args) = {angle/cuda} or {angle/kk} or {atomic/cuda} or {atomic/kk} or {bond/kk} or {charge/cuda} or {charge/kk} or {full/cuda} or {full/kk} or {molecular/kk} :l
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
atom_style atomic
|
||||
atom_style bond
|
||||
atom_style full
|
||||
atom_style full/cuda
|
||||
atom_style body nparticle 2 10
|
||||
atom_style hybrid charge bond
|
||||
atom_style hybrid charge body nparticle 2 5
|
||||
atom_style template myMols :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Define what style of atoms to use in a simulation. This determines
|
||||
what attributes are associated with the atoms. This command must be
|
||||
used before a simulation is setup via a "read_data"_read_data.html,
|
||||
"read_restart"_read_restart.html, or "create_box"_create_box.html
|
||||
command.
|
||||
|
||||
NOTE: Many of the atom styles discussed here are only enabled if
|
||||
LAMMPS was built with a specific package, as listed below in the
|
||||
Restrictions section.
|
||||
|
||||
Once a style is assigned, it cannot be changed, so use a style general
|
||||
enough to encompass all attributes. E.g. with style {bond}, angular
|
||||
terms cannot be used or added later to the model. It is OK to use a
|
||||
style more general than needed, though it may be slightly inefficient.
|
||||
|
||||
The choice of style affects what quantities are stored by each atom,
|
||||
what quantities are communicated between processors to enable forces
|
||||
to be computed, and what quantities are listed in the data file read
|
||||
by the "read_data"_read_data.html command.
|
||||
|
||||
These are the additional attributes of each style and the typical
|
||||
kinds of physical systems they are used to model. All styles store
|
||||
coordinates, velocities, atom IDs and types. See the
|
||||
"read_data"_read_data.html, "create_atoms"_create_atoms.html, and
|
||||
"set"_set.html commands for info on how to set these various
|
||||
quantities.
|
||||
|
||||
{angle} | bonds and angles | bead-spring polymers with stiffness |
|
||||
{atomic} | only the default values | coarse-grain liquids, solids, metals |
|
||||
{body} | mass, inertia moments, quaternion, angular momentum | arbitrary bodies |
|
||||
{bond} | bonds | bead-spring polymers |
|
||||
{charge} | charge | atomic system with charges |
|
||||
{dipole} | charge and dipole moment | system with dipolar particles |
|
||||
{dpd} | internal temperature and internal energies | DPD particles |
|
||||
{electron} | charge and spin and eradius | electronic force field |
|
||||
{ellipsoid} | shape, quaternion, angular momentum | aspherical particles |
|
||||
{full} | molecular + charge | bio-molecules |
|
||||
{line} | end points, angular velocity | rigid bodies |
|
||||
{meso} | rho, e, cv | SPH particles |
|
||||
{molecular} | bonds, angles, dihedrals, impropers | uncharged molecules |
|
||||
{peri} | mass, volume | mesocopic Peridynamic models |
|
||||
{smd} | volume, kernel diameter, contact radius, mass | solid and fluid SPH particles |
|
||||
{sphere} | diameter, mass, angular velocity | granular models |
|
||||
{template} | template index, template atom | small molecules with fixed topology |
|
||||
{tri} | corner points, angular momentum | rigid bodies |
|
||||
{wavepacket} | charge, spin, eradius, etag, cs_re, cs_im | AWPMD :tb(c=3,s=|)
|
||||
|
||||
NOTE: It is possible to add some attributes, such as a molecule ID, to
|
||||
atom styles that do not have them via the "fix
|
||||
property/atom"_fix_property_atom.html command. This command also
|
||||
allows new custom attributes consisting of extra integer or
|
||||
floating-point values to be added to atoms. See the "fix
|
||||
property/atom"_fix_property_atom.html doc page for examples of cases
|
||||
where this is useful and details on how to initialize, access, and
|
||||
output the custom values.
|
||||
|
||||
All of the above styles define point particles, except the {sphere},
|
||||
{ellipsoid}, {electron}, {peri}, {wavepacket}, {line}, {tri}, and
|
||||
{body} styles, which define finite-size particles. See "Section_howto
|
||||
14"_Section_howto.html#howto_14 for an overview of using finite-size
|
||||
particle models with LAMMPS.
|
||||
|
||||
All of the point-particle styles assign mass to particles on a
|
||||
per-type basis, using the "mass"_mass.html command, The finite-size
|
||||
particle styles assign mass to individual particles on a per-particle
|
||||
basis.
|
||||
|
||||
For the {sphere} style, the particles are spheres and each stores a
|
||||
per-particle diameter and mass. If the diameter > 0.0, the particle
|
||||
is a finite-size sphere. If the diameter = 0.0, it is a point
|
||||
particle.
|
||||
|
||||
For the {ellipsoid} style, the particles are ellipsoids and each
|
||||
stores a flag which indicates whether it is a finite-size ellipsoid or
|
||||
a point particle. If it is an ellipsoid, it also stores a shape
|
||||
vector with the 3 diamters of the ellipsoid and a quaternion 4-vector
|
||||
with its orientation.
|
||||
|
||||
For the {dipole} style, a point dipole is defined for each point
|
||||
particle. Note that if you wish the particles to be finite-size
|
||||
spheres as in a Stockmayer potential for a dipolar fluid, so that the
|
||||
particles can rotate due to dipole-dipole interactions, then you need
|
||||
to use atom_style hybrid sphere dipole, which will assign both a
|
||||
diameter and dipole moment to each particle.
|
||||
|
||||
For the {electron} style, the particles representing electrons are 3d
|
||||
Gaussians with a specified position and bandwidth or uncertainty in
|
||||
position, which is represented by the eradius = electron size.
|
||||
|
||||
For the {peri} style, the particles are spherical and each stores a
|
||||
per-particle mass and volume.
|
||||
|
||||
The {dpd} style is for dissipative particle dynamics (DPD) particles
|
||||
which store the particle internal temperature (dpdTheta), internal
|
||||
conductive energy (uCond) and internal mechanical energy (uMech).
|
||||
|
||||
The {meso} style is for smoothed particle hydrodynamics (SPH)
|
||||
particles which store a density (rho), energy (e), and heat capacity
|
||||
(cv).
|
||||
|
||||
The {smd} style is for a general formulation of Smooth Particle
|
||||
Hydrodynamics. Both fluids and solids can be modeled. Particles
|
||||
store the mass and volume of an integration point, a kernel diameter
|
||||
used for calculating the field variables (e.g. stress and deformation)
|
||||
and a contact radius for calculating repulsive forces which prevent
|
||||
individual physical bodies from penetretating each other.
|
||||
|
||||
The {wavepacket} style is similar to {electron}, but the electrons may
|
||||
consist of several Gaussian wave packets, summed up with coefficients
|
||||
cs= (cs_re,cs_im). Each of the wave packets is treated as a separate
|
||||
particle in LAMMPS, wave packets belonging to the same electron must
|
||||
have identical {etag} values.
|
||||
|
||||
For the {line} style, the particles are idealized line segments and
|
||||
each stores a per-particle mass and length and orientation (i.e. the
|
||||
end points of the line segment).
|
||||
|
||||
For the {tri} style, the particles are planar triangles and each
|
||||
stores a per-particle mass and size and orientation (i.e. the corner
|
||||
points of the triangle).
|
||||
|
||||
The {template} style allows molecular topolgy (bonds,angles,etc) to be
|
||||
defined via a molecule template using the "molecule"_molecule.txt
|
||||
command. The template stores one or more molecules with a single copy
|
||||
of the topology info (bonds,angles,etc) of each. Individual atoms
|
||||
only store a template index and template atom to identify which
|
||||
molecule and which atom-within-the-molecule they represent. Using the
|
||||
{template} style instead of the {bond}, {angle}, {molecular} styles
|
||||
can save memory for systems comprised of a large number of small
|
||||
molecules, all of a single type (or small number of types). See the
|
||||
paper by Grime and Voth, in "(Grime)"_#Grime, for examples of how this
|
||||
can be advantageous for large-scale coarse-grained systems.
|
||||
|
||||
NOTE: When using the {template} style with a "molecule
|
||||
template"_molecule.html that contains multiple molecules, you should
|
||||
insure the atom types, bond types, angle_types, etc in all the
|
||||
molecules are consistent. E.g. if one molecule represents H2O and
|
||||
another CO2, then you probably do not want each molecule file to
|
||||
define 2 atom types and a single bond type, because they will conflict
|
||||
with each other when a mixture system of H2O and CO2 molecules is
|
||||
defined, e.g. by the "read_data"_read_data.html command. Rather the
|
||||
H2O molecule should define atom types 1 and 2, and bond type 1. And
|
||||
the CO2 molecule should define atom types 3 and 4 (or atom types 3 and
|
||||
2 if a single oxygen type is desired), and bond type 2.
|
||||
|
||||
For the {body} style, the particles are arbitrary bodies with internal
|
||||
attributes defined by the "style" of the bodies, which is specified by
|
||||
the {bstyle} argument. Body particles can represent complex entities,
|
||||
such as surface meshes of discrete points, collections of
|
||||
sub-particles, deformable objects, etc.
|
||||
|
||||
The "body"_body.html doc page descibes the body styles LAMMPS
|
||||
currently supports, and provides more details as to the kind of body
|
||||
particles they represent. For all styles, each body particle stores
|
||||
moments of inertia and a quaternion 4-vector, so that its orientation
|
||||
and position can be time integrated due to forces and torques.
|
||||
|
||||
Note that there may be additional arguments required along with the
|
||||
{bstyle} specification, in the atom_style body command. These
|
||||
arguments are described in the "body"_body.html doc page.
|
||||
|
||||
:line
|
||||
|
||||
Typically, simulations require only a single (non-hybrid) atom style.
|
||||
If some atoms in the simulation do not have all the properties defined
|
||||
by a particular style, use the simplest style that defines all the
|
||||
needed properties by any atom. For example, if some atoms in a
|
||||
simulation are charged, but others are not, use the {charge} style.
|
||||
If some atoms have bonds, but others do not, use the {bond} style.
|
||||
|
||||
The only scenario where the {hybrid} style is needed is if there is no
|
||||
single style which defines all needed properties of all atoms. For
|
||||
example, as mentioned above, if you want dipolar particles which will
|
||||
rotate due to torque, you need to use "atom_style hybrid sphere
|
||||
dipole". When a hybrid style is used, atoms store and communicate the
|
||||
union of all quantities implied by the individual styles.
|
||||
|
||||
When using the {hybrid} style, you cannot combine the {template} style
|
||||
with another molecular style that stores bond,angle,etc info on a
|
||||
per-atom basis.
|
||||
|
||||
LAMMPS can be extended with new atom styles as well as new body
|
||||
styles; see "this section"_Section_modify.html.
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda} or {kk} suffix are functionally the same as the
|
||||
corresponding style without the suffix. They have been optimized to
|
||||
run faster, depending on your available hardware, as discussed in
|
||||
"Section_accelerate"_Section_accelerate.html of the manual. The
|
||||
accelerated styles take the same arguments and should produce the same
|
||||
results, except for round-off and precision issues.
|
||||
|
||||
Note that other acceleration packages in LAMMPS, specifically the GPU,
|
||||
USER-INTEL, USER-OMP, and OPT packages do not use accelerated atom
|
||||
styles.
|
||||
|
||||
The accelerated styles are part of the USER-CUDA and KOKKOS packages
|
||||
respectively. They are only enabled if LAMMPS was built with those
|
||||
packages. See the "Making LAMMPS"_Section_start.html#start_3 section
|
||||
for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This command cannot be used after the simulation box is defined by a
|
||||
"read_data"_read_data.html or "create_box"_create_box.html command.
|
||||
|
||||
Many of the styles listed above are only enabled if LAMMPS was built
|
||||
with a specific package, as listed below. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
The {angle}, {bond}, {full}, {molecular}, and {template} styles are
|
||||
part of the MOLECULE package.
|
||||
|
||||
The {line} and {tri} styles are part of the ASPHERE package.
|
||||
|
||||
The {body} style is part of the BODY package.
|
||||
|
||||
The {dipole} style is part of the DIPOLE package.
|
||||
|
||||
The {peri} style is part of the PERI package for Peridynamics.
|
||||
|
||||
The {electron} style is part of the USER-EFF package for "electronic
|
||||
force fields"_pair_eff.html.
|
||||
|
||||
The {dpd} style is part of the USER-DPD package for dissipative
|
||||
particle dynamics (DPD).
|
||||
|
||||
The {meso} style is part of the USER-SPH package for smoothed particle
|
||||
hydrodyanmics (SPH). See "this PDF
|
||||
guide"_USER/sph/SPH_LAMMPS_userguide.pdf to using SPH in LAMMPS.
|
||||
|
||||
The {wavepacket} style is part of the USER-AWPMD package for the
|
||||
"antisymmetrized wave packet MD method"_pair_awpmd.html.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"read_data"_read_data.html, "pair_style"_pair_style.html
|
||||
|
||||
[Default:]
|
||||
|
||||
atom_style atomic
|
||||
|
||||
:line
|
||||
|
||||
:link(Grime)
|
||||
[(Grime)] Grime and Voth, to appear in J Chem Theory & Computation
|
||||
(2014).
|
||||
542
doc/balance.html
542
doc/balance.html
@ -1,542 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>balance command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>balance command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="balance-command">
|
||||
<span id="index-0"></span><h1>balance command<a class="headerlink" href="#balance-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>balance thresh style args ... keyword value ...
|
||||
</pre></div>
|
||||
</div>
|
||||
<ul class="simple">
|
||||
<li>thresh = imbalance threshhold that must be exceeded to perform a re-balance</li>
|
||||
<li>one style/arg pair can be used (or multiple for <em>x</em>,*y*,*z*)</li>
|
||||
<li>style = <em>x</em> or <em>y</em> or <em>z</em> or <em>shift</em> or <em>rcb</em></li>
|
||||
</ul>
|
||||
<pre class="literal-block">
|
||||
<em>x</em> args = <em>uniform</em> or Px-1 numbers between 0 and 1
|
||||
<em>uniform</em> = evenly spaced cuts between processors in x dimension
|
||||
numbers = Px-1 ascending values between 0 and 1, Px - # of processors in x dimension
|
||||
<em>x</em> can be specified together with <em>y</em> or <em>z</em>
|
||||
<em>y</em> args = <em>uniform</em> or Py-1 numbers between 0 and 1
|
||||
<em>uniform</em> = evenly spaced cuts between processors in y dimension
|
||||
numbers = Py-1 ascending values between 0 and 1, Py - # of processors in y dimension
|
||||
<em>y</em> can be specified together with <em>x</em> or <em>z</em>
|
||||
<em>z</em> args = <em>uniform</em> or Pz-1 numbers between 0 and 1
|
||||
<em>uniform</em> = evenly spaced cuts between processors in z dimension
|
||||
numbers = Pz-1 ascending values between 0 and 1, Pz - # of processors in z dimension
|
||||
<em>z</em> can be specified together with <em>x</em> or <em>y</em>
|
||||
<em>shift</em> args = dimstr Niter stopthresh
|
||||
dimstr = sequence of letters containing "x" or "y" or "z", each not more than once
|
||||
Niter = # of times to iterate within each dimension of dimstr sequence
|
||||
stopthresh = stop balancing when this imbalance threshhold is reached
|
||||
<em>rcb</em> args = none
|
||||
</pre>
|
||||
<ul class="simple">
|
||||
<li>zero or more keyword/value pairs may be appended</li>
|
||||
<li>keyword = <em>out</em></li>
|
||||
</ul>
|
||||
<pre class="literal-block">
|
||||
<em>out</em> value = filename
|
||||
filename = write each processor's sub-domain to a file
|
||||
</pre>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>balance 0.9 x uniform y 0.4 0.5 0.6
|
||||
balance 1.2 shift xz 5 1.1
|
||||
balance 1.0 shift xz 5 1.1
|
||||
balance 1.1 rcb
|
||||
balance 1.0 shift x 20 1.0 out tmp.balance
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This command adjusts the size and shape of processor sub-domains
|
||||
within the simulation box, to attempt to balance the number of
|
||||
particles and thus the computational cost (load) evenly across
|
||||
processors. The load balancing is “static” in the sense that this
|
||||
command performs the balancing once, before or between simulations.
|
||||
The processor sub-domains will then remain static during the
|
||||
subsequent run. To perform “dynamic” balancing, see the <a class="reference internal" href="fix_balance.html"><em>fix balance</em></a> command, which can adjust processor
|
||||
sub-domain sizes and shapes on-the-fly during a <a class="reference internal" href="run.html"><em>run</em></a>.</p>
|
||||
<p>Load-balancing is typically only useful if the particles in the
|
||||
simulation box have a spatially-varying density distribution. E.g. a
|
||||
model of a vapor/liquid interface, or a solid with an irregular-shaped
|
||||
geometry containing void regions. In this case, the LAMMPS default of
|
||||
dividing the simulation box volume into a regular-spaced grid of 3d
|
||||
bricks, with one equal-volume sub-domain per procesor, may assign very
|
||||
different numbers of particles per processor. This can lead to poor
|
||||
performance when the simulation is run in parallel.</p>
|
||||
<p>Note that the <a class="reference internal" href="processors.html"><em>processors</em></a> command allows some control
|
||||
over how the box volume is split across processors. Specifically, for
|
||||
a Px by Py by Pz grid of processors, it allows choice of Px, Py, and
|
||||
Pz, subject to the constraint that Px * Py * Pz = P, the total number
|
||||
of processors. This is sufficient to achieve good load-balance for
|
||||
some problems on some processor counts. However, all the processor
|
||||
sub-domains will still have the same shape and same volume.</p>
|
||||
<p>The requested load-balancing operation is only performed if the
|
||||
current “imbalance factor” in particles owned by each processor
|
||||
exceeds the specified <em>thresh</em> parameter. The imbalance factor is
|
||||
defined as the maximum number of particles owned by any processor,
|
||||
divided by the average number of particles per processor. Thus an
|
||||
imbalance factor of 1.0 is perfect balance.</p>
|
||||
<p>As an example, for 10000 particles running on 10 processors, if the
|
||||
most heavily loaded processor has 1200 particles, then the factor is
|
||||
1.2, meaning there is a 20% imbalance. Note that a re-balance can be
|
||||
forced even if the current balance is perfect (1.0) be specifying a
|
||||
<em>thresh</em> < 1.0.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">Balancing is performed even if the imbalance factor does not
|
||||
exceed the <em>thresh</em> parameter if a “grid” style is specified when the
|
||||
current partitioning is “tiled”. The meaning of “grid” vs “tiled” is
|
||||
explained below. This is to allow forcing of the partitioning to
|
||||
“grid” so that the <a class="reference internal" href="comm_style.html"><em>comm_style brick</em></a> command can then
|
||||
be used to replace a current <a class="reference internal" href="comm_style.html"><em>comm_style tiled</em></a>
|
||||
setting.</p>
|
||||
</div>
|
||||
<p>When the balance command completes, it prints statistics about the
|
||||
result, including the change in the imbalance factor and the change in
|
||||
the maximum number of particles on any processor. For “grid” methods
|
||||
(defined below) that create a logical 3d grid of processors, the
|
||||
positions of all cutting planes in each of the 3 dimensions (as
|
||||
fractions of the box length) are also printed.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">This command attempts to minimize the imbalance factor, as
|
||||
defined above. But depending on the method a perfect balance (1.0)
|
||||
may not be achieved. For example, “grid” methods (defined below) that
|
||||
create a logical 3d grid cannot achieve perfect balance for many
|
||||
irregular distributions of particles. Likewise, if a portion of the
|
||||
system is a perfect lattice, e.g. the intiial system is generated by
|
||||
the <a class="reference internal" href="create_atoms.html"><em>create_atoms</em></a> command, then “grid” methods may
|
||||
be unable to achieve exact balance. This is because entire lattice
|
||||
planes will be owned or not owned by a single processor.</p>
|
||||
</div>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">The imbalance factor is also an estimate of the maximum speed-up
|
||||
you can hope to achieve by running a perfectly balanced simulation
|
||||
versus an imbalanced one. In the example above, the 10000 particle
|
||||
simulation could run up to 20% faster if it were perfectly balanced,
|
||||
versus when imbalanced. However, computational cost is not strictly
|
||||
proportional to particle count, and changing the relative size and
|
||||
shape of processor sub-domains may lead to additional computational
|
||||
and communication overheads, e.g. in the PPPM solver used via the
|
||||
<a class="reference internal" href="kspace_style.html"><em>kspace_style</em></a> command. Thus you should benchmark
|
||||
the run times of a simulation before and after balancing.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<p>The method used to perform a load balance is specified by one of the
|
||||
listed styles (or more in the case of <em>x</em>,*y*,*z*), which are
|
||||
described in detail below. There are 2 kinds of styles.</p>
|
||||
<p>The <em>x</em>, <em>y</em>, <em>z</em>, and <em>shift</em> styles are “grid” methods which produce
|
||||
a logical 3d grid of processors. They operate by changing the cutting
|
||||
planes (or lines) between processors in 3d (or 2d), to adjust the
|
||||
volume (area in 2d) assigned to each processor, as in the following 2d
|
||||
diagram where processor sub-domains are shown and atoms are colored by
|
||||
the processor that owns them. The leftmost diagram is the default
|
||||
partitioning of the simulation box across processors (one sub-box for
|
||||
each of 16 processors); the middle diagram is after a “grid” method
|
||||
has been applied.</p>
|
||||
<a data-lightbox="group-default"
|
||||
href="_images/balance_uniform.jpg"
|
||||
class=""
|
||||
title=""
|
||||
data-title=""
|
||||
><img src="_images/balance_uniform.jpg"
|
||||
class="align-center"
|
||||
width="25%"
|
||||
height="auto"
|
||||
alt=""/>
|
||||
</a><a data-lightbox="group-default"
|
||||
href="_images/balance_nonuniform.jpg"
|
||||
class=""
|
||||
title=""
|
||||
data-title=""
|
||||
><img src="_images/balance_nonuniform.jpg"
|
||||
class="align-center"
|
||||
width="25%"
|
||||
height="auto"
|
||||
alt=""/>
|
||||
</a><a data-lightbox="group-default"
|
||||
href="_images/balance_rcb.jpg"
|
||||
class=""
|
||||
title=""
|
||||
data-title=""
|
||||
><img src="_images/balance_rcb.jpg"
|
||||
class="align-center"
|
||||
width="25%"
|
||||
height="auto"
|
||||
alt=""/>
|
||||
</a><p>The <em>rcb</em> style is a “tiling” method which does not produce a logical
|
||||
3d grid of processors. Rather it tiles the simulation domain with
|
||||
rectangular sub-boxes of varying size and shape in an irregular
|
||||
fashion so as to have equal numbers of particles in each sub-box, as
|
||||
in the rightmost diagram above.</p>
|
||||
<p>The “grid” methods can be used with either of the
|
||||
<a class="reference internal" href="comm_style.html"><em>comm_style</em></a> command options, <em>brick</em> or <em>tiled</em>. The
|
||||
“tiling” methods can only be used with <a class="reference internal" href="comm_style.html"><em>comm_style tiled</em></a>. Note that it can be useful to use a “grid”
|
||||
method with <a class="reference internal" href="comm_style.html"><em>comm_style tiled</em></a> to return the domain
|
||||
partitioning to a logical 3d grid of processors so that “comm_style
|
||||
brick” can afterwords be specified for subsequent <a class="reference internal" href="run.html"><em>run</em></a>
|
||||
commands.</p>
|
||||
<p>When a “grid” method is specified, the current domain partitioning can
|
||||
be either a logical 3d grid or a tiled partitioning. In the former
|
||||
case, the current logical 3d grid is used as a starting point and
|
||||
changes are made to improve the imbalance factor. In the latter case,
|
||||
the tiled partitioning is discarded and a logical 3d grid is created
|
||||
with uniform spacing in all dimensions. This becomes the starting
|
||||
point for the balancing operation.</p>
|
||||
<p>When a “tiling” method is specified, the current domain partitioning
|
||||
(“grid” or “tiled”) is ignored, and a new partitioning is computed
|
||||
from scratch.</p>
|
||||
<hr class="docutils" />
|
||||
<p>The <em>x</em>, <em>y</em>, and <em>z</em> styles invoke a “grid” method for balancing, as
|
||||
described above. Note that any or all of these 3 styles can be
|
||||
specified together, one after the other, but they cannot be used with
|
||||
any other style. This style adjusts the position of cutting planes
|
||||
between processor sub-domains in specific dimensions. Only the
|
||||
specified dimensions are altered.</p>
|
||||
<p>The <em>uniform</em> argument spaces the planes evenly, as in the left
|
||||
diagrams above. The <em>numeric</em> argument requires listing Ps-1 numbers
|
||||
that specify the position of the cutting planes. This requires
|
||||
knowing Ps = Px or Py or Pz = the number of processors assigned by
|
||||
LAMMPS to the relevant dimension. This assignment is made (and the
|
||||
Px, Py, Pz values printed out) when the simulation box is created by
|
||||
the “create_box” or “read_data” or “read_restart” command and is
|
||||
influenced by the settings of the <a class="reference internal" href="processors.html"><em>processors</em></a>
|
||||
command.</p>
|
||||
<p>Each of the numeric values must be between 0 and 1, and they must be
|
||||
listed in ascending order. They represent the fractional position of
|
||||
the cutting place. The left (or lower) edge of the box is 0.0, and
|
||||
the right (or upper) edge is 1.0. Neither of these values is
|
||||
specified. Only the interior Ps-1 positions are specified. Thus is
|
||||
there are 2 procesors in the x dimension, you specify a single value
|
||||
such as 0.75, which would make the left processor’s sub-domain 3x
|
||||
larger than the right processor’s sub-domain.</p>
|
||||
<hr class="docutils" />
|
||||
<p>The <em>shift</em> style invokes a “grid” method for balancing, as
|
||||
described above. It changes the positions of cutting planes between
|
||||
processors in an iterative fashion, seeking to reduce the imbalance
|
||||
factor, similar to how the <a class="reference internal" href="fix_balance.html"><em>fix balance shift</em></a>
|
||||
command operates.</p>
|
||||
<p>The <em>dimstr</em> argument is a string of characters, each of which must be
|
||||
an “x” or “y” or “z”. Eacn character can appear zero or one time,
|
||||
since there is no advantage to balancing on a dimension more than
|
||||
once. You should normally only list dimensions where you expect there
|
||||
to be a density variation in the particles.</p>
|
||||
<p>Balancing proceeds by adjusting the cutting planes in each of the
|
||||
dimensions listed in <em>dimstr</em>, one dimension at a time. For a single
|
||||
dimension, the balancing operation (described below) is iterated on up
|
||||
to <em>Niter</em> times. After each dimension finishes, the imbalance factor
|
||||
is re-computed, and the balancing operation halts if the <em>stopthresh</em>
|
||||
criterion is met.</p>
|
||||
<p>A rebalance operation in a single dimension is performed using a
|
||||
recursive multisectioning algorithm, where the position of each
|
||||
cutting plane (line in 2d) in the dimension is adjusted independently.
|
||||
This is similar to a recursive bisectioning for a single value, except
|
||||
that the bounds used for each bisectioning take advantage of
|
||||
information from neighboring cuts if possible. At each iteration, the
|
||||
count of particles on either side of each plane is tallied. If the
|
||||
counts do not match the target value for the plane, the position of
|
||||
the cut is adjusted to be halfway between a low and high bound. The
|
||||
low and high bounds are adjusted on each iteration, using new count
|
||||
information, so that they become closer together over time. Thus as
|
||||
the recustion progresses, the count of particles on either side of the
|
||||
plane gets closer to the target value.</p>
|
||||
<p>Once the rebalancing is complete and final processor sub-domains
|
||||
assigned, particles are migrated to their new owning processor, and
|
||||
the balance procedure ends.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">At each rebalance operation, the bisectioning for each cutting
|
||||
plane (line in 2d) typcially starts with low and high bounds separated
|
||||
by the extent of a processor’s sub-domain in one dimension. The size
|
||||
of this bracketing region shrinks by 1/2 every iteration. Thus if
|
||||
<em>Niter</em> is specified as 10, the cutting plane will typically be
|
||||
positioned to 1 part in 1000 accuracy (relative to the perfect target
|
||||
position). For <em>Niter</em> = 20, it will be accurate to 1 part in a
|
||||
million. Thus there is no need ot set <em>Niter</em> to a large value.
|
||||
LAMMPS will check if the threshold accuracy is reached (in a
|
||||
dimension) is less iterations than <em>Niter</em> and exit early. However,
|
||||
<em>Niter</em> should also not be set too small, since it will take roughly
|
||||
the same number of iterations to converge even if the cutting plane is
|
||||
initially close to the target value.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<p>The <em>rcb</em> style invokes a “tiled” method for balancing, as described
|
||||
above. It performs a recursive coordinate bisectioning (RCB) of the
|
||||
simulation domain. The basic idea is as follows.</p>
|
||||
<p>The simulation domain is cut into 2 boxes by an axis-aligned cut in
|
||||
the longest dimension, leaving one new box on either side of the cut.
|
||||
All the processors are also partitioned into 2 groups, half assigned
|
||||
to the box on the lower side of the cut, and half to the box on the
|
||||
upper side. (If the processor count is odd, one side gets an extra
|
||||
processor.) The cut is positioned so that the number of atoms in the
|
||||
lower box is exactly the number that the processors assigned to that
|
||||
box should own for load balance to be perfect. This also makes load
|
||||
balance for the upper box perfect. The positioning is done
|
||||
iteratively, by a bisectioning method. Note that counting atoms on
|
||||
either side of the cut requires communication between all processors
|
||||
at each iteration.</p>
|
||||
<p>That is the procedure for the first cut. Subsequent cuts are made
|
||||
recursively, in exactly the same manner. The subset of processors
|
||||
assigned to each box make a new cut in the longest dimension of that
|
||||
box, splitting the box, the subset of processsors, and the atoms in
|
||||
the box in two. The recursion continues until every processor is
|
||||
assigned a sub-box of the entire simulation domain, and owns the atoms
|
||||
in that sub-box.</p>
|
||||
<hr class="docutils" />
|
||||
<p>The <em>out</em> keyword writes a text file to the specified <em>filename</em> with
|
||||
the results of the balancing operation. The file contains the bounds
|
||||
of the sub-domain for each processor after the balancing operation
|
||||
completes. The format of the file is compatible with the
|
||||
<a class="reference external" href="pizza">Pizza.py</a> <em>mdump</em> tool which has support for manipulating and
|
||||
visualizing mesh files. An example is shown here for a balancing by 4
|
||||
processors for a 2d problem:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>ITEM: TIMESTEP
|
||||
0
|
||||
ITEM: NUMBER OF NODES
|
||||
16
|
||||
ITEM: BOX BOUNDS
|
||||
0 10
|
||||
0 10
|
||||
0 10
|
||||
ITEM: NODES
|
||||
1 1 0 0 0
|
||||
2 1 5 0 0
|
||||
3 1 5 5 0
|
||||
4 1 0 5 0
|
||||
5 1 5 0 0
|
||||
6 1 10 0 0
|
||||
7 1 10 5 0
|
||||
8 1 5 5 0
|
||||
9 1 0 5 0
|
||||
10 1 5 5 0
|
||||
11 1 5 10 0
|
||||
12 1 10 5 0
|
||||
13 1 5 5 0
|
||||
14 1 10 5 0
|
||||
15 1 10 10 0
|
||||
16 1 5 10 0
|
||||
ITEM: TIMESTEP
|
||||
0
|
||||
ITEM: NUMBER OF SQUARES
|
||||
4
|
||||
ITEM: SQUARES
|
||||
1 1 1 2 3 4
|
||||
2 1 5 6 7 8
|
||||
3 1 9 10 11 12
|
||||
4 1 13 14 15 16
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The coordinates of all the vertices are listed in the NODES section, 5
|
||||
per processor. Note that the 4 sub-domains share vertices, so there
|
||||
will be duplicate nodes in the list.</p>
|
||||
<p>The “SQUARES” section lists the node IDs of the 4 vertices in a
|
||||
rectangle for each processor (1 to 4).</p>
|
||||
<p>For a 3d problem, the syntax is similar with 8 vertices listed for
|
||||
each processor, instead of 4, and “SQUARES” replaced by “CUBES”.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>For 2d simulations, the <em>z</em> style cannot be used. Nor can a “z”
|
||||
appear in <em>dimstr</em> for the <em>shift</em> style.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="processors.html"><em>processors</em></a>, <a class="reference internal" href="fix_balance.html"><em>fix balance</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
346
doc/balance.txt
346
doc/balance.txt
@ -1,346 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
balance command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
balance thresh style args ... keyword value ... :pre
|
||||
|
||||
thresh = imbalance threshhold that must be exceeded to perform a re-balance :ulb,l
|
||||
one style/arg pair can be used (or multiple for {x},{y},{z}) :l
|
||||
style = {x} or {y} or {z} or {shift} or {rcb} :l
|
||||
{x} args = {uniform} or Px-1 numbers between 0 and 1
|
||||
{uniform} = evenly spaced cuts between processors in x dimension
|
||||
numbers = Px-1 ascending values between 0 and 1, Px - # of processors in x dimension
|
||||
{x} can be specified together with {y} or {z}
|
||||
{y} args = {uniform} or Py-1 numbers between 0 and 1
|
||||
{uniform} = evenly spaced cuts between processors in y dimension
|
||||
numbers = Py-1 ascending values between 0 and 1, Py - # of processors in y dimension
|
||||
{y} can be specified together with {x} or {z}
|
||||
{z} args = {uniform} or Pz-1 numbers between 0 and 1
|
||||
{uniform} = evenly spaced cuts between processors in z dimension
|
||||
numbers = Pz-1 ascending values between 0 and 1, Pz - # of processors in z dimension
|
||||
{z} can be specified together with {x} or {y}
|
||||
{shift} args = dimstr Niter stopthresh
|
||||
dimstr = sequence of letters containing "x" or "y" or "z", each not more than once
|
||||
Niter = # of times to iterate within each dimension of dimstr sequence
|
||||
stopthresh = stop balancing when this imbalance threshhold is reached
|
||||
{rcb} args = none :pre
|
||||
zero or more keyword/value pairs may be appended :l
|
||||
keyword = {out} :l
|
||||
{out} value = filename
|
||||
filename = write each processor's sub-domain to a file :pre
|
||||
:ule
|
||||
|
||||
[Examples:]
|
||||
|
||||
balance 0.9 x uniform y 0.4 0.5 0.6
|
||||
balance 1.2 shift xz 5 1.1
|
||||
balance 1.0 shift xz 5 1.1
|
||||
balance 1.1 rcb
|
||||
balance 1.0 shift x 20 1.0 out tmp.balance :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
This command adjusts the size and shape of processor sub-domains
|
||||
within the simulation box, to attempt to balance the number of
|
||||
particles and thus the computational cost (load) evenly across
|
||||
processors. The load balancing is "static" in the sense that this
|
||||
command performs the balancing once, before or between simulations.
|
||||
The processor sub-domains will then remain static during the
|
||||
subsequent run. To perform "dynamic" balancing, see the "fix
|
||||
balance"_fix_balance.html command, which can adjust processor
|
||||
sub-domain sizes and shapes on-the-fly during a "run"_run.html.
|
||||
|
||||
Load-balancing is typically only useful if the particles in the
|
||||
simulation box have a spatially-varying density distribution. E.g. a
|
||||
model of a vapor/liquid interface, or a solid with an irregular-shaped
|
||||
geometry containing void regions. In this case, the LAMMPS default of
|
||||
dividing the simulation box volume into a regular-spaced grid of 3d
|
||||
bricks, with one equal-volume sub-domain per procesor, may assign very
|
||||
different numbers of particles per processor. This can lead to poor
|
||||
performance when the simulation is run in parallel.
|
||||
|
||||
Note that the "processors"_processors.html command allows some control
|
||||
over how the box volume is split across processors. Specifically, for
|
||||
a Px by Py by Pz grid of processors, it allows choice of Px, Py, and
|
||||
Pz, subject to the constraint that Px * Py * Pz = P, the total number
|
||||
of processors. This is sufficient to achieve good load-balance for
|
||||
some problems on some processor counts. However, all the processor
|
||||
sub-domains will still have the same shape and same volume.
|
||||
|
||||
The requested load-balancing operation is only performed if the
|
||||
current "imbalance factor" in particles owned by each processor
|
||||
exceeds the specified {thresh} parameter. The imbalance factor is
|
||||
defined as the maximum number of particles owned by any processor,
|
||||
divided by the average number of particles per processor. Thus an
|
||||
imbalance factor of 1.0 is perfect balance.
|
||||
|
||||
As an example, for 10000 particles running on 10 processors, if the
|
||||
most heavily loaded processor has 1200 particles, then the factor is
|
||||
1.2, meaning there is a 20% imbalance. Note that a re-balance can be
|
||||
forced even if the current balance is perfect (1.0) be specifying a
|
||||
{thresh} < 1.0.
|
||||
|
||||
NOTE: Balancing is performed even if the imbalance factor does not
|
||||
exceed the {thresh} parameter if a "grid" style is specified when the
|
||||
current partitioning is "tiled". The meaning of "grid" vs "tiled" is
|
||||
explained below. This is to allow forcing of the partitioning to
|
||||
"grid" so that the "comm_style brick"_comm_style.html command can then
|
||||
be used to replace a current "comm_style tiled"_comm_style.html
|
||||
setting.
|
||||
|
||||
When the balance command completes, it prints statistics about the
|
||||
result, including the change in the imbalance factor and the change in
|
||||
the maximum number of particles on any processor. For "grid" methods
|
||||
(defined below) that create a logical 3d grid of processors, the
|
||||
positions of all cutting planes in each of the 3 dimensions (as
|
||||
fractions of the box length) are also printed.
|
||||
|
||||
NOTE: This command attempts to minimize the imbalance factor, as
|
||||
defined above. But depending on the method a perfect balance (1.0)
|
||||
may not be achieved. For example, "grid" methods (defined below) that
|
||||
create a logical 3d grid cannot achieve perfect balance for many
|
||||
irregular distributions of particles. Likewise, if a portion of the
|
||||
system is a perfect lattice, e.g. the intiial system is generated by
|
||||
the "create_atoms"_create_atoms.html command, then "grid" methods may
|
||||
be unable to achieve exact balance. This is because entire lattice
|
||||
planes will be owned or not owned by a single processor.
|
||||
|
||||
NOTE: The imbalance factor is also an estimate of the maximum speed-up
|
||||
you can hope to achieve by running a perfectly balanced simulation
|
||||
versus an imbalanced one. In the example above, the 10000 particle
|
||||
simulation could run up to 20% faster if it were perfectly balanced,
|
||||
versus when imbalanced. However, computational cost is not strictly
|
||||
proportional to particle count, and changing the relative size and
|
||||
shape of processor sub-domains may lead to additional computational
|
||||
and communication overheads, e.g. in the PPPM solver used via the
|
||||
"kspace_style"_kspace_style.html command. Thus you should benchmark
|
||||
the run times of a simulation before and after balancing.
|
||||
|
||||
:line
|
||||
|
||||
The method used to perform a load balance is specified by one of the
|
||||
listed styles (or more in the case of {x},{y},{z}), which are
|
||||
described in detail below. There are 2 kinds of styles.
|
||||
|
||||
The {x}, {y}, {z}, and {shift} styles are "grid" methods which produce
|
||||
a logical 3d grid of processors. They operate by changing the cutting
|
||||
planes (or lines) between processors in 3d (or 2d), to adjust the
|
||||
volume (area in 2d) assigned to each processor, as in the following 2d
|
||||
diagram where processor sub-domains are shown and atoms are colored by
|
||||
the processor that owns them. The leftmost diagram is the default
|
||||
partitioning of the simulation box across processors (one sub-box for
|
||||
each of 16 processors); the middle diagram is after a "grid" method
|
||||
has been applied.
|
||||
|
||||
:c,image(JPG/balance_uniform_small.jpg,JPG/balance_uniform.jpg),image(JPG/balance_nonuniform_small.jpg,JPG/balance_nonuniform.jpg),image(JPG/balance_rcb_small.jpg,JPG/balance_rcb.jpg)
|
||||
|
||||
The {rcb} style is a "tiling" method which does not produce a logical
|
||||
3d grid of processors. Rather it tiles the simulation domain with
|
||||
rectangular sub-boxes of varying size and shape in an irregular
|
||||
fashion so as to have equal numbers of particles in each sub-box, as
|
||||
in the rightmost diagram above.
|
||||
|
||||
The "grid" methods can be used with either of the
|
||||
"comm_style"_comm_style.html command options, {brick} or {tiled}. The
|
||||
"tiling" methods can only be used with "comm_style
|
||||
tiled"_comm_style.html. Note that it can be useful to use a "grid"
|
||||
method with "comm_style tiled"_comm_style.html to return the domain
|
||||
partitioning to a logical 3d grid of processors so that "comm_style
|
||||
brick" can afterwords be specified for subsequent "run"_run.html
|
||||
commands.
|
||||
|
||||
When a "grid" method is specified, the current domain partitioning can
|
||||
be either a logical 3d grid or a tiled partitioning. In the former
|
||||
case, the current logical 3d grid is used as a starting point and
|
||||
changes are made to improve the imbalance factor. In the latter case,
|
||||
the tiled partitioning is discarded and a logical 3d grid is created
|
||||
with uniform spacing in all dimensions. This becomes the starting
|
||||
point for the balancing operation.
|
||||
|
||||
When a "tiling" method is specified, the current domain partitioning
|
||||
("grid" or "tiled") is ignored, and a new partitioning is computed
|
||||
from scratch.
|
||||
|
||||
:line
|
||||
|
||||
The {x}, {y}, and {z} styles invoke a "grid" method for balancing, as
|
||||
described above. Note that any or all of these 3 styles can be
|
||||
specified together, one after the other, but they cannot be used with
|
||||
any other style. This style adjusts the position of cutting planes
|
||||
between processor sub-domains in specific dimensions. Only the
|
||||
specified dimensions are altered.
|
||||
|
||||
The {uniform} argument spaces the planes evenly, as in the left
|
||||
diagrams above. The {numeric} argument requires listing Ps-1 numbers
|
||||
that specify the position of the cutting planes. This requires
|
||||
knowing Ps = Px or Py or Pz = the number of processors assigned by
|
||||
LAMMPS to the relevant dimension. This assignment is made (and the
|
||||
Px, Py, Pz values printed out) when the simulation box is created by
|
||||
the "create_box" or "read_data" or "read_restart" command and is
|
||||
influenced by the settings of the "processors"_processors.html
|
||||
command.
|
||||
|
||||
Each of the numeric values must be between 0 and 1, and they must be
|
||||
listed in ascending order. They represent the fractional position of
|
||||
the cutting place. The left (or lower) edge of the box is 0.0, and
|
||||
the right (or upper) edge is 1.0. Neither of these values is
|
||||
specified. Only the interior Ps-1 positions are specified. Thus is
|
||||
there are 2 procesors in the x dimension, you specify a single value
|
||||
such as 0.75, which would make the left processor's sub-domain 3x
|
||||
larger than the right processor's sub-domain.
|
||||
|
||||
:line
|
||||
|
||||
The {shift} style invokes a "grid" method for balancing, as
|
||||
described above. It changes the positions of cutting planes between
|
||||
processors in an iterative fashion, seeking to reduce the imbalance
|
||||
factor, similar to how the "fix balance shift"_fix_balance.html
|
||||
command operates.
|
||||
|
||||
The {dimstr} argument is a string of characters, each of which must be
|
||||
an "x" or "y" or "z". Eacn character can appear zero or one time,
|
||||
since there is no advantage to balancing on a dimension more than
|
||||
once. You should normally only list dimensions where you expect there
|
||||
to be a density variation in the particles.
|
||||
|
||||
Balancing proceeds by adjusting the cutting planes in each of the
|
||||
dimensions listed in {dimstr}, one dimension at a time. For a single
|
||||
dimension, the balancing operation (described below) is iterated on up
|
||||
to {Niter} times. After each dimension finishes, the imbalance factor
|
||||
is re-computed, and the balancing operation halts if the {stopthresh}
|
||||
criterion is met.
|
||||
|
||||
A rebalance operation in a single dimension is performed using a
|
||||
recursive multisectioning algorithm, where the position of each
|
||||
cutting plane (line in 2d) in the dimension is adjusted independently.
|
||||
This is similar to a recursive bisectioning for a single value, except
|
||||
that the bounds used for each bisectioning take advantage of
|
||||
information from neighboring cuts if possible. At each iteration, the
|
||||
count of particles on either side of each plane is tallied. If the
|
||||
counts do not match the target value for the plane, the position of
|
||||
the cut is adjusted to be halfway between a low and high bound. The
|
||||
low and high bounds are adjusted on each iteration, using new count
|
||||
information, so that they become closer together over time. Thus as
|
||||
the recustion progresses, the count of particles on either side of the
|
||||
plane gets closer to the target value.
|
||||
|
||||
Once the rebalancing is complete and final processor sub-domains
|
||||
assigned, particles are migrated to their new owning processor, and
|
||||
the balance procedure ends.
|
||||
|
||||
NOTE: At each rebalance operation, the bisectioning for each cutting
|
||||
plane (line in 2d) typcially starts with low and high bounds separated
|
||||
by the extent of a processor's sub-domain in one dimension. The size
|
||||
of this bracketing region shrinks by 1/2 every iteration. Thus if
|
||||
{Niter} is specified as 10, the cutting plane will typically be
|
||||
positioned to 1 part in 1000 accuracy (relative to the perfect target
|
||||
position). For {Niter} = 20, it will be accurate to 1 part in a
|
||||
million. Thus there is no need ot set {Niter} to a large value.
|
||||
LAMMPS will check if the threshold accuracy is reached (in a
|
||||
dimension) is less iterations than {Niter} and exit early. However,
|
||||
{Niter} should also not be set too small, since it will take roughly
|
||||
the same number of iterations to converge even if the cutting plane is
|
||||
initially close to the target value.
|
||||
|
||||
:line
|
||||
|
||||
The {rcb} style invokes a "tiled" method for balancing, as described
|
||||
above. It performs a recursive coordinate bisectioning (RCB) of the
|
||||
simulation domain. The basic idea is as follows.
|
||||
|
||||
The simulation domain is cut into 2 boxes by an axis-aligned cut in
|
||||
the longest dimension, leaving one new box on either side of the cut.
|
||||
All the processors are also partitioned into 2 groups, half assigned
|
||||
to the box on the lower side of the cut, and half to the box on the
|
||||
upper side. (If the processor count is odd, one side gets an extra
|
||||
processor.) The cut is positioned so that the number of atoms in the
|
||||
lower box is exactly the number that the processors assigned to that
|
||||
box should own for load balance to be perfect. This also makes load
|
||||
balance for the upper box perfect. The positioning is done
|
||||
iteratively, by a bisectioning method. Note that counting atoms on
|
||||
either side of the cut requires communication between all processors
|
||||
at each iteration.
|
||||
|
||||
That is the procedure for the first cut. Subsequent cuts are made
|
||||
recursively, in exactly the same manner. The subset of processors
|
||||
assigned to each box make a new cut in the longest dimension of that
|
||||
box, splitting the box, the subset of processsors, and the atoms in
|
||||
the box in two. The recursion continues until every processor is
|
||||
assigned a sub-box of the entire simulation domain, and owns the atoms
|
||||
in that sub-box.
|
||||
|
||||
:line
|
||||
|
||||
The {out} keyword writes a text file to the specified {filename} with
|
||||
the results of the balancing operation. The file contains the bounds
|
||||
of the sub-domain for each processor after the balancing operation
|
||||
completes. The format of the file is compatible with the
|
||||
"Pizza.py"_pizza {mdump} tool which has support for manipulating and
|
||||
visualizing mesh files. An example is shown here for a balancing by 4
|
||||
processors for a 2d problem:
|
||||
|
||||
ITEM: TIMESTEP
|
||||
0
|
||||
ITEM: NUMBER OF NODES
|
||||
16
|
||||
ITEM: BOX BOUNDS
|
||||
0 10
|
||||
0 10
|
||||
0 10
|
||||
ITEM: NODES
|
||||
1 1 0 0 0
|
||||
2 1 5 0 0
|
||||
3 1 5 5 0
|
||||
4 1 0 5 0
|
||||
5 1 5 0 0
|
||||
6 1 10 0 0
|
||||
7 1 10 5 0
|
||||
8 1 5 5 0
|
||||
9 1 0 5 0
|
||||
10 1 5 5 0
|
||||
11 1 5 10 0
|
||||
12 1 10 5 0
|
||||
13 1 5 5 0
|
||||
14 1 10 5 0
|
||||
15 1 10 10 0
|
||||
16 1 5 10 0
|
||||
ITEM: TIMESTEP
|
||||
0
|
||||
ITEM: NUMBER OF SQUARES
|
||||
4
|
||||
ITEM: SQUARES
|
||||
1 1 1 2 3 4
|
||||
2 1 5 6 7 8
|
||||
3 1 9 10 11 12
|
||||
4 1 13 14 15 16 :pre
|
||||
|
||||
The coordinates of all the vertices are listed in the NODES section, 5
|
||||
per processor. Note that the 4 sub-domains share vertices, so there
|
||||
will be duplicate nodes in the list.
|
||||
|
||||
The "SQUARES" section lists the node IDs of the 4 vertices in a
|
||||
rectangle for each processor (1 to 4).
|
||||
|
||||
For a 3d problem, the syntax is similar with 8 vertices listed for
|
||||
each processor, instead of 4, and "SQUARES" replaced by "CUBES".
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
For 2d simulations, the {z} style cannot be used. Nor can a "z"
|
||||
appear in {dimstr} for the {shift} style.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"processors"_processors.html, "fix balance"_fix_balance.html
|
||||
|
||||
[Default:] none
|
||||
452
doc/body.html
452
doc/body.html
@ -1,452 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>Body particles — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>Body particles</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="body-particles">
|
||||
<h1>Body particles<a class="headerlink" href="#body-particles" title="Permalink to this headline">¶</a></h1>
|
||||
<p><strong>Overview:</strong></p>
|
||||
<p>This doc page is not about a LAMMPS input script command, but about
|
||||
body particles, which are generalized finite-size particles.
|
||||
Individual body particles can represent complex entities, such as
|
||||
surface meshes of discrete points, collections of sub-particles,
|
||||
deformable objects, etc. Note that other kinds of finite-size
|
||||
spherical and aspherical particles are also supported by LAMMPS, such
|
||||
as spheres, ellipsoids, line segments, and triangles, but they are
|
||||
simpler entities that body particles. See <a class="reference internal" href="Section_howto.html#howto-14"><span>Section_howto 14</span></a> for a general overview of all these
|
||||
particle types.</p>
|
||||
<p>Body particles are used via the <a class="reference internal" href="atom_style.html"><em>atom_style body</em></a>
|
||||
command. It takes a body style as an argument. The current body
|
||||
styles supported by LAMMPS are as follows. The name in the first
|
||||
column is used as the <em>bstyle</em> argument for the <a class="reference internal" href="atom_style.html"><em>atom_style body</em></a> command.</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="35%" />
|
||||
<col width="65%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr class="row-odd"><td><em>nparticle</em></td>
|
||||
<td>rigid body with N sub-particles</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><em>rounded/polygon</em></td>
|
||||
<td>2d convex polygon with N vertices</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The body style determines what attributes are stored for each body and
|
||||
thus how they can be used to compute pairwise body/body or
|
||||
bond/non-body (point particle) interactions. More details of each
|
||||
style are described below.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">The rounded/polygon style listed in the table above and
|
||||
described below has not yet been relesed in LAMMPS. It will be soon.</p>
|
||||
</div>
|
||||
<p>We hope to add more styles in the future. See <a class="reference internal" href="Section_modify.html#mod-12"><span>Section_modify 12</span></a> for details on how to add a new body
|
||||
style to the code.</p>
|
||||
<hr class="docutils" />
|
||||
<p><strong>When to use body particles:</strong></p>
|
||||
<p>You should not use body particles to model a rigid body made of
|
||||
simpler particles (e.g. point, sphere, ellipsoid, line segment,
|
||||
triangular particles), if the interaction between pairs of rigid
|
||||
bodies is just the summation of pairwise interactions between the
|
||||
simpler particles. LAMMPS already supports this kind of model via the
|
||||
<a class="reference internal" href="fix_rigid.html"><em>fix rigid</em></a> command. Any of the numerous pair styles
|
||||
that compute interactions between simpler particles can be used. The
|
||||
<a class="reference internal" href="fix_rigid.html"><em>fix rigid</em></a> command time integrates the motion of the
|
||||
rigid bodies. All of the standard LAMMPS commands for thermostatting,
|
||||
adding constraints, performing output, etc will operate as expected on
|
||||
the simple particles.</p>
|
||||
<p>By contrast, when body particles are used, LAMMPS treats an entire
|
||||
body as a single particle for purposes of computing pairwise
|
||||
interactions, building neighbor lists, migrating particles between
|
||||
processors, outputting particles to a dump file, etc. This means that
|
||||
interactions between pairs of bodies or between a body and non-body
|
||||
(point) particle need to be encoded in an appropriate pair style. If
|
||||
such a pair style were to mimic the <a class="reference internal" href="fix_rigid.html"><em>fix rigid</em></a> model,
|
||||
it would need to loop over the entire collection of interactions
|
||||
between pairs of simple particles within the two bodies, each time a
|
||||
single body/body interaction was computed.</p>
|
||||
<p>Thus it only makes sense to use body particles and develop such a pair
|
||||
style, when particle/particle interactions are more complex than what
|
||||
the <a class="reference internal" href="fix_rigid.html"><em>fix rigid</em></a> command can already calculate. For
|
||||
example, if particles have one or more of the following attributes:</p>
|
||||
<ul class="simple">
|
||||
<li>represented by a surface mesh</li>
|
||||
<li>represented by a collection of geometric entities (e.g. planes + spheres)</li>
|
||||
<li>deformable</li>
|
||||
<li>internal stress that induces fragmentation</li>
|
||||
</ul>
|
||||
<p>then the interaction between pairs of particles is likely to be more
|
||||
complex than the summation of simple sub-particle interactions. An
|
||||
example is contact or frictional forces between particles with planar
|
||||
sufaces that inter-penetrate.</p>
|
||||
<p>These are additional LAMMPS commands that can be used with body
|
||||
particles of different styles</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="48%" />
|
||||
<col width="52%" />
|
||||
</colgroup>
|
||||
<tbody valign="top">
|
||||
<tr class="row-odd"><td><a class="reference internal" href="fix_nve_body.html"><em>fix nve/body</em></a></td>
|
||||
<td>integrate motion of a body particle in NVE ensemble</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><a class="reference internal" href="fix_nvt_body.html"><em>fix nvt/body</em></a></td>
|
||||
<td>ditto for NVT ensemble</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><a class="reference internal" href="fix_npt_body.html"><em>fix npt/body</em></a></td>
|
||||
<td>ditto for NPT ensemble</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><a class="reference internal" href="fix_nph_body.html"><em>fix nph/body</em></a></td>
|
||||
<td>ditto for NPH ensemble</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><a class="reference internal" href="compute_body_local.html"><em>compute body/local</em></a></td>
|
||||
<td>store sub-particle attributes of a body particle</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><a class="reference internal" href="compute_temp_body.html"><em>compute temp/body</em></a></td>
|
||||
<td>compute temperature of body particles</td>
|
||||
</tr>
|
||||
<tr class="row-odd"><td><a class="reference internal" href="dump.html"><em>dump local</em></a></td>
|
||||
<td>output sub-particle attributes of a body particle</td>
|
||||
</tr>
|
||||
<tr class="row-even"><td><a class="reference internal" href="dump_image.html"><em>dump image</em></a></td>
|
||||
<td>output body particle attributes as an image</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The pair styles defined for use with specific body styles are listed
|
||||
in the sections below.</p>
|
||||
<hr class="docutils" />
|
||||
<p><strong>Specifics of body style nparticle:</strong></p>
|
||||
<p>The <em>nparticle</em> body style represents body particles as a rigid body
|
||||
with a variable number N of sub-particles. It is provided as a
|
||||
vanillia, prototypical example of a body particle, although as
|
||||
mentioned above, the <a class="reference internal" href="fix_rigid.html"><em>fix rigid</em></a> command already
|
||||
duplicates its functionality.</p>
|
||||
<p>The atom_style body command for this body style takes two additional
|
||||
arguments:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>atom_style body nparticle Nmin Nmax
|
||||
Nmin = minimum # of sub-particles in any body in the system
|
||||
Nmax = maximum # of sub-particles in any body in the system
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.</p>
|
||||
<p>When the <a class="reference internal" href="read_data.html"><em>read_data</em></a> command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the <em>Bodies</em> section of the data file:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>atom-ID 1 M
|
||||
N
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>N is the number of sub-particles in the body particle. M = 6 + 3*N.
|
||||
The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
sub-particles (x1 to zN) as 3N values. These values can be listed on
|
||||
as many lines as you wish; see the <a class="reference internal" href="read_data.html"><em>read_data</em></a> command
|
||||
for more details.</p>
|
||||
<p>The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the prinicpal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each sub-particle are specified as its x,y,z
|
||||
displacement from the center-of-mass of the body particle. The
|
||||
center-of-mass position of the particle is specified by the x,y,z
|
||||
values in the <em>Atoms</em> section of the data file, as is the total mass
|
||||
of the body particle.</p>
|
||||
<p>The <a class="reference internal" href="pair_body.html"><em>pair_style body</em></a> command can be used with this
|
||||
body style to compute body/body and body/non-body interactions.</p>
|
||||
<p>For output purposes via the <a class="reference internal" href="compute_body_local.html"><em>compute body/local</em></a> and <a class="reference internal" href="dump.html"><em>dump local</em></a>
|
||||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>1 = x position of sub-particle
|
||||
2 = y position of sub-particle
|
||||
3 = z position of sub-particle
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>These values are the current position of the sub-particle within the
|
||||
simulation domain, not a displacement from the center-of-mass (COM) of
|
||||
the body particle itself. These values are calculated using the
|
||||
current COM and orientation of the body particle.</p>
|
||||
<p>For images created by the <a class="reference internal" href="dump_image.html"><em>dump image</em></a> command, if the
|
||||
<em>body</em> keyword is set, then each body particle is drawn as a
|
||||
collection of spheres, one for each sub-particle. The size of each
|
||||
sphere is determined by the <em>bflag1</em> parameter for the <em>body</em> keyword.
|
||||
The <em>bflag2</em> argument is ignored.</p>
|
||||
<hr class="docutils" />
|
||||
<p><strong>Specifics of body style rounded/polygon:</strong></p>
|
||||
<p>The <em>rounded/polygon</em> body style represents body particles as a convex
|
||||
polygon with a variable number N > 2 of vertices, which can only be
|
||||
used for 2d models. One example use of this body style is for 2d
|
||||
discrete element models, as described in <a class="reference internal" href="#fraige"><span>Fraige</span></a>. Similar to
|
||||
body style <em>nparticle</em>, the atom_style body command for this body
|
||||
style takes two additional arguments:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>atom_style body rounded/polygon Nmin Nmax
|
||||
Nmin = minimum # of vertices in any body in the system
|
||||
Nmax = maximum # of vertices in any body in the system
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.</p>
|
||||
<p>When the <a class="reference internal" href="read_data.html"><em>read_data</em></a> command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the <em>Bodies</em> section of the data file:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>atom-ID 1 M
|
||||
N
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
i j j k k ...
|
||||
radius
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>N is the number of vertices in the body particle. M = 6 + 3*N + 2*N +
|
||||
1. The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
vertices (x1 to zN) as 3N values, followed by 2N vertex indices
|
||||
corresponding to the end points of the N edges, followed by a single
|
||||
radius value = the smallest circle encompassing the polygon. That
|
||||
last value is used to facilitate the body/body contact detection.
|
||||
These floating-point values can be listed on as many lines as you
|
||||
wish; see the <a class="reference internal" href="read_data.html"><em>read_data</em></a> command for more details.</p>
|
||||
<p>The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the prinicpal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each vertex are specified as its x,y,z displacement
|
||||
from the center-of-mass of the body particle. The center-of-mass
|
||||
position of the particle is specified by the x,y,z values in the
|
||||
<em>Atoms</em> section of the data file.</p>
|
||||
<p>For example, the following information would specify a square
|
||||
particles whose edge length is sqrt(2):</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>3 1 27
|
||||
4
|
||||
1 1 4 0 0 0
|
||||
-0.7071 -0.7071 0
|
||||
-0.7071 0.7071 0
|
||||
0.7071 0.7071 0
|
||||
0.7071 -0.7071 0
|
||||
0 1 1 2 2 3 3 0
|
||||
1.0
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>The <code class="xref doc docutils literal"><span class="pre">pair_style</span> <span class="pre">body/rounded/polygon</span></code> command
|
||||
can be used with this body style to compute body/body interactions.</p>
|
||||
<p>For output purposes via the <a class="reference internal" href="compute_body_local.html"><em>compute body/local</em></a> and <a class="reference internal" href="dump.html"><em>dump local</em></a>
|
||||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>1 = x position of vertex
|
||||
2 = y position of vertex
|
||||
3 = z position of vertex
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>These values are the current position of the vertex within the
|
||||
simulation domain, not a displacement from the center-of-mass (COM) of
|
||||
the body particle itself. These values are calculated using the
|
||||
current COM and orientation of the body particle.</p>
|
||||
<p>For images created by the <a class="reference internal" href="dump_image.html"><em>dump image</em></a> command, if the
|
||||
<em>body</em> keyword is set, then each body particle is drawn as a convex
|
||||
polygon consisting of N line segments. Note that the line segments
|
||||
are drawn between the N vertices, which does not correspond exactly to
|
||||
the physical extent of the body (because the <a class="reference external" href="pair_body_rounded_polygon.cpp">pair_style rounded/polygon</a> defines finite-size
|
||||
spheres at those point and the line segments between the spheres are
|
||||
tangent to the spheres). The drawn diameter of each line segment is
|
||||
determined by the <em>bflag1</em> parameter for the <em>body</em> keyword. The
|
||||
<em>bflag2</em> argument is ignored.</p>
|
||||
<hr class="docutils" />
|
||||
<p id="fraige"><strong>(Fraige)</strong> F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
|
||||
Particuology, 6, 455 (2008).</p>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
270
doc/body.txt
270
doc/body.txt
@ -1,270 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
Body particles :h3
|
||||
|
||||
[Overview:]
|
||||
|
||||
This doc page is not about a LAMMPS input script command, but about
|
||||
body particles, which are generalized finite-size particles.
|
||||
Individual body particles can represent complex entities, such as
|
||||
surface meshes of discrete points, collections of sub-particles,
|
||||
deformable objects, etc. Note that other kinds of finite-size
|
||||
spherical and aspherical particles are also supported by LAMMPS, such
|
||||
as spheres, ellipsoids, line segments, and triangles, but they are
|
||||
simpler entities that body particles. See "Section_howto
|
||||
14"_Section_howto.html#howto_14 for a general overview of all these
|
||||
particle types.
|
||||
|
||||
Body particles are used via the "atom_style body"_atom_style.html
|
||||
command. It takes a body style as an argument. The current body
|
||||
styles supported by LAMMPS are as follows. The name in the first
|
||||
column is used as the {bstyle} argument for the "atom_style
|
||||
body"_atom_style.html command.
|
||||
|
||||
{nparticle} | rigid body with N sub-particles |
|
||||
{rounded/polygon} | 2d convex polygon with N vertices :tb(c=2,s=|)
|
||||
|
||||
The body style determines what attributes are stored for each body and
|
||||
thus how they can be used to compute pairwise body/body or
|
||||
bond/non-body (point particle) interactions. More details of each
|
||||
style are described below.
|
||||
|
||||
NOTE: The rounded/polygon style listed in the table above and
|
||||
described below has not yet been relesed in LAMMPS. It will be soon.
|
||||
|
||||
We hope to add more styles in the future. See "Section_modify
|
||||
12"_Section_modify.html#mod_12 for details on how to add a new body
|
||||
style to the code.
|
||||
|
||||
:line
|
||||
|
||||
[When to use body particles:]
|
||||
|
||||
You should not use body particles to model a rigid body made of
|
||||
simpler particles (e.g. point, sphere, ellipsoid, line segment,
|
||||
triangular particles), if the interaction between pairs of rigid
|
||||
bodies is just the summation of pairwise interactions between the
|
||||
simpler particles. LAMMPS already supports this kind of model via the
|
||||
"fix rigid"_fix_rigid.html command. Any of the numerous pair styles
|
||||
that compute interactions between simpler particles can be used. The
|
||||
"fix rigid"_fix_rigid.html command time integrates the motion of the
|
||||
rigid bodies. All of the standard LAMMPS commands for thermostatting,
|
||||
adding constraints, performing output, etc will operate as expected on
|
||||
the simple particles.
|
||||
|
||||
By contrast, when body particles are used, LAMMPS treats an entire
|
||||
body as a single particle for purposes of computing pairwise
|
||||
interactions, building neighbor lists, migrating particles between
|
||||
processors, outputting particles to a dump file, etc. This means that
|
||||
interactions between pairs of bodies or between a body and non-body
|
||||
(point) particle need to be encoded in an appropriate pair style. If
|
||||
such a pair style were to mimic the "fix rigid"_fix_rigid.html model,
|
||||
it would need to loop over the entire collection of interactions
|
||||
between pairs of simple particles within the two bodies, each time a
|
||||
single body/body interaction was computed.
|
||||
|
||||
Thus it only makes sense to use body particles and develop such a pair
|
||||
style, when particle/particle interactions are more complex than what
|
||||
the "fix rigid"_fix_rigid.html command can already calculate. For
|
||||
example, if particles have one or more of the following attributes:
|
||||
|
||||
represented by a surface mesh
|
||||
represented by a collection of geometric entities (e.g. planes + spheres)
|
||||
deformable
|
||||
internal stress that induces fragmentation :ul
|
||||
|
||||
then the interaction between pairs of particles is likely to be more
|
||||
complex than the summation of simple sub-particle interactions. An
|
||||
example is contact or frictional forces between particles with planar
|
||||
sufaces that inter-penetrate.
|
||||
|
||||
These are additional LAMMPS commands that can be used with body
|
||||
particles of different styles
|
||||
|
||||
"fix nve/body"_fix_nve_body.html : integrate motion of a body particle in NVE ensemble
|
||||
"fix nvt/body"_fix_nvt_body.html : ditto for NVT ensemble
|
||||
"fix npt/body"_fix_npt_body.html : ditto for NPT ensemble
|
||||
"fix nph/body"_fix_nph_body.html : ditto for NPH ensemble
|
||||
"compute body/local"_compute_body_local.html : store sub-particle attributes of a body particle
|
||||
"compute temp/body"_compute_temp_body.html : compute temperature of body particles
|
||||
"dump local"_dump.html : output sub-particle attributes of a body particle
|
||||
"dump image"_dump_image.html : output body particle attributes as an image :tb(s=:)
|
||||
|
||||
The pair styles defined for use with specific body styles are listed
|
||||
in the sections below.
|
||||
|
||||
:line
|
||||
|
||||
[Specifics of body style nparticle:]
|
||||
|
||||
The {nparticle} body style represents body particles as a rigid body
|
||||
with a variable number N of sub-particles. It is provided as a
|
||||
vanillia, prototypical example of a body particle, although as
|
||||
mentioned above, the "fix rigid"_fix_rigid.html command already
|
||||
duplicates its functionality.
|
||||
|
||||
The atom_style body command for this body style takes two additional
|
||||
arguments:
|
||||
|
||||
atom_style body nparticle Nmin Nmax
|
||||
Nmin = minimum # of sub-particles in any body in the system
|
||||
Nmax = maximum # of sub-particles in any body in the system :pre
|
||||
|
||||
The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.
|
||||
|
||||
When the "read_data"_read_data.html command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the {Bodies} section of the data file:
|
||||
|
||||
atom-ID 1 M
|
||||
N
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN :pre
|
||||
|
||||
N is the number of sub-particles in the body particle. M = 6 + 3*N.
|
||||
The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
sub-particles (x1 to zN) as 3N values. These values can be listed on
|
||||
as many lines as you wish; see the "read_data"_read_data.html command
|
||||
for more details.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the prinicpal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each sub-particle are specified as its x,y,z
|
||||
displacement from the center-of-mass of the body particle. The
|
||||
center-of-mass position of the particle is specified by the x,y,z
|
||||
values in the {Atoms} section of the data file, as is the total mass
|
||||
of the body particle.
|
||||
|
||||
The "pair_style body"_pair_body.html command can be used with this
|
||||
body style to compute body/body and body/non-body interactions.
|
||||
|
||||
For output purposes via the "compute
|
||||
body/local"_compute_body_local.html and "dump local"_dump.html
|
||||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:
|
||||
|
||||
1 = x position of sub-particle
|
||||
2 = y position of sub-particle
|
||||
3 = z position of sub-particle :pre
|
||||
|
||||
These values are the current position of the sub-particle within the
|
||||
simulation domain, not a displacement from the center-of-mass (COM) of
|
||||
the body particle itself. These values are calculated using the
|
||||
current COM and orientation of the body particle.
|
||||
|
||||
For images created by the "dump image"_dump_image.html command, if the
|
||||
{body} keyword is set, then each body particle is drawn as a
|
||||
collection of spheres, one for each sub-particle. The size of each
|
||||
sphere is determined by the {bflag1} parameter for the {body} keyword.
|
||||
The {bflag2} argument is ignored.
|
||||
|
||||
:line
|
||||
|
||||
[Specifics of body style rounded/polygon:]
|
||||
|
||||
The {rounded/polygon} body style represents body particles as a convex
|
||||
polygon with a variable number N > 2 of vertices, which can only be
|
||||
used for 2d models. One example use of this body style is for 2d
|
||||
discrete element models, as described in "Fraige"_#Fraige. Similar to
|
||||
body style {nparticle}, the atom_style body command for this body
|
||||
style takes two additional arguments:
|
||||
|
||||
atom_style body rounded/polygon Nmin Nmax
|
||||
Nmin = minimum # of vertices in any body in the system
|
||||
Nmax = maximum # of vertices in any body in the system :pre
|
||||
|
||||
The Nmin and Nmax arguments are used to bound the size of data
|
||||
structures used internally by each particle.
|
||||
|
||||
When the "read_data"_read_data.html command reads a data file for this
|
||||
body style, the following information must be provided for each entry
|
||||
in the {Bodies} section of the data file:
|
||||
|
||||
atom-ID 1 M
|
||||
N
|
||||
ixx iyy izz ixy ixz iyz
|
||||
x1 y1 z1
|
||||
...
|
||||
xN yN zN
|
||||
i j j k k ...
|
||||
radius :pre
|
||||
|
||||
N is the number of vertices in the body particle. M = 6 + 3*N + 2*N +
|
||||
1. The integer line has a single value N. The floating point line(s)
|
||||
list 6 moments of inertia followed by the coordinates of the N
|
||||
vertices (x1 to zN) as 3N values, followed by 2N vertex indices
|
||||
corresponding to the end points of the N edges, followed by a single
|
||||
radius value = the smallest circle encompassing the polygon. That
|
||||
last value is used to facilitate the body/body contact detection.
|
||||
These floating-point values can be listed on as many lines as you
|
||||
wish; see the "read_data"_read_data.html command for more details.
|
||||
|
||||
The 6 moments of inertia (ixx,iyy,izz,ixy,ixz,iyz) should be the
|
||||
values consistent with the current orientation of the rigid body
|
||||
around its center of mass. The values are with respect to the
|
||||
simulation box XYZ axes, not with respect to the prinicpal axes of the
|
||||
rigid body itself. LAMMPS performs the latter calculation internally.
|
||||
The coordinates of each vertex are specified as its x,y,z displacement
|
||||
from the center-of-mass of the body particle. The center-of-mass
|
||||
position of the particle is specified by the x,y,z values in the
|
||||
{Atoms} section of the data file.
|
||||
|
||||
For example, the following information would specify a square
|
||||
particles whose edge length is sqrt(2):
|
||||
|
||||
3 1 27
|
||||
4
|
||||
1 1 4 0 0 0
|
||||
-0.7071 -0.7071 0
|
||||
-0.7071 0.7071 0
|
||||
0.7071 0.7071 0
|
||||
0.7071 -0.7071 0
|
||||
0 1 1 2 2 3 3 0
|
||||
1.0 :pre
|
||||
|
||||
The "pair_style body/rounded/polygon"_pair_body_rounded_polygon.html command
|
||||
can be used with this body style to compute body/body interactions.
|
||||
|
||||
For output purposes via the "compute
|
||||
body/local"_compute_body_local.html and "dump local"_dump.html
|
||||
commands, this body style produces one datum for each of the N
|
||||
sub-particles in a body particle. The datum has 3 values:
|
||||
|
||||
1 = x position of vertex
|
||||
2 = y position of vertex
|
||||
3 = z position of vertex :pre
|
||||
|
||||
These values are the current position of the vertex within the
|
||||
simulation domain, not a displacement from the center-of-mass (COM) of
|
||||
the body particle itself. These values are calculated using the
|
||||
current COM and orientation of the body particle.
|
||||
|
||||
For images created by the "dump image"_dump_image.html command, if the
|
||||
{body} keyword is set, then each body particle is drawn as a convex
|
||||
polygon consisting of N line segments. Note that the line segments
|
||||
are drawn between the N vertices, which does not correspond exactly to
|
||||
the physical extent of the body (because the "pair_style
|
||||
rounded/polygon"_pair_body_rounded_polygon.cpp defines finite-size
|
||||
spheres at those point and the line segments between the spheres are
|
||||
tangent to the spheres). The drawn diameter of each line segment is
|
||||
determined by the {bflag1} parameter for the {body} keyword. The
|
||||
{bflag2} argument is ignored.
|
||||
|
||||
:line
|
||||
|
||||
:link(Fraige)
|
||||
[(Fraige)] F. Y. Fraige, P. A. Langston, A. J. Matchett, J. Dodds,
|
||||
Particuology, 6, 455 (2008).
|
||||
@ -1,256 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>bond_style class2 command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>bond_style class2 command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="bond-style-class2-command">
|
||||
<span id="index-0"></span><h1>bond_style class2 command<a class="headerlink" href="#bond-style-class2-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="bond-style-class2-omp-command">
|
||||
<h1>bond_style class2/omp command<a class="headerlink" href="#bond-style-class2-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style class2
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style class2
|
||||
bond_coeff 1 1.0 100.0 80.0 80.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>class2</em> bond style uses the potential</p>
|
||||
<img alt="_images/bond_class2.jpg" class="align-center" src="_images/bond_class2.jpg" />
|
||||
<p>where r0 is the equilibrium bond distance.</p>
|
||||
<p>See <a class="reference internal" href="pair_modify.html#sun"><span>(Sun)</span></a> for a description of the COMPASS class2 force field.</p>
|
||||
<p>The following coefficients must be defined for each bond type via the
|
||||
<a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>R0 (distance)</li>
|
||||
<li>K2 (energy/distance^2)</li>
|
||||
<li>K3 (energy/distance^3)</li>
|
||||
<li>K4 (energy/distance^4)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This bond style can only be used if LAMMPS was built with the CLASS2
|
||||
package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section
|
||||
for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a>, <a class="reference internal" href="delete_bonds.html"><em>delete_bonds</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
<hr class="docutils" />
|
||||
<p id="sun"><strong>(Sun)</strong> Sun, J Phys Chem B 102, 7338-7364 (1998).</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,81 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
bond_style class2 command :h3
|
||||
bond_style class2/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
bond_style class2 :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
bond_style class2
|
||||
bond_coeff 1 1.0 100.0 80.0 80.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {class2} bond style uses the potential
|
||||
|
||||
:c,image(Eqs/bond_class2.jpg)
|
||||
|
||||
where r0 is the equilibrium bond distance.
|
||||
|
||||
See "(Sun)"_#Sun for a description of the COMPASS class2 force field.
|
||||
|
||||
The following coefficients must be defined for each bond type via the
|
||||
"bond_coeff"_bond_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
R0 (distance)
|
||||
K2 (energy/distance^2)
|
||||
K3 (energy/distance^3)
|
||||
K4 (energy/distance^4) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the CLASS2
|
||||
package. See the "Making LAMMPS"_Section_start.html#start_3 section
|
||||
for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
:line
|
||||
|
||||
:link(Sun)
|
||||
[(Sun)] Sun, J Phys Chem B 102, 7338-7364 (1998).
|
||||
@ -1,276 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>bond_coeff command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>bond_coeff command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="bond-coeff-command">
|
||||
<span id="index-0"></span><h1>bond_coeff command<a class="headerlink" href="#bond-coeff-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_coeff N args
|
||||
</pre></div>
|
||||
</div>
|
||||
<ul class="simple">
|
||||
<li>N = bond type (see asterisk form below)</li>
|
||||
<li>args = coefficients for one or more bond types</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_coeff 5 80.0 1.2
|
||||
bond_coeff * 30.0 1.5 1.0 1.0
|
||||
bond_coeff 1*4 30.0 1.5 1.0 1.0
|
||||
bond_coeff 1 harmonic 200.0 1.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Specify the bond force field coefficients for one or more bond types.
|
||||
The number and meaning of the coefficients depends on the bond style.
|
||||
Bond coefficients can also be set in the data file read by the
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a> command or in a restart file.</p>
|
||||
<p>N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple bond types. This takes the
|
||||
form “*” or “<em>n” or “n</em>” or “m*n”. If N = the number of bond types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
leading asterisk means all types from 1 to n (inclusive). A trailing
|
||||
asterisk means all types from n to N (inclusive). A middle asterisk
|
||||
means all types from m to n (inclusive).</p>
|
||||
<p>Note that using a bond_coeff command can override a previous setting
|
||||
for the same bond type. For example, these commands set the coeffs
|
||||
for all bond types, then overwrite the coeffs for just bond type 2:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_coeff * 100.0 1.2
|
||||
bond_coeff 2 200.0 1.2
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>A line in a data file that specifies bond coefficients uses the exact
|
||||
same format as the arguments of the bond_coeff command in an input
|
||||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the “Bond Coeffs” section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre>5 80.0 1.2
|
||||
</pre></div>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<p>Here is an alphabetic list of bond styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated <a class="reference internal" href=""><em>bond_coeff</em></a> command.</p>
|
||||
<p>Note that here are also additional bond styles submitted by users
|
||||
which are included in the LAMMPS distribution. The list of these with
|
||||
links to the individual styles are given in the bond section of <a class="reference internal" href="Section_commands.html#cmd-5"><span>this page</span></a>.</p>
|
||||
<ul class="simple">
|
||||
<li><a class="reference internal" href="bond_none.html"><em>bond_style none</em></a> - turn off bonded interactions</li>
|
||||
<li><a class="reference internal" href="bond_hybrid.html"><em>bond_style hybrid</em></a> - define multiple styles of bond interactions</li>
|
||||
<li><a class="reference internal" href="bond_class2.html"><em>bond_style class2</em></a> - COMPASS (class 2) bond</li>
|
||||
<li><a class="reference internal" href="bond_fene.html"><em>bond_style fene</em></a> - FENE (finite-extensible non-linear elastic) bond</li>
|
||||
<li><a class="reference internal" href="bond_fene_expand.html"><em>bond_style fene/expand</em></a> - FENE bonds with variable size particles</li>
|
||||
<li><a class="reference internal" href="bond_harmonic.html"><em>bond_style harmonic</em></a> - harmonic bond</li>
|
||||
<li><a class="reference internal" href="bond_morse.html"><em>bond_style morse</em></a> - Morse bond</li>
|
||||
<li><a class="reference internal" href="bond_nonlinear.html"><em>bond_style nonlinear</em></a> - nonlinear bond</li>
|
||||
<li><a class="reference internal" href="bond_quartic.html"><em>bond_style quartic</em></a> - breakable quartic bond</li>
|
||||
<li><a class="reference internal" href="bond_table.html"><em>bond_style table</em></a> - tabulated by bond length</li>
|
||||
</ul>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This command must come after the simulation box is defined by a
|
||||
<a class="reference internal" href="read_data.html"><em>read_data</em></a>, <a class="reference internal" href="read_restart.html"><em>read_restart</em></a>, or
|
||||
<a class="reference internal" href="create_box.html"><em>create_box</em></a> command.</p>
|
||||
<p>A bond style must be defined before any bond coefficients are set,
|
||||
either in the input script or in a data file.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="bond_style.html"><em>bond_style</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,95 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
bond_coeff command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
bond_coeff N args :pre
|
||||
|
||||
N = bond type (see asterisk form below)
|
||||
args = coefficients for one or more bond types :ul
|
||||
|
||||
[Examples:]
|
||||
|
||||
bond_coeff 5 80.0 1.2
|
||||
bond_coeff * 30.0 1.5 1.0 1.0
|
||||
bond_coeff 1*4 30.0 1.5 1.0 1.0
|
||||
bond_coeff 1 harmonic 200.0 1.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
Specify the bond force field coefficients for one or more bond types.
|
||||
The number and meaning of the coefficients depends on the bond style.
|
||||
Bond coefficients can also be set in the data file read by the
|
||||
"read_data"_read_data.html command or in a restart file.
|
||||
|
||||
N can be specified in one of two ways. An explicit numeric value can
|
||||
be used, as in the 1st example above. Or a wild-card asterisk can be
|
||||
used to set the coefficients for multiple bond types. This takes the
|
||||
form "*" or "*n" or "n*" or "m*n". If N = the number of bond types,
|
||||
then an asterisk with no numeric values means all types from 1 to N. A
|
||||
leading asterisk means all types from 1 to n (inclusive). A trailing
|
||||
asterisk means all types from n to N (inclusive). A middle asterisk
|
||||
means all types from m to n (inclusive).
|
||||
|
||||
Note that using a bond_coeff command can override a previous setting
|
||||
for the same bond type. For example, these commands set the coeffs
|
||||
for all bond types, then overwrite the coeffs for just bond type 2:
|
||||
|
||||
bond_coeff * 100.0 1.2
|
||||
bond_coeff 2 200.0 1.2 :pre
|
||||
|
||||
A line in a data file that specifies bond coefficients uses the exact
|
||||
same format as the arguments of the bond_coeff command in an input
|
||||
script, except that wild-card asterisks should not be used since
|
||||
coefficients for all N types must be listed in the file. For example,
|
||||
under the "Bond Coeffs" section of a data file, the line that
|
||||
corresponds to the 1st example above would be listed as
|
||||
|
||||
5 80.0 1.2 :pre
|
||||
|
||||
:line
|
||||
|
||||
Here is an alphabetic list of bond styles defined in LAMMPS. Click on
|
||||
the style to display the formula it computes and coefficients
|
||||
specified by the associated "bond_coeff"_bond_coeff.html command.
|
||||
|
||||
Note that here are also additional bond styles submitted by users
|
||||
which are included in the LAMMPS distribution. The list of these with
|
||||
links to the individual styles are given in the bond section of "this
|
||||
page"_Section_commands.html#cmd_5.
|
||||
|
||||
"bond_style none"_bond_none.html - turn off bonded interactions
|
||||
"bond_style hybrid"_bond_hybrid.html - define multiple styles of bond interactions :ul
|
||||
|
||||
"bond_style class2"_bond_class2.html - COMPASS (class 2) bond
|
||||
"bond_style fene"_bond_fene.html - FENE (finite-extensible non-linear elastic) bond
|
||||
"bond_style fene/expand"_bond_fene_expand.html - FENE bonds with variable size particles
|
||||
"bond_style harmonic"_bond_harmonic.html - harmonic bond
|
||||
"bond_style morse"_bond_morse.html - Morse bond
|
||||
"bond_style nonlinear"_bond_nonlinear.html - nonlinear bond
|
||||
"bond_style quartic"_bond_quartic.html - breakable quartic bond
|
||||
"bond_style table"_bond_table.html - tabulated by bond length :ul
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This command must come after the simulation box is defined by a
|
||||
"read_data"_read_data.html, "read_restart"_read_restart.html, or
|
||||
"create_box"_create_box.html command.
|
||||
|
||||
A bond style must be defined before any bond coefficients are set,
|
||||
either in the input script or in a data file.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"bond_style"_bond_style.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,264 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>bond_style fene command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>bond_style fene command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="bond-style-fene-command">
|
||||
<span id="index-0"></span><h1>bond_style fene command<a class="headerlink" href="#bond-style-fene-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="bond-style-fene-kk-command">
|
||||
<h1>bond_style fene/kk command<a class="headerlink" href="#bond-style-fene-kk-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="bond-style-fene-omp-command">
|
||||
<h1>bond_style fene/omp command<a class="headerlink" href="#bond-style-fene-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style fene
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style fene
|
||||
bond_coeff 1 30.0 1.5 1.0 1.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>fene</em> bond style uses the potential</p>
|
||||
<img alt="_images/bond_fene.jpg" class="align-center" src="_images/bond_fene.jpg" />
|
||||
<p>to define a finite extensible nonlinear elastic (FENE) potential
|
||||
<a class="reference internal" href="special_bonds.html#kremer"><span>(Kremer)</span></a>, used for bead-spring polymer models. The first
|
||||
term is attractive, the 2nd Lennard-Jones term is repulsive. The
|
||||
first term extends to R0, the maximum extent of the bond. The 2nd
|
||||
term is cutoff at 2^(1/6) sigma, the minimum of the LJ potential.</p>
|
||||
<p>The following coefficients must be defined for each bond type via the
|
||||
<a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy/distance^2)</li>
|
||||
<li>R0 (distance)</li>
|
||||
<li>epsilon (energy)</li>
|
||||
<li>sigma (distance)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
<p>You typically should specify <a class="reference external" href="special_bonds.html"">special_bonds fene</a>
|
||||
or <a class="reference internal" href="special_bonds.html"><em>special_bonds lj/coul 0 1 1</em></a> to use this bond
|
||||
style. LAMMPS will issue a warning it that’s not the case.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a>, <a class="reference internal" href="delete_bonds.html"><em>delete_bonds</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
<hr class="docutils" />
|
||||
<p id="kremer"><strong>(Kremer)</strong> Kremer, Grest, J Chem Phys, 92, 5057 (1990).</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,88 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
bond_style fene command :h3
|
||||
bond_style fene/kk command :h3
|
||||
bond_style fene/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
bond_style fene :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
bond_style fene
|
||||
bond_coeff 1 30.0 1.5 1.0 1.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {fene} bond style uses the potential
|
||||
|
||||
:c,image(Eqs/bond_fene.jpg)
|
||||
|
||||
to define a finite extensible nonlinear elastic (FENE) potential
|
||||
"(Kremer)"_#Kremer, used for bead-spring polymer models. The first
|
||||
term is attractive, the 2nd Lennard-Jones term is repulsive. The
|
||||
first term extends to R0, the maximum extent of the bond. The 2nd
|
||||
term is cutoff at 2^(1/6) sigma, the minimum of the LJ potential.
|
||||
|
||||
The following coefficients must be defined for each bond type via the
|
||||
"bond_coeff"_bond_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy/distance^2)
|
||||
R0 (distance)
|
||||
epsilon (energy)
|
||||
sigma (distance) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
You typically should specify "special_bonds fene"_special_bonds.html"
|
||||
or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond
|
||||
style. LAMMPS will issue a warning it that's not the case.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
:line
|
||||
|
||||
:link(Kremer)
|
||||
[(Kremer)] Kremer, Grest, J Chem Phys, 92, 5057 (1990).
|
||||
@ -1,265 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>bond_style fene/expand command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>bond_style fene/expand command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="bond-style-fene-expand-command">
|
||||
<span id="index-0"></span><h1>bond_style fene/expand command<a class="headerlink" href="#bond-style-fene-expand-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="bond-style-fene-expand-omp-command">
|
||||
<h1>bond_style fene/expand/omp command<a class="headerlink" href="#bond-style-fene-expand-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style fene/expand
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style fene/expand
|
||||
bond_coeff 1 30.0 1.5 1.0 1.0 0.5
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>fene/expand</em> bond style uses the potential</p>
|
||||
<img alt="_images/bond_fene_expand.jpg" class="align-center" src="_images/bond_fene_expand.jpg" />
|
||||
<p>to define a finite extensible nonlinear elastic (FENE) potential
|
||||
<a class="reference internal" href="special_bonds.html#kremer"><span>(Kremer)</span></a>, used for bead-spring polymer models. The first
|
||||
term is attractive, the 2nd Lennard-Jones term is repulsive.</p>
|
||||
<p>The <em>fene/expand</em> bond style is similar to <em>fene</em> except that an extra
|
||||
shift factor of delta (positive or negative) is added to <em>r</em> to
|
||||
effectively change the bead size of the bonded atoms. The first term
|
||||
now extends to R0 + delta and the 2nd term is cutoff at 2^(1/6) sigma
|
||||
+ delta.</p>
|
||||
<p>The following coefficients must be defined for each bond type via the
|
||||
<a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy/distance^2)</li>
|
||||
<li>R0 (distance)</li>
|
||||
<li>epsilon (energy)</li>
|
||||
<li>sigma (distance)</li>
|
||||
<li>delta (distance)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
<p>You typically should specify <a class="reference external" href="special_bonds.html"">special_bonds fene</a>
|
||||
or <a class="reference internal" href="special_bonds.html"><em>special_bonds lj/coul 0 1 1</em></a> to use this bond
|
||||
style. LAMMPS will issue a warning it that’s not the case.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a>, <a class="reference internal" href="delete_bonds.html"><em>delete_bonds</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
<hr class="docutils" />
|
||||
<p id="kremer"><strong>(Kremer)</strong> Kremer, Grest, J Chem Phys, 92, 5057 (1990).</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,92 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
bond_style fene/expand command :h3
|
||||
bond_style fene/expand/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
bond_style fene/expand :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
bond_style fene/expand
|
||||
bond_coeff 1 30.0 1.5 1.0 1.0 0.5 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {fene/expand} bond style uses the potential
|
||||
|
||||
:c,image(Eqs/bond_fene_expand.jpg)
|
||||
|
||||
to define a finite extensible nonlinear elastic (FENE) potential
|
||||
"(Kremer)"_#Kremer, used for bead-spring polymer models. The first
|
||||
term is attractive, the 2nd Lennard-Jones term is repulsive.
|
||||
|
||||
The {fene/expand} bond style is similar to {fene} except that an extra
|
||||
shift factor of delta (positive or negative) is added to {r} to
|
||||
effectively change the bead size of the bonded atoms. The first term
|
||||
now extends to R0 + delta and the 2nd term is cutoff at 2^(1/6) sigma
|
||||
+ delta.
|
||||
|
||||
The following coefficients must be defined for each bond type via the
|
||||
"bond_coeff"_bond_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy/distance^2)
|
||||
R0 (distance)
|
||||
epsilon (energy)
|
||||
sigma (distance)
|
||||
delta (distance) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
You typically should specify "special_bonds fene"_special_bonds.html"
|
||||
or "special_bonds lj/coul 0 1 1"_special_bonds.html to use this bond
|
||||
style. LAMMPS will issue a warning it that's not the case.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
|
||||
|
||||
[Default:] none
|
||||
|
||||
:line
|
||||
|
||||
:link(Kremer)
|
||||
[(Kremer)] Kremer, Grest, J Chem Phys, 92, 5057 (1990).
|
||||
@ -1,257 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>bond_style harmonic command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>bond_style harmonic command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="bond-style-harmonic-command">
|
||||
<span id="index-0"></span><h1>bond_style harmonic command<a class="headerlink" href="#bond-style-harmonic-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="bond-style-harmonic-intel-command">
|
||||
<h1>bond_style harmonic/intel command<a class="headerlink" href="#bond-style-harmonic-intel-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="bond-style-harmonic-kk-command">
|
||||
<h1>bond_style harmonic/kk command<a class="headerlink" href="#bond-style-harmonic-kk-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="bond-style-harmonic-omp-command">
|
||||
<h1>bond_style harmonic/omp command<a class="headerlink" href="#bond-style-harmonic-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style harmonic
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style harmonic
|
||||
bond_coeff 5 80.0 1.2
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>harmonic</em> bond style uses the potential</p>
|
||||
<img alt="_images/bond_harmonic.jpg" class="align-center" src="_images/bond_harmonic.jpg" />
|
||||
<p>where r0 is the equilibrium bond distance. Note that the usual 1/2
|
||||
factor is included in K.</p>
|
||||
<p>The following coefficients must be defined for each bond type via the
|
||||
<a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>K (energy/distance^2)</li>
|
||||
<li>r0 (distance)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a>, <a class="reference internal" href="delete_bonds.html"><em>delete_bonds</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,75 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
bond_style harmonic command :h3
|
||||
bond_style harmonic/intel command :h3
|
||||
bond_style harmonic/kk command :h3
|
||||
bond_style harmonic/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
bond_style harmonic :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
bond_style harmonic
|
||||
bond_coeff 5 80.0 1.2 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {harmonic} bond style uses the potential
|
||||
|
||||
:c,image(Eqs/bond_harmonic.jpg)
|
||||
|
||||
where r0 is the equilibrium bond distance. Note that the usual 1/2
|
||||
factor is included in K.
|
||||
|
||||
The following coefficients must be defined for each bond type via the
|
||||
"bond_coeff"_bond_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
K (energy/distance^2)
|
||||
r0 (distance) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
MOLECULE package (which it is by default). See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html
|
||||
|
||||
[Default:] none
|
||||
@ -1,256 +0,0 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
||||
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
|
||||
<title>bond_style harmonic/shift command — LAMMPS documentation</title>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="stylesheet" href="_static/sphinxcontrib-images/LightBox2/lightbox2/css/lightbox.css" type="text/css" />
|
||||
|
||||
|
||||
|
||||
<link rel="top" title="LAMMPS documentation" href="index.html"/>
|
||||
|
||||
|
||||
<script src="_static/js/modernizr.min.js"></script>
|
||||
|
||||
</head>
|
||||
|
||||
<body class="wy-body-for-nav" role="document">
|
||||
|
||||
<div class="wy-grid-for-nav">
|
||||
|
||||
|
||||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||||
<div class="wy-side-nav-search">
|
||||
|
||||
|
||||
|
||||
<a href="Manual.html" class="icon icon-home"> LAMMPS
|
||||
|
||||
|
||||
|
||||
</a>
|
||||
|
||||
|
||||
<div role="search">
|
||||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||||
<input type="text" name="q" placeholder="Search docs" />
|
||||
<input type="hidden" name="check_keywords" value="yes" />
|
||||
<input type="hidden" name="area" value="default" />
|
||||
</form>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
||||
|
||||
|
||||
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_intro.html">1. Introduction</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_start.html">2. Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_commands.html">3. Commands</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_packages.html">4. Packages</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_accelerate.html">5. Accelerating LAMMPS performance</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_howto.html">6. How-to discussions</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_example.html">7. Example problems</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_perf.html">8. Performance & scalability</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_tools.html">9. Additional tools</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_modify.html">10. Modifying & extending LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_python.html">11. Python interface to LAMMPS</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_errors.html">12. Errors</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="Section_history.html">13. Future and history</a></li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</nav>
|
||||
|
||||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
||||
|
||||
|
||||
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
||||
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
||||
<a href="Manual.html">LAMMPS</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
<div class="wy-nav-content">
|
||||
<div class="rst-content">
|
||||
<div role="navigation" aria-label="breadcrumbs navigation">
|
||||
<ul class="wy-breadcrumbs">
|
||||
<li><a href="Manual.html">Docs</a> »</li>
|
||||
|
||||
<li>bond_style harmonic/shift command</li>
|
||||
<li class="wy-breadcrumbs-aside">
|
||||
|
||||
|
||||
<a href="http://lammps.sandia.gov">Website</a>
|
||||
<a href="Section_commands.html#comm">Commands</a>
|
||||
|
||||
</li>
|
||||
</ul>
|
||||
<hr/>
|
||||
|
||||
</div>
|
||||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||||
<div itemprop="articleBody">
|
||||
|
||||
<div class="section" id="bond-style-harmonic-shift-command">
|
||||
<span id="index-0"></span><h1>bond_style harmonic/shift command<a class="headerlink" href="#bond-style-harmonic-shift-command" title="Permalink to this headline">¶</a></h1>
|
||||
</div>
|
||||
<div class="section" id="bond-style-harmonic-shift-omp-command">
|
||||
<h1>bond_style harmonic/shift/omp command<a class="headerlink" href="#bond-style-harmonic-shift-omp-command" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="syntax">
|
||||
<h2>Syntax<a class="headerlink" href="#syntax" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style harmonic/shift
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="examples">
|
||||
<h2>Examples<a class="headerlink" href="#examples" title="Permalink to this headline">¶</a></h2>
|
||||
<div class="highlight-python"><div class="highlight"><pre>bond_style harmonic/shift
|
||||
bond_coeff 5 10.0 0.5 1.0
|
||||
</pre></div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="description">
|
||||
<h2>Description<a class="headerlink" href="#description" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The <em>harmonic/shift</em> bond style is a shifted harmonic bond that uses
|
||||
the potential</p>
|
||||
<img alt="_images/bond_harmonic_shift.jpg" class="align-center" src="_images/bond_harmonic_shift.jpg" />
|
||||
<p>where r0 is the equilibrium bond distance, and rc the critical distance.
|
||||
The potential is -Umin at r0 and zero at rc. The spring constant is
|
||||
k = Umin / [ 2 (r0-rc)^2].</p>
|
||||
<p>The following coefficients must be defined for each bond type via the
|
||||
<a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a> command as in the example above, or in
|
||||
the data file or restart files read by the <a class="reference internal" href="read_data.html"><em>read_data</em></a>
|
||||
or <a class="reference internal" href="read_restart.html"><em>read_restart</em></a> commands:</p>
|
||||
<ul class="simple">
|
||||
<li>Umin (energy)</li>
|
||||
<li>r0 (distance)</li>
|
||||
<li>rc (distance)</li>
|
||||
</ul>
|
||||
<hr class="docutils" />
|
||||
<p>Styles with a <em>cuda</em>, <em>gpu</em>, <em>intel</em>, <em>kk</em>, <em>omp</em>, or <em>opt</em> suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a>
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.</p>
|
||||
<p>These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a> section for more info.</p>
|
||||
<p>You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the <a class="reference internal" href="Section_start.html#start-7"><span>-suffix command-line switch</span></a> when you invoke LAMMPS, or you can
|
||||
use the <a class="reference internal" href="suffix.html"><em>suffix</em></a> command in your input script.</p>
|
||||
<p>See <a class="reference internal" href="Section_accelerate.html"><em>Section_accelerate</em></a> of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.</p>
|
||||
</div>
|
||||
<hr class="docutils" />
|
||||
<div class="section" id="restrictions">
|
||||
<h2>Restrictions<a class="headerlink" href="#restrictions" title="Permalink to this headline">¶</a></h2>
|
||||
<p>This bond style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the <a class="reference internal" href="Section_start.html#start-3"><span>Making LAMMPS</span></a>
|
||||
section for more info on packages.</p>
|
||||
</div>
|
||||
<div class="section" id="related-commands">
|
||||
<h2>Related commands<a class="headerlink" href="#related-commands" title="Permalink to this headline">¶</a></h2>
|
||||
<p><a class="reference internal" href="bond_coeff.html"><em>bond_coeff</em></a>, <a class="reference internal" href="delete_bonds.html"><em>delete_bonds</em></a>,
|
||||
<a class="reference internal" href="bond_harmonic.html"><em>bond_harmonic</em></a></p>
|
||||
<p><strong>Default:</strong> none</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<footer>
|
||||
|
||||
|
||||
<hr/>
|
||||
|
||||
<div role="contentinfo">
|
||||
<p>
|
||||
© Copyright 2013 Sandia Corporation.
|
||||
</p>
|
||||
</div>
|
||||
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||||
|
||||
</footer>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
var DOCUMENTATION_OPTIONS = {
|
||||
URL_ROOT:'./',
|
||||
VERSION:'',
|
||||
COLLAPSE_INDEX:false,
|
||||
FILE_SUFFIX:'.html',
|
||||
HAS_SOURCE: true
|
||||
};
|
||||
</script>
|
||||
<script type="text/javascript" src="_static/jquery.js"></script>
|
||||
<script type="text/javascript" src="_static/underscore.js"></script>
|
||||
<script type="text/javascript" src="_static/doctools.js"></script>
|
||||
<script type="text/javascript" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/jquery-1.11.0.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2/js/lightbox.min.js"></script>
|
||||
<script type="text/javascript" src="_static/sphinxcontrib-images/LightBox2/lightbox2-customize/jquery-noconflict.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript" src="_static/js/theme.js"></script>
|
||||
|
||||
|
||||
|
||||
|
||||
<script type="text/javascript">
|
||||
jQuery(function () {
|
||||
SphinxRtdTheme.StickyNav.enable();
|
||||
});
|
||||
</script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@ -1,77 +0,0 @@
|
||||
"LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
|
||||
|
||||
:link(lws,http://lammps.sandia.gov)
|
||||
:link(ld,Manual.html)
|
||||
:link(lc,Section_commands.html#comm)
|
||||
|
||||
:line
|
||||
|
||||
bond_style harmonic/shift command :h3
|
||||
bond_style harmonic/shift/omp command :h3
|
||||
|
||||
[Syntax:]
|
||||
|
||||
bond_style harmonic/shift :pre
|
||||
|
||||
[Examples:]
|
||||
|
||||
bond_style harmonic/shift
|
||||
bond_coeff 5 10.0 0.5 1.0 :pre
|
||||
|
||||
[Description:]
|
||||
|
||||
The {harmonic/shift} bond style is a shifted harmonic bond that uses
|
||||
the potential
|
||||
|
||||
:c,image(Eqs/bond_harmonic_shift.jpg)
|
||||
|
||||
where r0 is the equilibrium bond distance, and rc the critical distance.
|
||||
The potential is -Umin at r0 and zero at rc. The spring constant is
|
||||
k = Umin / \[ 2 (r0-rc)^2\].
|
||||
|
||||
The following coefficients must be defined for each bond type via the
|
||||
"bond_coeff"_bond_coeff.html command as in the example above, or in
|
||||
the data file or restart files read by the "read_data"_read_data.html
|
||||
or "read_restart"_read_restart.html commands:
|
||||
|
||||
Umin (energy) :ul
|
||||
r0 (distance) :ul
|
||||
rc (distance) :ul
|
||||
|
||||
:line
|
||||
|
||||
Styles with a {cuda}, {gpu}, {intel}, {kk}, {omp}, or {opt} suffix are
|
||||
functionally the same as the corresponding style without the suffix.
|
||||
They have been optimized to run faster, depending on your available
|
||||
hardware, as discussed in "Section_accelerate"_Section_accelerate.html
|
||||
of the manual. The accelerated styles take the same arguments and
|
||||
should produce the same results, except for round-off and precision
|
||||
issues.
|
||||
|
||||
These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
|
||||
KOKKOS, USER-OMP and OPT packages, respectively. They are only
|
||||
enabled if LAMMPS was built with those packages. See the "Making
|
||||
LAMMPS"_Section_start.html#start_3 section for more info.
|
||||
|
||||
You can specify the accelerated styles explicitly in your input script
|
||||
by including their suffix, or you can use the "-suffix command-line
|
||||
switch"_Section_start.html#start_7 when you invoke LAMMPS, or you can
|
||||
use the "suffix"_suffix.html command in your input script.
|
||||
|
||||
See "Section_accelerate"_Section_accelerate.html of the manual for
|
||||
more instructions on how to use the accelerated styles effectively.
|
||||
|
||||
:line
|
||||
|
||||
[Restrictions:]
|
||||
|
||||
This bond style can only be used if LAMMPS was built with the
|
||||
USER-MISC package. See the "Making LAMMPS"_Section_start.html#start_3
|
||||
section for more info on packages.
|
||||
|
||||
[Related commands:]
|
||||
|
||||
"bond_coeff"_bond_coeff.html, "delete_bonds"_delete_bonds.html,
|
||||
"bond_harmonic"_bond_harmonic.html
|
||||
|
||||
[Default:] none
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user