fix ave/time problem

Hello,

I am having some difficulty with the fix ave/time command.
For example, as a test, I am trying to get an average every 100 timesteps from timesteps 10, 20, 30 etc up to 100.

The doc page has 3 parameters: Nevery, Nrepeat, and Nfrequency

Therefore, my fix ave/time looks like:

fix ave/time 10 10 100

Since Nfreq = 100, I will compute the final average on timestep 100.

Additionally, I repeat 10 times with step size 10.

This means that I get the points every 10 timesteps (10,20,30 etc) and I repeat 10 times (so 10,20,30 up to 100). However, if I run for 100 timesteps, there is no data in output file. If I run for 200 timesteps, I do get data. Why must I run twice as long? Does it not count the first 100 timesteps? I found this consistent with running for 10,000 timesteps and so on (I Wanted to make sure the problem persisted).

So the problem that I am finding is that in order to get averages, I actually need to run twice as long. Can someone help me address this problem?

Ben

Hello,

I am having some difficulty with the fix ave/time command.
For example, as a test, I am trying to get an average every 100 timesteps
from timesteps 10, 20, 30 etc up to 100.

The doc page has 3 parameters: Nevery, Nrepeat, and Nfrequency

Therefore, my fix ave/time looks like:

fix ave/time 10 10 100

Since Nfreq = 100, I will compute the final average on timestep 100.

Additionally, I repeat 10 times with step size 10.

This means that I get the points every 10 timesteps (10,20,30 etc) and I
repeat 10 times (so 10,20,30 up to 100). However, if I run for 100
timesteps, there is no data in output file. If I run for 200 timesteps, I do
get data. Why must I run twice as long? Does it not count the first 100
timesteps? I found this consistent with running for 10,000 timesteps and so
on (I Wanted to make sure the problem persisted).

So the problem that I am finding is that in order to get averages, I
actually need to run twice as long. Can someone help me address this

This is not true. Make sure the run that you use fix ave/time starts
with 0, or multiples of 100, then you will get an output every 100
steps instead of twice as long.

I am reading a restart file. Could this cause an issue?

When I run the program with a thermo 100, I notice the steps on terminal show:

0, 0.026, 0.126 etc.

I am reading a restart file. Could this cause an issue?

Why not? Why should fix ave/time care if you read a data or a
restart? Just make sure "the run that you use fix ave/time starts
with 0, or multiples of 100"

When I run the program with a thermo 100, I notice the steps on terminal
show:

0, 0.026, 0.126 etc.

This makes no sense.

Ray

Could this perhaps have to do with minimization in the original file? I notice that the minimization (Depending on when it finishes) will finish on some timestep, and then from there on out, the output timesteps will be multiples of that step. I am not sure why this is doing that here. The script is below. I Really do not see a reason why the output values are the way they are.

#Hexagonal quartz with BKS potential
units metal
atom_style full
kspace_style pppm 1.0e-6

#Data format is read in below
read_restart …/STP/BKS_STP.restart

pair_style buck/coul/long 15
pair_coeff 1 1 1388.7730 0.36231884058 175.0000
pair_coeff 1 2 18003.7572 0.205204814926 133.5381
pair_coeff 2 2 0 .1 0

thermo 100
thermo_style custom time temp

timestep 0.001
variable volume equal vol
fix 25 all ave/time 10 10 100 v_volume
run 200

Please carefully re-read the doc page, where you will find the answers you seek.

R.

I think I found the answer I seek.

reset_timestep


Could this perhaps have to do with minimization in the original file? I notice that the minimization (Depending on when it finishes) will finish on some timestep, and then from there on out, the output timesteps will be multiples of that step. I am not sure why this is doing that here. The script is below. I Really do not see a reason why the output values are the way they are.

#Hexagonal quartz with BKS potential
units metal
atom_style full
kspace_style pppm 1.0e-6

#Data format is read in below
read_restart …/STP/BKS_STP.restart

pair_style buck/coul/long 15
pair_coeff 1 1 1388.7730 0.36231884058 175.0000
pair_coeff 1 2 18003.7572 0.205204814926 133.5381
pair_coeff 2 2 0 .1 0

thermo 100
thermo_style custom time temp

timestep 0.001
variable volume equal vol
fix 25 all ave/time 10 10 100 v_volume
run 200


On Mon, Apr 21, 2014 at 5:05 PM, Ray Shan <[email protected]…24…> wrote:
On Mon, Apr 21, 2014 at 5:02 PM, Benjamin Cowen <[email protected]…24…> wrote:
> I am reading a restart file. Could this cause an issue?

Why not? Why should fix ave/time care if you read a data or a
restart? Just make sure “the run that you use fix ave/time starts
with 0, or multiples of 100”

I am also puzzled by this behavior of all the fix ave/* . I could not understand the meaning of the line

nvalid = (update->ntimestep/nfreq)*nfreq + nfreq;

in nextvalid()

and have personally replaced it by just

nvalid = update->ntimestep + nfreq;

What is the point to want the initial timestep to be a multiple of nfreq? This is actually written nowhere in the documentation.

Anton

I am also puzzled by this behavior of all the fix ave/* . I could not
understand the meaning of the line

nvalid = (update->ntimestep/nfreq)*nfreq + nfreq;

in nextvalid()

and have personally replaced it by just

nvalid = update->ntimestep + nfreq;

What is the point to want the initial timestep to be a multiple of nfreq?
This is actually written nowhere in the documentation.

​this is so can transparently restart your runs and don't have to write out
restarts on common multiples of all of your various "nfreq" values.​

​axel.​

After Anton’s and Axel’s post, I more fully understand what was happening. I was not previously aware that the initial timestep had to be a multiple of nfrequency. This explains the behavior I was seeing.

The initial timestep does not have to be a multiple
of Nfreq. But if you specify fix ave/time 10 10 100,
and you expect output on step 100, then
you can’t start from a restart file that starts on
step 26. B/c there will be no data produced
on steps 10 or 20 to contribute to the final average.
So in that case fix ave/time will print its first
output on step 200, using output between steps
100-200 of the run.

I.e. fix ave/time makes sure it does not start its averaging
until a set of 100 steps (in this case) for which the
full set of steps will be run. It does not allow, what
someone hinted at, to start a run at step 26, and
do averaging from step 26 to 126 to produce output
on step 126.

Steve