doc/src/timer.txt

   1 "LAMMPS WWW Site"_lws - "LAMMPS Documentation"_ld - "LAMMPS Commands"_lc :c
   2
   3 :link(lws,http://lammps.sandia.gov)
   4 :link(ld,Manual.html)
   5 :link(lc,Section_commands.html#comm)
   6
   7 :line
   8
   9 timer command :h3
  10
  11 [Syntax:]
  12
  13 timer args :pre
  14
  15 {args} = one or more of {off} or {loop} or {normal} or {full} or {sync} or {nosync} or {timeout} or {every} :l
  16   {off} = do not collect or print any timing information
  17   {loop} = collect only the total time for the simulation loop
  18   {normal} = collect timer information broken down by sections (default)
  19   {full} = like {normal} but also include CPU and thread utilzation
  20   {sync} = explicitly synchronize MPI tasks between sections
  21   {nosync} = do not synchronize MPI tasks between sections (default)
  22   {timeout} elapse = set walltime limit to {elapse}
  23   {every} Ncheck = perform timeout check every {Ncheck} steps :pre
  24
  25 [Examples:]
  26
  27 timer full sync
  28 timer timeout 2:00:00 every 100
  29 timer loop :pre
  30
  31 [Description:]
  32
  33 Select the level of detail at which LAMMPS performs its CPU timings.
  34 Multiple keywords can be specified with the {timer} command.  For
  35 keywords that are mutually exclusive, the last one specified takes
  36 precedence.
  37
  38 During a simulation run LAMMPS collects information about how much
  39 time is spent in different sections of the code and thus can provide
  40 information for determining performance and load imbalance problems.
  41 This can be done at different levels of detail and accuracy.  For more
  42 information about the timing output, see this "discussion of screen
  43 output in Section 2.8"_Section_start.html#start_8.
  44
  45 The {off} setting will turn all time measurements off. The {loop}
  46 setting will only measure the total time for a run and not collect any
  47 detailed per section information.  With the {normal} setting, timing
  48 information for portions of the timestep (pairwise calculations,
  49 neighbor list construction, output, etc) are collected as well as
  50 information about load imbalances for those sections across
  51 procsessors.  The {full} setting adds information about CPU
  52 utilization and thread utilization, when multi-threading is enabled.
  53
  54 With the {sync} setting, all MPI tasks are synchronized at each timer
  55 call which measures load imbalance for each section more accuractly,
  56 though it can also slow down the simulation by prohibiting overlapping
  57 independent computations on different MPI ranks  Using the {nosync}
  58 setting (which is the default) turns this synchronization off.
  59
  60 With the {timeout} keyword a walltime limit can be imposed, that
  61 affects the "run"_run.html and "minimize"_minimize.html commands.
  62 This can be convenient when calculations have to comply with execution
  63 time limits, e.g. when running under a batch system when you want to
  64 maximize the utilization of the batch time slot, especially for runs
  65 where the time per timestep varies much and thus it becomes difficult
  66 to predict how many steps a simulation can perform for a given walltime
  67 limit. This also applies for difficult to converge minimizations.
  68 The timeout {elapse} value should be somewhat smaller than the maximum
  69 wall time requested from the batch system, as there is usually
  70 some overhead to launch jobs, and it is advisable to write
  71 out a restart after terminating a run due to a timeout.
  72
  73 The timeout timer starts when the command is issued. When the time
  74 limit is reached, the run or energy minimization will exit on the
  75 next step or iteration that is a multiple of the {Ncheck} value
  76 which can be set with the {every} keyword. Default is checking
  77 every 10 steps. After the timer timeout has expired all subsequent
  78 run or minimize commands in the input script will be skipped.
  79 The remaining time or timer status can be accessed with the
  80 "thermo"_thermo_style.html variable {timeremain}, which will be
  81 zero, if the timeout is inactive (default setting), it will be
  82 negative, if the timeout time is expired and positive if there
  83 is time remaining and in this case the value of the variable are
  84 the number of seconds remaining.
  85
  86 When the {timeout} key word is used a second time, the timer is
  87 restarted with a new time limit. The timeout {elapse} value can
  88 be specified as {off} or {unlimited} to impose a no timeout condition
  89 (which is the default).  The {elapse} setting can be specified as
  90 a single number for seconds, two numbers separated by a colon (MM:SS)
  91 for minutes and seconds, or as three numbers separated by colons for
  92 hours, minutes, and seconds (H:MM:SS).
  93
  94 The {every} keyword sets how frequently during a run or energy
  95 minimization the wall clock will be checked.  This check count applies
  96 to the outer iterations or time steps during minimizations or "r-RESPA
  97 runs"_run_style.html, respectively.  Checking for timeout too often,
  98 can slow a calculation down.  Checking too infrequently can make the
  99 timeout measurement less accurate, with the run being stopped later
 100 than desired.
 101
 102 NOTE: Using the {full} and {sync} options provides the most detailed
 103 and accurate timing information, but can also have a negative
 104 performance impact due to the overhead of the many required system
 105 calls. It is thus recommended to use these settings only when testing
 106 tests to identify performance bottlenecks. For calculations with few
 107 atoms or a very large number of processors, even the {normal} setting
 108 can have a measurable negative performance impact. In those cases you
 109 can just use the {loop} or {off} setting.
 110
 111 [Restrictions:] none
 112
 113 [Related commands:]
 114
 115 "run post no"_run.html, "kspace_modify fftbench"_kspace_modify.html
 116
 117 [Default:]
 118
 119 timer normal nosync
 120 timer timeout off
 121 timer every 10 :pre