[lammps-users] Jan09 release query.

Hi, running this cut-down test case results in:

ERROR: Compute used in variable between runs is not current

which didn't happen with the previous 08 version.

I have since reverted, but I would like to use some of the new utilities. I have read the variable man page but still don't understand. Could you take a quick look and explain what is happening and what I need to do please?

Many thanks,

variablecurrentbug.in (915 Bytes)

That's not a bug, that's a feature.
Your script does not cause compute gl1x to be invoked
during the previous run 0, so it's value is not current.
Hence LAMMPS will not print its value.

Computes are not invoked between runs. Rather
their values are used if they are current. See the variable
doc page, section on Variable Accuracy.

If you add this line before your run 0, then it runs as you
expect, b/c you are forcing that compute to be evaluated
in a preceding run.

thermo_style custom step temp c_gl1x


Thanks, I will give that a whirl.

Does the variable doc page need to be updated? In fact the script I submitted was made to follow the recommendations section in the manual on Variable Accuracy, which describes the run 0, print method for evaluating the variable, but which still throws up the described error. I'm assumming the thermo_modify gets evaluated at a different time to the print and so would work.

Thanks as ever! Anthony

I just updated it for clarity, but I think the basic info was
previously correct.


Further to this thread related to variable availability, I ran into a
related problem with a script where I first minimise then run an nve that
errored saying that the compute was not current, or had not been tallied.

It took quite some time to figure out.

The minimisation took 89 timesteps, I had a dump going every 100. When the
nve run started it would error as soon as it got to the first dump. I went
up a blind alley thinking that the variable really was not available and
trying to print it out but ran into problems there.

Eventually I realised that taking the minimisation out eliminated the error,
and have hence fixed the script with a reset_timestep 0.

I don't know whether this is something worth investigating further or not -
I'll leave that up to you, but intuition says that a logic check somewhere
could be a little more general when it comes to non-zero starting timesteps.


If you post (as simple as possible) version
of the script, I can take a look.