Hello Jan-Michael,
Thank you for the reply! And thank you for the convincible proof.
Indeed in the plot you showed the msd calculated by your post-processing
program is much better than the lammps fix.
I guess you must have used shifting time origin <r(t0).r(t0+dt)> to improve
the statistics. I also suppose in lammps fix msd simply uses
fixed time origin <r(0).r(dt)> . Or I cannot understand why your result is
much better especially at large time. As you've mentioned,
the simple rdf should not be affected so much, since it's not a time
correlation function (a non- van Hove). Therefore I expect rdf
could be better produced by fix rdf, because I can set output and average
rdf at each timestep but I cannot do that often for the
trajectory output (simply because the file size would be too large). I also
expect the difference we see in your example will get
smaller if we considerably increase the simulation time. Anyway you
presented a good reason to do post-processing instead of using
the fix. And this comparison is very interesting! I think most of the users
should notice this. (You are also right, we can normally get improved
statistics for rdf by involving more image boxes if we don't really care
about the artificial periodic behavior. )
However, I don't want this specific case to enshroud the main point I
mentioned in the previous post. That is about the concept or
design of lammps data handling process. I repeat briefly here. There are
lots of useful data DURING the simulation, but we have to drop
them when output to disk file. They can be used as extra sampling points to
improve statistics if the system functions accept them as input.
We can never get the same resolution from the trajectory file for sure. In
addition,to recalculate the properties or sometimes even to reconstruct
the structure in the post-processing takes energy.
I don't mean we should
not do post-processing, but we should not waste data if the analysis is not
very cpu-eating.
Another aspect is that considering the extensibility of lammps I think more
and more fix or computes will be added by authors and users. They are
the valuables of lammps besides the engine itself. To reuse them should be
recommended in my opinion. What I can realize now is, if the fix
and computes accept a group of variables as input, the flexibility and
ability of lammps will be largely enhanced. I'm also thinking if there is
a convenient way to expose the analysis functionalities built within lammps
to end users, and the users can just call them in the input script after the
'run' command (something like 'analyze ID var-grp-ID keyword arg'). This
will amend the saying that lammps has no good post-processing tools.
(Please don't ask me where I got this say, I cannot remember, I saw
somewhere on the internet.
) I briefly looked at the source code. I found
it's not very straightforward to transfer variables to compute function of a
fix, since it's based on atom/group ID. But I'm new to lammps and
haven't fully understood the whole design of lammps. I'm sure the authors or
other advanced users could see more clearly. I'd like to see a more
powerful lammps from both development and application points of view. Just
like I've said I think lammps is distinct and versatile. However, without
those aforementioned features, you will see many competitive projects out
there.
Sorry I might have said too much. I'll keep learning lammps:)
link