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 <rayshan819@…24…> wrote:
On Mon, Apr 21, 2014 at 5:02 PM, Benjamin Cowen <bjcowen90@…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