<li><em>args</em> = one or more of <em>off</em> or <em>loop</em> or <em>normal</em> or <em>full</em> or <em>sync</em> or <em>nosync</em> or <em>timeout</em> or <em>every</em></li>
</ul>
<pre class="literal-block">
<em>off</em> = do not collect or print any timing information
<em>loop</em> = collect only the total time for the simulation loop
<em>normal</em> = collect timer information broken down by sections (default)
<em>full</em> = like <em>normal</em> but also include CPU and thread utilzation
<em>sync</em> = explicitly synchronize MPI tasks between sections
<em>nosync</em> = do not synchronize MPI tasks between sections (default)
<em>timeout</em> elapse = set walltime limit to <em>elapse</em>
<em>every</em> Ncheck = perform timeout check every <em>Ncheck</em> steps
<p>Select the level of detail at which LAMMPS performs its CPU timings.
Multiple keywords can be specified with the <em>timer</em> command. For
keywords that are mutually exclusive, the last one specified takes
effect.</p>
<p>During a simulation run LAMMPS collects information about how much
time is spent in different sections of the code and thus can provide
information for determining performance and load imbalance problems.
This can be done at different levels of detail and accuracy. For more
information about the timing output, see this <a class="reference internal" href="Section_start.html#start-8"><span class="std std-ref">discussion of screen output</span></a>.</p>
<p>The <em>off</em> setting will turn all time measurements off. The <em>loop</em>
setting will only measure the total time for a run and not collect any
detailed per section information. With the <em>normal</em> setting, timing
information for portions of the timestep (pairwise calculations,
neighbor list construction, output, etc) are collected as well as
information about load imbalances for those sections across
procsessors. The <em>full</em> setting adds information about CPU
utilization and thread utilization, when multi-threading is enabled.</p>
<p>With the <em>sync</em> setting, all MPI tasks are synchronized at each timer
call which meaures load imbalance more accuractly, though it can also
slow down the simulation. Using the <em>nosync</em> setting (which is the
default) turns off this synchronization.</p>
<p>With the <em>timeout</em> keyword a walltime limit can be imposed that
affects the <a class="reference internal" href="run.html"><span class="doc">run</span></a> and <a class="reference internal" href="minimize.html"><span class="doc">minimize</span></a> commands.
This can be convenient when runs have to confirm to time limits,
e.g. when running under a batch system and you want to maximize
the utilization of the batch time slot, especially when the time
per timestep varies and is thus difficult to predict how many
steps a simulation can perform, or for difficult to converge
minimizations. The timeout <em>elapse</em> value should be somewhat smaller
than the time requested from the batch system, as there is usually
some overhead to launch jobs, and it may be advisable to write
out a restart after terminating a run due to a timeout.</p>
<p>The timeout timer starts when the command is issued. When the time
limit is reached, the run or energy minimization will exit on the
next step or iteration that is a multiple of the <em>Ncheck</em> value
which can be set with the <em>every</em> keyword. Default is checking
every 10 steps. After the timer timeout has expired all subsequent
run or minimize commands in the input script will be skipped.
The remaining time or timer status can be accessed with the
<a class="reference internal" href="thermo_style.html"><span class="doc">thermo</span></a> variable <em>timeremain</em>, which will be
zero, if the timeout is inactive (default setting), it will be
negative, if the timeout time is expired and positive if there
is time remaining and in this case the value of the variable are
the number of seconds remaining.</p>
<p>When the <em>timeout</em> key word is used a second time, the timer is
restarted with a new time limit. The timeout <em>elapse</em> value can
be specified as <em>off</em> or <em>unlimited</em> to impose a no timeout condition
(which is the default). The <em>elapse</em> setting can be specified as
a single number for seconds, two numbers separated by a colon (MM:SS)
for minutes and seconds, or as three numbers separated by colons for
hours, minutes, and seconds (H:MM:SS).</p>
<p>The <em>every</em> keyword sets how frequently during a run or energy
minimization the wall clock will be checked. This check count applies
to the outer iterations or time steps during minimizations or <a class="reference internal" href="run_style.html"><span class="doc">r-RESPA runs</span></a>, respectively. Checking for timeout too often,
can slow a calculation down. Checking too infrequently can make the
timeout measurement less accurate, with the run being stopped later
than desired.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Using the <em>full</em> and <em>sync</em> options provides the most detailed
and accurate timing information, but can also have a negative
performance impact due to the overhead of the many required system
calls. It is thus recommended to use these settings only when testing
tests to identify performance bottlenecks. For calculations with few
atoms or a very large number of processors, even the <em>normal</em> setting
can have a measurable negative performance impact. In those cases you
can just use the <em>loop</em> or <em>off</em> setting.</p>
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>.