120 lines
5.2 KiB
Plaintext
120 lines
5.2 KiB
Plaintext
"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
|
|
|
|
timer command :h3
|
|
|
|
[Syntax:]
|
|
|
|
timer args :pre
|
|
|
|
{args} = one or more of {off} or {loop} or {normal} or {full} or {sync} or {nosync} or {timeout} or {every} :l
|
|
{off} = do not collect or print any timing information
|
|
{loop} = collect only the total time for the simulation loop
|
|
{normal} = collect timer information broken down by sections (default)
|
|
{full} = like {normal} but also include CPU and thread utilzation
|
|
{sync} = explicitly synchronize MPI tasks between sections
|
|
{nosync} = do not synchronize MPI tasks between sections (default)
|
|
{timeout} elapse = set walltime limit to {elapse}
|
|
{every} Ncheck = perform timeout check every {Ncheck} steps :pre
|
|
|
|
[Examples:]
|
|
|
|
timer full sync
|
|
timer timeout 2:00:00 every 100
|
|
timer loop :pre
|
|
|
|
[Description:]
|
|
|
|
Select the level of detail at which LAMMPS performs its CPU timings.
|
|
Multiple keywords can be specified with the {timer} command. For
|
|
keywords that are mutually exclusive, the last one specified takes
|
|
effect.
|
|
|
|
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 "discussion of screen
|
|
output"_Section_start.html#start_8.
|
|
|
|
The {off} setting will turn all time measurements off. The {loop}
|
|
setting will only measure the total time for a run and not collect any
|
|
detailed per section information. With the {normal} 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 {full} setting adds information about CPU
|
|
utilization and thread utilization, when multi-threading is enabled.
|
|
|
|
With the {sync} 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 {nosync} setting (which is the
|
|
default) turns off this synchronization.
|
|
|
|
With the {timeout} keyword a walltime limit can be imposed that
|
|
affects the "run"_run.html and "minimize"_minimize.html 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 {elapse} 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.
|
|
|
|
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 {Ncheck} value
|
|
which can be set with the {every} 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
|
|
"thermo"_thermo_style.html variable {timeremain}, 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.
|
|
|
|
When the {timeout} key word is used a second time, the timer is
|
|
restarted with a new time limit. The timeout {elapse} value can
|
|
be specified as {off} or {unlimited} to impose a no timeout condition
|
|
(which is the default). The {elapse} 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).
|
|
|
|
The {every} 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 "r-RESPA
|
|
runs"_run_style.html, 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.
|
|
|
|
NOTE: Using the {full} and {sync} 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 {normal} setting
|
|
can have a measurable negative performance impact. In those cases you
|
|
can just use the {loop} or {off} setting.
|
|
|
|
[Restrictions:] none
|
|
|
|
[Related commands:]
|
|
|
|
"run post no"_run.html, "kspace_modify fftbench"_kspace_modify.html
|
|
|
|
[Default:]
|
|
|
|
timer normal nosync
|
|
timer timeout off
|
|
timer every 10 :pre
|