Energy was not tallied on needed timestep

LAMMPS LAMMPS Mailing List Mirror
1

Hello all,

I used lammps (7 Dec 2015, gpu version) to run a simulation based on a restart file generated by cpu version of lammps, and got a message 'Energy was not tallied on needed timestep (../compute_pe.cpp:75)' right after the initial step output. The input file for gpu is essentially identical to the cpu version except three parameters (thermo, restart, run) are different. A long simulation had been run by cpu version with no error before I switched to gpu. The full input file for gpu is below. Thanks a lot.

Chunguang

*********************** input file ***********************

units metal
boundary p p p
atom_style atomic
read_restart restart.*
pair_style eam/fs
pair_coeff * * \{home\}/code/lammps/potentials/Cu\-Zr\_2\.eam\.fs Cu Zr thermo 1000000 thermo\_style custom step temp pe ke vol press timestep 0\.002 fix fall all npt temp 900 900 0\.1 iso 0\.0 0\.0 1\.0 restart 50000000 restart variable vtime equal step\*0\.000002 variable vtemp equal temp variable ft format vtemp %\.8g variable vpe equal pe/atoms variable fpe format vpe %\.8g variable vke equal ke/atoms variable fke format vke %\.8g variable vvol equal vol/atoms variable fv format vvol %\.8g variable vp equal press variable fp format vp %\.8g fix fprint all print 100000 "{vtime} \{ft\} {fpe} \{fke\} {fv} ${fp}" append thermolog.dat screen no
run 50000000

2

Hello all,

I used lammps (7 Dec 2015, gpu version) to run a simulation based on a
restart file generated by cpu version of lammps, and got a message
'Energy was not tallied on needed timestep (../compute_pe.cpp:75)' right
after the initial step output. The input file for gpu is essentially
identical to the cpu version except three parameters (thermo, restart,
run) are different. A long simulation had been run by cpu version with
no error before I switched to gpu. The full input file for gpu is below.

this error has *nothing* to do with using GPU styles.

you set your thermo output to be generated and ever 1 million step,
but your fix print command tries to access them every 100 thousand
steps. that won't do. you cannot print what you have not computed.

axel.

3

Actually, I think that should work. The fix print command has

logic to insure the variables it needs are current on timesteps

it will output. E.g. if you add these lines to bench/in.lj,

it works fine:

variable vpe equal pe
variable fpe format vpe %.8g
fix 10 all print 10 “PE1 = ${fpe}”

or just

variable pe equal pe
fix 20 all print 10 “PE2 = ${pe}”

even though thermo output is only on step 100.

Something else must be going on with your script.

Steve

4

Hello Steve and Axel,

It appears Axel is right. I tried with

thermo 100

fix fprint all print 10 …

and it didn’t work. But changing to ‘fix fprint all print 100’ or ‘fix fprint all print 200’ it worked. I did this test using version (9 Dec 2014).

Thanks.

Chunguang

5

Hello Steve and Axel,

It appears Axel is right. I tried with

i have to disagree. steve is correct. there is a very subtle 64-bit
integer bug in fix print.

thermo 100

fix fprint all print 10 ....

and it didn't work. But changing to 'fix fprint all print 100' or 'fix
fprint all print 200' it worked. I did this test using version (9 Dec 2014).

and if you would add:

reset_timestep 0

to your script somewhere in a line before "run", suddenly you *can*
use fix print with a print frequency smaller than the thermo
frequency.

the code in fix print that signals on which timestep to *additionally*
invoke computes cannot handle timesteps larger than 2147483647
with the little one line change below, it will work the way as steve
said it would.

diff --git a/src/fix_print.cpp b/src/fix_print.cpp
index 3c54772..4ed1628 100644
--- a/src/fix_print.cpp
+++ b/src/fix_print.cpp
@@ -93,7 +93,7 @@ FixPrint::FixPrint(LAMMPS *lmp, int narg, char **arg) :
   // since don't know a priori which are invoked via variables by this fix
   // once in end_of_step() can set timestep for ones actually invoked

- int nfirst = (update->ntimestep/nevery)*nevery + nevery;
+ const bigint nfirst = (update->ntimestep/nevery)*nevery + nevery;
   modify->addstep_compute_all(nfirst);
}

6

Thanks, Axel. It's good to know that.

7

I have a similar problem. I’ve tried upgrading to the latest lammps version today (development version) but it didn’t help.

I have thermo every 2000 steps and print energy output every 10 steps.

If I do a short simulation

run 2000

run 5000

this is fine, but if I do

run 2000

reset_timestep 0

run 5000

It crashes with the energy tally error on the first step of run 5000.

If I set thermo every 10 steps to match the frequency of energy print statements, it doesn’t crash.

This was compiled with the GPU package but it is not running on the GPU.

If you would like me to provide more details, don’t hesitate to let me know.

Thank you.

Best regards,

James

8

yes, provide as small,short as possible input script

that triggers the problem. LAMMPS may throw

an error if you don’t have a current energy (due to

the reset_timestep), but it shouldn’t crash.

Steve