(1) The variable may be evaluated accurately. If it contains references to a compute or fix, and these values were calculated on @@ -530,9 +530,11 @@ used by the variable and the result will be accurate.
(2) LAMMPS may not be able to evaluate the variable and generate an error. For example, if the variable requires a quantity from a -compute that is not current, LAMMPS will not do it. -This means, for example, that such a variable cannot be evaluated -before the first run has occurred. +compute that is not current, LAMMPS will generate an +error. This means, for example, that such a variable cannot be +evaluated before the first run has occurred. Likewise, in between +runs, such a variable cannot be accessed unless it was evaluated on +the last timestep of the preceding run, e.g. by thermodynamic output.
One way to get around this problem is to perform a 0-timestep run before using the variable. For example, these commands @@ -560,7 +562,10 @@ does not change the input state for the 1000-timestep run that follows. Also note that the 0-timestep run must actually use and invoke the compute in question (e.g. via thermo or dump output) in order for it to enable the compute to be -used in a variable after the run. +used in a variable after the run. Thus if you are trying to print a +variable that uses a compute you have defined, you could insure it was +invoked on the last timestep of the preceding run by including it in +thermodynamic output.
Unlike computes, fixes will never generate an error if their values are accessed by a variable in between runs. They always diff --git a/doc/variable.txt b/doc/variable.txt index 7a32440b31..09b506a942 100644 --- a/doc/variable.txt +++ b/doc/variable.txt @@ -508,9 +508,9 @@ after or in between runs, e.g. by including them in a "print"_print.html command. In this case, if a compute is needed to evaluate a variable (either directly or indirectly), LAMMPS will not invoke the compute, but it will use a value previously calculated by -the compute if it is current. Fixes will always provide a quantity -needed by a variable, but the quantity may or may not be current. -This leads to one of three kinds of behavior: +the compute, and can do this only if it is current. Fixes will always +provide a quantity needed by a variable, but the quantity may or may +not be current. This leads to one of three kinds of behavior: (1) The variable may be evaluated accurately. If it contains references to a compute or fix, and these values were calculated on @@ -519,9 +519,11 @@ used by the variable and the result will be accurate. (2) LAMMPS may not be able to evaluate the variable and generate an error. For example, if the variable requires a quantity from a -"compute"_compute.html that is not current, LAMMPS will not do it. -This means, for example, that such a variable cannot be evaluated -before the first run has occurred. +"compute"_compute.html that is not current, LAMMPS will generate an +error. This means, for example, that such a variable cannot be +evaluated before the first run has occurred. Likewise, in between +runs, such a variable cannot be accessed unless it was evaluated on +the last timestep of the preceding run, e.g. by thermodynamic output. One way to get around this problem is to perform a 0-timestep run before using the variable. For example, these commands @@ -549,7 +551,10 @@ does not change the input state for the 1000-timestep run that follows. Also note that the 0-timestep run must actually use and invoke the compute in question (e.g. via "thermo"_thermo_style.html or "dump"_dump.html output) in order for it to enable the compute to be -used in a variable after the run. +used in a variable after the run. Thus if you are trying to print a +variable that uses a compute you have defined, you could insure it was +invoked on the last timestep of the preceding run by including it in +thermodynamic output. Unlike computes, "fixes"_fix.html will never generate an error if their values are accessed by a variable in between runs. They always