386 lines
29 KiB
HTML
386 lines
29 KiB
HTML
<!DOCTYPE html>
|
||
<html class="writer-html5" lang="en" >
|
||
<head>
|
||
<meta charset="utf-8" /><meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||
<title>4.7. How a timestep works — LAMMPS documentation</title>
|
||
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/sphinx-design.min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/lammps.css" type="text/css" />
|
||
<link rel="shortcut icon" href="_static/lammps.ico"/>
|
||
<link rel="canonical" href="https://docs.lammps.org/Developer_flow.html" />
|
||
<!--[if lt IE 9]>
|
||
<script src="_static/js/html5shiv.min.js"></script>
|
||
<![endif]-->
|
||
|
||
<script src="_static/jquery.js?v=5d32c60e"></script>
|
||
<script src="_static/_sphinx_javascript_frameworks_compat.js?v=2cd50e6c"></script>
|
||
<script src="_static/documentation_options.js?v=5929fcd5"></script>
|
||
<script src="_static/doctools.js?v=9bcbadda"></script>
|
||
<script src="_static/sphinx_highlight.js?v=dc90522c"></script>
|
||
<script src="_static/design-tabs.js?v=f930bc37"></script>
|
||
<script async="async" src="_static/mathjax/es5/tex-mml-chtml.js?v=cadf963e"></script>
|
||
<script src="_static/js/theme.js"></script>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="next" title="4.8. Writing new styles" href="Developer_write.html" />
|
||
<link rel="prev" title="4.6. Communication patterns" href="Developer_comm_ops.html" />
|
||
</head>
|
||
|
||
<body class="wy-body-for-nav">
|
||
<div class="wy-grid-for-nav">
|
||
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
||
<div class="wy-side-scroll">
|
||
<div class="wy-side-nav-search" >
|
||
|
||
|
||
|
||
<a href="Manual.html">
|
||
|
||
<img src="_static/lammps-logo.png" class="logo" alt="Logo"/>
|
||
</a>
|
||
<div class="lammps_version">Version: <b>19 Nov 2024</b></div>
|
||
<div class="lammps_release">git info: </div>
|
||
<div role="search">
|
||
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
||
<input type="text" name="q" placeholder="Search docs" aria-label="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="Navigation menu">
|
||
<p class="caption" role="heading"><span class="caption-text">User Guide</span></p>
|
||
<ul>
|
||
<li class="toctree-l1"><a class="reference internal" href="Intro.html">1. Introduction</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Install.html">2. Install LAMMPS</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Build.html">3. Build LAMMPS</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Run_head.html">4. Run LAMMPS</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Commands.html">5. Commands</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Packages.html">6. Optional packages</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Speed.html">7. Accelerate performance</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Howto.html">8. Howto discussions</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Examples.html">9. Example scripts</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Tools.html">10. Auxiliary tools</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Errors.html">11. Errors</a></li>
|
||
</ul>
|
||
<p class="caption" role="heading"><span class="caption-text">Programmer Guide</span></p>
|
||
<ul class="current">
|
||
<li class="toctree-l1"><a class="reference internal" href="Library.html">1. LAMMPS Library Interfaces</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Python_head.html">2. Use Python with LAMMPS</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Modify.html">3. Modifying & extending LAMMPS</a></li>
|
||
<li class="toctree-l1 current"><a class="reference internal" href="Developer.html">4. Information for Developers</a><ul class="current">
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_org.html">4.1. Source files</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_org.html#class-topology">4.2. Class topology</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_code_design.html">4.3. Code design</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_parallel.html">4.4. Parallel algorithms</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_atom.html">4.5. Accessing per-atom data</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_comm_ops.html">4.6. Communication patterns</a></li>
|
||
<li class="toctree-l2 current"><a class="current reference internal" href="#">4.7. How a timestep works</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_write.html">4.8. Writing new styles</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_notes.html">4.9. Notes for developers and code maintainers</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_updating.html">4.10. Notes for updating code written for older LAMMPS versions</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_plugins.html">4.11. Writing plugins</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_unittest.html">4.12. Adding tests for unit testing</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Classes.html">4.13. C++ base classes</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_platform.html">4.14. Platform abstraction functions</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_utils.html">4.15. Utility functions</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_utils.html#special-math-functions">4.16. Special Math functions</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_utils.html#tokenizer-classes">4.17. Tokenizer classes</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_utils.html#argument-parsing-classes">4.18. Argument parsing classes</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_utils.html#file-reader-classes">4.19. File reader classes</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_utils.html#memory-pool-classes">4.20. Memory pool classes</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_utils.html#eigensolver-functions">4.21. Eigensolver functions</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_utils.html#communication-buffer-coding-with-ubuf">4.22. Communication buffer coding with <em>ubuf</em></a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="Developer_grid.html">4.23. Use of distributed grids within style classes</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<p class="caption" role="heading"><span class="caption-text">Command Reference</span></p>
|
||
<ul>
|
||
<li class="toctree-l1"><a class="reference internal" href="commands_list.html">Commands</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="fixes.html">Fix Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="computes.html">Compute Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="pairs.html">Pair Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="bonds.html">Bond Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="angles.html">Angle Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="dihedrals.html">Dihedral Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="impropers.html">Improper Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="dumps.html">Dump Styles</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="fix_modify_atc_commands.html">fix_modify AtC commands</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="Bibliography.html">Bibliography</a></li>
|
||
</ul>
|
||
|
||
</div>
|
||
</div>
|
||
</nav>
|
||
|
||
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap"><nav class="wy-nav-top" aria-label="Mobile navigation menu" >
|
||
<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 style-external-links">
|
||
<div role="navigation" aria-label="Page navigation">
|
||
<ul class="wy-breadcrumbs">
|
||
<li><a href="Manual.html" class="icon icon-home" aria-label="Home"></a></li>
|
||
<li class="breadcrumb-item"><a href="Developer.html"><span class="section-number">4. </span>Information for Developers</a></li>
|
||
<li class="breadcrumb-item active"><span class="section-number">4.7. </span>How a timestep works</li>
|
||
<li class="wy-breadcrumbs-aside">
|
||
<a href="https://www.lammps.org"><img src="_static/lammps-logo.png" width="64" height="16" alt="LAMMPS Homepage"></a> | <a href="Commands_all.html">Commands</a>
|
||
</li>
|
||
</ul><div class="rst-breadcrumbs-buttons" role="navigation" aria-label="Sequential page navigation">
|
||
<a href="Developer_comm_ops.html" class="btn btn-neutral float-left" title="4.6. Communication patterns" accesskey="p"><span class="fa fa-arrow-circle-left" aria-hidden="true"></span> Previous</a>
|
||
<a href="Developer_write.html" class="btn btn-neutral float-right" title="4.8. Writing new styles" accesskey="n">Next <span class="fa fa-arrow-circle-right" aria-hidden="true"></span></a>
|
||
</div>
|
||
<hr/>
|
||
</div>
|
||
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
||
<div itemprop="articleBody">
|
||
|
||
<p><span class="math notranslate nohighlight">\(\renewcommand{\AA}{\text{Å}}\)</span></p>
|
||
<section id="how-a-timestep-works">
|
||
<h1><span class="section-number">4.7. </span>How a timestep works<a class="headerlink" href="#how-a-timestep-works" title="Link to this heading"></a></h1>
|
||
<p>The first and most fundamental operation within LAMMPS to understand is
|
||
how a timestep is structured. Timestepping is performed by calling
|
||
methods of the Integrate class instance within the Update class. Since
|
||
Integrate is a base class, it will point to an instance of a derived
|
||
class corresponding to what is selected by the <a class="reference internal" href="run_style.html"><span class="doc">run_style</span></a> input script command.</p>
|
||
<p>In this section, the timestep implemented by the Verlet class is
|
||
described. A similar timestep protocol is implemented by the Respa
|
||
class, for the r-RESPA hierarchical timestepping method.</p>
|
||
<p>The Min base class performs energy minimization, so does not perform a
|
||
literal timestep. But it has logic similar to what is described here,
|
||
to compute forces and invoke fixes at each iteration of a minimization.
|
||
Differences between time integration and minimization are highlighted at
|
||
the end of this section.</p>
|
||
<p>The Verlet class is encoded in the <code class="docutils literal notranslate"><span class="pre">src/verlet.cpp</span></code> and <code class="docutils literal notranslate"><span class="pre">verlet.h</span></code>
|
||
files. It implements the velocity-Verlet timestepping algorithm. The
|
||
workhorse method is <code class="docutils literal notranslate"><span class="pre">Verlet::run()</span></code>, but first we highlight several
|
||
other methods in the class.</p>
|
||
<ul class="simple">
|
||
<li><p>The <code class="docutils literal notranslate"><span class="pre">init()</span></code> method is called at the beginning of each dynamics
|
||
run. It simply sets some internal flags, based on user settings in
|
||
other parts of the code.</p></li>
|
||
<li><p>The <code class="docutils literal notranslate"><span class="pre">setup()</span></code> or <code class="docutils literal notranslate"><span class="pre">setup_minimal()</span></code> methods are also called before
|
||
each run. The velocity-Verlet method requires current forces be
|
||
calculated before the first timestep, so these routines compute
|
||
forces due to all atomic interactions, using the same logic that
|
||
appears in the timestepping described next. A few fixes are also
|
||
invoked, using the mechanism described in the next section. Various
|
||
counters are also initialized before the run begins. The
|
||
<code class="docutils literal notranslate"><span class="pre">setup_minimal()</span></code> method is a variant that has a flag for performing
|
||
less setup. This is used when runs are continued and information
|
||
from the previous run is still valid. For example, if repeated
|
||
short LAMMPS runs are being invoked, interleaved by other commands,
|
||
via the <em>pre no</em> and <em>every</em> options of the run command, the
|
||
<code class="docutils literal notranslate"><span class="pre">setup_minimal()</span></code> method is used.</p></li>
|
||
<li><p>The <code class="docutils literal notranslate"><span class="pre">force_clear()</span></code> method initializes force and other arrays to
|
||
zero before each timestep, so that forces (torques, etc) can be
|
||
accumulated.</p></li>
|
||
</ul>
|
||
<p>Now for the <code class="docutils literal notranslate"><span class="pre">Verlet::run()</span></code> method. Its basic structure in hi-level
|
||
pseudocode is shown below. In the actual code in <code class="docutils literal notranslate"><span class="pre">src/verlet.cpp</span></code>
|
||
some of these operations are conditionally invoked.</p>
|
||
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="n">loop</span> <span class="n">over</span> <span class="n">N</span> <span class="n">timesteps</span><span class="p">:</span>
|
||
<span class="k">if</span> <span class="n">timeout</span> <span class="n">condition</span><span class="p">:</span> <span class="k">break</span>
|
||
<span class="n">ev_set</span><span class="p">()</span>
|
||
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">initial_integrate</span><span class="p">()</span>
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">post_integrate</span><span class="p">()</span>
|
||
|
||
<span class="n">nflag</span> <span class="o">=</span> <span class="n">neighbor</span><span class="o">-></span><span class="n">decide</span><span class="p">()</span>
|
||
<span class="k">if</span> <span class="n">nflag</span><span class="p">:</span>
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">pre_exchange</span><span class="p">()</span>
|
||
<span class="n">domain</span><span class="o">-></span><span class="n">pbc</span><span class="p">()</span>
|
||
<span class="n">domain</span><span class="o">-></span><span class="n">reset_box</span><span class="p">()</span>
|
||
<span class="n">comm</span><span class="o">-></span><span class="n">setup</span><span class="p">()</span>
|
||
<span class="n">neighbor</span><span class="o">-></span><span class="n">setup_bins</span><span class="p">()</span>
|
||
<span class="n">comm</span><span class="o">-></span><span class="n">exchange</span><span class="p">()</span>
|
||
<span class="n">comm</span><span class="o">-></span><span class="n">borders</span><span class="p">()</span>
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">pre_neighbor</span><span class="p">()</span>
|
||
<span class="n">neighbor</span><span class="o">-></span><span class="n">build</span><span class="p">()</span>
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">post_neighbor</span><span class="p">()</span>
|
||
<span class="k">else</span><span class="p">:</span>
|
||
<span class="n">comm</span><span class="o">-></span><span class="n">forward_comm</span><span class="p">()</span>
|
||
|
||
<span class="n">force_clear</span><span class="p">()</span>
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">pre_force</span><span class="p">()</span>
|
||
|
||
<span class="n">pair</span><span class="o">-></span><span class="n">compute</span><span class="p">()</span>
|
||
<span class="n">bond</span><span class="o">-></span><span class="n">compute</span><span class="p">()</span>
|
||
<span class="n">angle</span><span class="o">-></span><span class="n">compute</span><span class="p">()</span>
|
||
<span class="n">dihedral</span><span class="o">-></span><span class="n">compute</span><span class="p">()</span>
|
||
<span class="n">improper</span><span class="o">-></span><span class="n">compute</span><span class="p">()</span>
|
||
<span class="n">kspace</span><span class="o">-></span><span class="n">compute</span><span class="p">()</span>
|
||
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">pre_reverse</span><span class="p">()</span>
|
||
<span class="n">comm</span><span class="o">-></span><span class="n">reverse_comm</span><span class="p">()</span>
|
||
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">post_force</span><span class="p">()</span>
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">final_integrate</span><span class="p">()</span>
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">end_of_step</span><span class="p">()</span>
|
||
|
||
<span class="k">if</span> <span class="nb">any</span> <span class="n">output</span> <span class="n">on</span> <span class="n">this</span> <span class="n">step</span><span class="p">:</span>
|
||
<span class="n">output</span><span class="o">-></span><span class="n">write</span><span class="p">()</span>
|
||
|
||
<span class="c1"># after loop</span>
|
||
<span class="n">fix</span><span class="o">-></span><span class="n">post_run</span><span class="p">()</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">ev_set()</span></code> method (in the parent Integrate class), sets two flags
|
||
(<em>eflag</em> and <em>vflag</em>) for energy and virial computation. Each flag
|
||
encodes whether global and/or per-atom energy and virial should be
|
||
calculated on this timestep, because some fix or variable or output will
|
||
need it. These flags are passed to the various methods that compute
|
||
particle interactions, so that they either compute and tally the
|
||
corresponding data or can skip the extra calculations if the energy and
|
||
virial are not needed. See the comments for the <code class="docutils literal notranslate"><span class="pre">Integrate::ev_set()</span></code>
|
||
method, which document the flag values.</p>
|
||
<p>At various points of the timestep, fixes are invoked,
|
||
e.g. <code class="docutils literal notranslate"><span class="pre">fix->initial_integrate()</span></code>. In the code, this is actually done
|
||
via the Modify class, which stores all the Fix objects and lists of which
|
||
should be invoked at what point in the timestep. Fixes are the LAMMPS
|
||
mechanism for tailoring the operations of a timestep for a particular
|
||
simulation. As described elsewhere, each fix has one or more methods,
|
||
each of which is invoked at a specific stage of the timestep, as show in
|
||
the timestep pseudocode. All the active fixes defined in an input
|
||
script, that are flagged to have an <code class="docutils literal notranslate"><span class="pre">initial_integrate()</span></code> method, are
|
||
invoked at the beginning of each timestep. Examples are <a class="reference internal" href="fix_nve.html"><span class="doc">fix nve</span></a> or <a class="reference internal" href="fix_nh.html"><span class="doc">fix nvt or fix npt</span></a> which perform the
|
||
start-of-timestep velocity-Verlet integration operations to update
|
||
velocities by a half-step, and coordinates by a full step. The
|
||
<code class="docutils literal notranslate"><span class="pre">post_integrate()</span></code> method is next for operations that need to happen
|
||
immediately after those updates. Only a few fixes use this, e.g. to
|
||
reflect particles off box boundaries in the <a class="reference internal" href="fix_wall_reflect.html"><span class="doc">FixWallReflect class</span></a>.</p>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">decide()</span></code> method in the Neighbor class determines whether
|
||
neighbor lists need to be rebuilt on the current timestep (conditions
|
||
can be changed using the <a class="reference internal" href="neigh_modify.html"><span class="doc">neigh_modify every/delay/check</span></a> command). If not, coordinates of ghost atoms are
|
||
acquired by each processor via the <code class="docutils literal notranslate"><span class="pre">forward_comm()</span></code> method of the Comm
|
||
class. If neighbor lists need to be built, several operations within
|
||
the inner if clause of the pseudocode are first invoked. The
|
||
<code class="docutils literal notranslate"><span class="pre">pre_exchange()</span></code> method of any defined fixes is invoked first.
|
||
Typically, this inserts or deletes particles from the system.</p>
|
||
<p>Periodic boundary conditions are then applied by the Domain class via
|
||
its <code class="docutils literal notranslate"><span class="pre">pbc()</span></code> method to remap particles that have moved outside the
|
||
simulation box back into the box. Note that this is not done every
|
||
timestep, but only when neighbor lists are rebuilt. This is so that
|
||
each processor’s subdomain will have consistent (nearby) atom
|
||
coordinates for its owned and ghost atoms. It is also why dumped atom
|
||
coordinates may be slightly outside the simulation box if not dumped
|
||
on a step where the neighbor lists are rebuilt.</p>
|
||
<p>The box boundaries are then reset (if needed) via the <code class="docutils literal notranslate"><span class="pre">reset_box()</span></code>
|
||
method of the Domain class, e.g. if box boundaries are shrink-wrapped to
|
||
current particle coordinates. A change in the box size or shape
|
||
requires internal information for communicating ghost atoms (Comm class)
|
||
and neighbor list bins (Neighbor class) to be updated. The <code class="docutils literal notranslate"><span class="pre">setup()</span></code>
|
||
method of the Comm class and <code class="docutils literal notranslate"><span class="pre">setup_bins()</span></code> method of the Neighbor
|
||
class perform the update.</p>
|
||
<p>The code is now ready to migrate atoms that have left a processor’s
|
||
geometric subdomain to new processors. The <code class="docutils literal notranslate"><span class="pre">exchange()</span></code> method of
|
||
the Comm class performs this operation. The <code class="docutils literal notranslate"><span class="pre">borders()</span></code> method of the
|
||
Comm class then identifies ghost atoms surrounding each processor’s
|
||
subdomain and communicates ghost atom information to neighboring
|
||
processors. It does this by looping over all the atoms owned by a
|
||
processor to make lists of those to send to each neighbor processor. On
|
||
subsequent timesteps, the lists are used by the <code class="docutils literal notranslate"><span class="pre">Comm::forward_comm()</span></code>
|
||
method.</p>
|
||
<p>Fixes with a <code class="docutils literal notranslate"><span class="pre">pre_neighbor()</span></code> method are then called. These typically
|
||
re-build some data structure stored by the fix that depends on the
|
||
current atoms owned by each processor.</p>
|
||
<p>Now that each processor has a current list of its owned and ghost
|
||
atoms, LAMMPS is ready to rebuild neighbor lists via the <code class="docutils literal notranslate"><span class="pre">build()</span></code>
|
||
method of the Neighbor class. This is typically done by binning all
|
||
owned and ghost atoms, and scanning a stencil of bins around each
|
||
owned atom’s bin to make a Verlet list of neighboring atoms within the
|
||
force cutoff plus neighbor skin distance.</p>
|
||
<p>In the next portion of the timestep, all interaction forces between
|
||
particles are computed, after zeroing the per-atom force vector via the
|
||
<code class="docutils literal notranslate"><span class="pre">force_clear()</span></code> method. If the newton flag is set to <em>on</em> by the
|
||
newton command, forces are added to both owned and ghost atoms, otherwise
|
||
only to owned (aka local) atoms.</p>
|
||
<p>Pairwise forces are calculated first, which enables the global virial
|
||
(if requested) to be calculated cheaply (at O(N) cost instead of O(N**2)
|
||
at the end of the <code class="docutils literal notranslate"><span class="pre">Pair::compute()</span></code> method), by a dot product of atom
|
||
coordinates and forces. By including owned and ghost atoms in the dot
|
||
product, the effect of periodic boundary conditions is correctly
|
||
accounted for. Molecular topology interactions (bonds, angles,
|
||
dihedrals, impropers) are calculated next (if supported by the current
|
||
atom style). The final contribution is from long-range Coulombic
|
||
interactions, invoked by the KSpace class.</p>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">pre_reverse()</span></code> method in fixes is used for operations that have to
|
||
be done <em>before</em> the upcoming reverse communication (e.g. to perform
|
||
additional data transfers or reductions for data computed during the
|
||
force computation and stored with ghost atoms).</p>
|
||
<p>If the newton flag is on, forces on ghost atoms are communicated and
|
||
summed back to their corresponding owned atoms. The <code class="docutils literal notranslate"><span class="pre">reverse_comm()</span></code>
|
||
method of the Comm class performs this operation, which is essentially
|
||
the inverse operation of sending copies of owned atom coordinates to
|
||
other processor’s ghost atoms.</p>
|
||
<p>At this point in the timestep, the total force on each (local) atom is
|
||
known. Additional force constraints (external forces, SHAKE, etc) are
|
||
applied by Fixes that have a <code class="docutils literal notranslate"><span class="pre">post_force()</span></code> method. The second half
|
||
of the velocity-Verlet integration, <code class="docutils literal notranslate"><span class="pre">final_integrate()</span></code> is then
|
||
performed (another half-step update of the velocities) via fixes like
|
||
nve, nvt, npt.</p>
|
||
<p>At the end of the timestep, fixes that contain an <code class="docutils literal notranslate"><span class="pre">end_of_step()</span></code>
|
||
method are invoked. These typically perform a diagnostic calculation,
|
||
e.g. the ave/time and ave/spatial fixes. The final operation of the
|
||
timestep is to perform any requested output, via the <code class="docutils literal notranslate"><span class="pre">write()</span></code> method
|
||
of the Output class. There are 3 kinds of LAMMPS output: thermodynamic
|
||
output to the screen and log file, snapshots of atom data to a dump
|
||
file, and restart files. See the <a class="reference internal" href="thermo_style.html"><span class="doc">thermo_style</span></a>,
|
||
<a class="reference internal" href="dump.html"><span class="doc">dump</span></a>, and <a class="reference internal" href="restart.html"><span class="doc">restart</span></a> commands for more
|
||
details.</p>
|
||
<p>The flow of control during energy minimization iterations is similar to
|
||
that of a molecular dynamics timestep. Forces are computed, neighbor
|
||
lists are built as needed, atoms migrate to new processors, and atom
|
||
coordinates and forces are communicated to neighboring processors. The
|
||
only difference is what Fix class operations are invoked when. Only a
|
||
subset of LAMMPS fixes are useful during energy minimization, as
|
||
explained in their individual doc pages. The relevant Fix class methods
|
||
are <code class="docutils literal notranslate"><span class="pre">min_pre_exchange()</span></code>, <code class="docutils literal notranslate"><span class="pre">min_pre_force()</span></code>, and
|
||
<code class="docutils literal notranslate"><span class="pre">min_post_force()</span></code>. Each fix is invoked at the appropriate place
|
||
within the minimization iteration. For example, the
|
||
<code class="docutils literal notranslate"><span class="pre">min_post_force()</span></code> method is analogous to the <code class="docutils literal notranslate"><span class="pre">post_force()</span></code> method
|
||
for dynamics; it is used to alter or constrain forces on each atom,
|
||
which affects the minimization procedure.</p>
|
||
<p>After all iterations are completed, there is a <code class="docutils literal notranslate"><span class="pre">cleanup</span></code> step which
|
||
calls the <code class="docutils literal notranslate"><span class="pre">post_run()</span></code> method of fixes to perform operations only required
|
||
at the end of a calculation (like freeing temporary storage or creating
|
||
final outputs).</p>
|
||
</section>
|
||
|
||
|
||
</div>
|
||
</div>
|
||
<footer><div class="rst-footer-buttons" role="navigation" aria-label="Footer">
|
||
<a href="Developer_comm_ops.html" class="btn btn-neutral float-left" title="4.6. Communication patterns" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left" aria-hidden="true"></span> Previous</a>
|
||
<a href="Developer_write.html" class="btn btn-neutral float-right" title="4.8. Writing new styles" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right" aria-hidden="true"></span></a>
|
||
</div>
|
||
|
||
<hr/>
|
||
|
||
<div role="contentinfo">
|
||
<p>© Copyright 2003-2025 Sandia Corporation.</p>
|
||
</div>
|
||
|
||
Built with <a href="https://www.sphinx-doc.org/">Sphinx</a> using a
|
||
<a href="https://github.com/readthedocs/sphinx_rtd_theme">theme</a>
|
||
provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
||
|
||
|
||
</footer>
|
||
</div>
|
||
</div>
|
||
</section>
|
||
</div>
|
||
<script>
|
||
jQuery(function () {
|
||
SphinxRtdTheme.Navigation.enable(false);
|
||
});
|
||
</script>
|
||
|
||
</body>
|
||
</html> |