Fix ave/time: bigint in fix_ave_time.cpp and a stop_args request

Hi List,

I am using the latest version of lammps (svn updated today) and I didn't
see anything in the bug fix pages about this, so here goes...

I am using the rerun_command to re-evaluate some data from a previous
LAMMPS trajectory and have come across what, for me, appears to be an
inconvenience although it may be part of a larger design plan for the
fix_ave/time_command. The default value for the variable bigint in
fix_ave/time isn't quite big enough.

I am reprocessing a trajectory file in which timestep(0)= 1,000,000. If
the rerun_inscript file specifies fix_ave/time as:

fix id group-id ave/time Nevery Nrepeat Nfreq c_1 mode arg ave arg file
filename

I get:

ERROR: Fix ave/time missed timestep (../fix_ave_time.cpp:942)

If I add "start 1000000" to the fix ave/time command, then the rerun
simulation will execute.

However, the rerun will generate the compute output specified by the
fix_ave/time (and write it to the file_filename) for the entire
trajectory (until Nfinal) even if I try to limit the rerun_command with
"start Nstart stop Nstop". With respect to this last point, is there a
way to limit fix ave/ time to stop at a specific timestep? Am I failing
to recognize a LAMMPS command other than rerun that will address this?

Thank you.

Aric

A secondary issue has arisen with the use of rerun and fix ave/time when
computing *.rdfs.

The Nevery, Nrepeat, Nfreq options behave differently depending on what
my value of timestep(0) is. For my test trajectory with timestep(0)= 0,
I can specify Nrepeat > 1 and generate output. For the trajectory with
timestep(0)= 1,000,000, I cannot use a value of Nrepeat> 1 without
receiving the following:

ERROR: Fix ave/time missed timestep (../fix_ave_time.cpp:942)

I am specifying Nevery, Nrepeat, and Nfreq as 200, 10, 2000 in both of
the rerun input scripts (my dump snapshots are every 200 timesteps).
These N* specifications for fix ave/time are consistent with the Nfreq >
(Nrepeat-1)*Nevery requirements. Is this a secondary effect of the
bigint variable?

thank you.
aric

Hi List,

I am using the latest version of lammps (svn updated today) and I didn't
see anything in the bug fix pages about this, so here goes...

I am using the rerun_command to re-evaluate some data from a previous
LAMMPS trajectory and have come across what, for me, appears to be an
inconvenience although it may be part of a larger design plan for the
fix_ave/time_command. The default value for the variable bigint in
fix_ave/time isn't quite big enough.

there is no "variable bigint". bigint is a type.

I am reprocessing a trajectory file in which timestep(0)= 1,000,000. If
the rerun_inscript file specifies fix_ave/time as:

fix id group-id ave/time Nevery Nrepeat Nfreq c_1 mode arg ave arg file
filename

I get:

ERROR: Fix ave/time missed timestep (../fix_ave_time.cpp:942)

If I add "start 1000000" to the fix ave/time command, then the rerun
simulation will execute.

However, the rerun will generate the compute output specified by the
fix_ave/time (and write it to the file_filename) for the entire
trajectory (until Nfinal) even if I try to limit the rerun_command with
"start Nstart stop Nstop". With respect to this last point, is there a
way to limit fix ave/ time to stop at a specific timestep? Am I failing
to recognize a LAMMPS command other than rerun that will address this?

your description is a big confusing and there are quite a few details
missing. can you manufacture an input based on, say, the melt example
which mimics what you are seeing without having to (re-)run a massive
trajectory. just use the set_timestep option.

you also need to let us know what kind of machine you are on (OS and
bitness) and whether you compiled with -DLAMMPS_SMALLSMALL,
-DLAMMPS_BIGBIG or -DLAMMPS_SMALLBIG (the default).

thanks,
     axel.

two more comments:

Hi List,

I am using the latest version of lammps (svn updated today) and I didn't
see anything in the bug fix pages about this, so here goes...

I am using the rerun_command to re-evaluate some data from a previous
LAMMPS trajectory and have come across what, for me, appears to be an
inconvenience although it may be part of a larger design plan for the
fix_ave/time_command. The default value for the variable bigint in
fix_ave/time isn't quite big enough.

a wraparound error due to 32-bit vs. 64-bit integer would only happen
after you have numbers 3 orders of magnitude larger, i.e.
2,147,483,648 or 2^31

I am reprocessing a trajectory file in which timestep(0)= 1,000,000. If
the rerun_inscript file specifies fix_ave/time as:

fix id group-id ave/time Nevery Nrepeat Nfreq c_1 mode arg ave arg file
filename

I get:

ERROR: Fix ave/time missed timestep (../fix_ave_time.cpp:942)

If I add "start 1000000" to the fix ave/time command, then the rerun
simulation will execute.

However, the rerun will generate the compute output specified by the
fix_ave/time (and write it to the file_filename) for the entire
trajectory (until Nfinal) even if I try to limit the rerun_command with
"start Nstart stop Nstop". With respect to this last point, is there a
way to limit fix ave/ time to stop at a specific timestep? Am I failing

you can just run for the first section with the post no option, then
unfix the fix, and then continue the run with the "pre no" option.

axel.

Thank you for your reply Axel. Sorry for the confusing description, it was a confusing error.

I have sorted it through and have determined what was amiss. I was able to re-create the error using a second example trajectory based on the melt simulation in the examples directory as you suggested in your follow-up comments. In summary, when starting from later timesteps (timestep > zero), the error arises when I use “read_data data.file” to define the simulation box and auxiliary properties that are not contained in the dump file. If the initial timestep(0)= 0, then there is no problem with using “read_data data.file”.

There is no error if I use “read_restart restart.file” to define the auxiliary system properties for the rerun command. I am not sure why this difference arises as the specific “read_data data.file” is the output from the utility “restart2data restart.file data.file” but the differences between the info in the data* and restart* files appear to be enough to produce the error.

I don’t know if you’re interested in the rest of the info, but you asked about what machines I am using and the compiler options. The error behavior was consistent on both machines that I am using [MacBook OS X 10.7 (64 bit) and Debian 7 (64 bit)] with the default -DLAMMPS_SMALLBIG compiler settings.

Thank you for your help.

Aric

Thank you for your reply Axel. Sorry for the confusing description, it was
a confusing error.

I have sorted it through and have determined what was amiss. I was able to
re-create the error using a second example trajectory based on the melt
simulation in the examples directory as you suggested in your follow-up

so where *is* that input?? without actually seeing that input we
remain like two blind people discussing colors. remember that there is
always the chance that would you describe you are doing or what you
think you are doing is not always the same as what the simulation is
doing based on the input file.

comments. In summary, when starting from later timesteps (timestep > zero),
the error arises when I use "read_data data.file" to define the simulation
box and auxiliary properties that are not contained in the dump file. If
the initial timestep(0)= 0, then there is no problem with using "read_data
data.file".

There is no error if I use "read_restart restart.file" to define the
auxiliary system properties for the rerun command. I am not sure why this
difference arises as the specific "read_data data.file" is the output from
the utility "restart2data restart.file data.file" but the differences
between the info in the data* and restart* files appear to be enough to
produce the error.

there is one very important difference between those two options.
read_data can only read information that is contained in the data file
format. that is a subset of what is stored in a restart file. so with
read_restart the current timestep is set to the value of the timestep
when the restart was written (and other global properties are
initialized to their corresponding current state). with read_data,
this is not the case. restart2data effectively discards all
information from the restart file that can not be stored in a data
file and the timestep number is one of them.

axel.

So here is that input. I’ve attached a directory with the example trajectory (based on melt) that reproduces the errors that I was experiencing. There is a “READ_ME” describing the input files and the outputs. I appear to have found a way to generate specious output with rerun(?). Even when rerun generates output with fix ave/time with a data.file and t(0)> 0, the output is not consistent with that output from a rerun that used a restart.* file to define the simulation box and the auxiliary model properties.

Thank you,
Aric

melt_ak.zip (1.98 MB)