[lammps-users] FW: How can I calculate the RDF for the COMs of user-defined atom-groups?

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.:slight_smile: 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.:wink: ) 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

Sorry I might have said too much. I'll keep learning lammps:)



just to give you a "heads-up" and an idea or two.

i basically agree with your premise that doing the
analysis during the run would be better for many cases,
and particularly for cases where lammps is especially
well suited: very large systems.

_however_, all of the added functionality has to be implemented
ideally in an orthogonal way (= as little as possible overlapping
functionality) and a non-obstrusive way.

for your specific problem, having access to the center of mass
of groups there are a number of issues to consider.
- it would be a bad idea to add special cases to _all_ fixes.
- instead having a way to set up dummy atoms with no interactions
  and propagate them along would be a much better solution, as it
  would allow to use all existing functionality without change and
  would isolate the code determining which is the COM info in just
  one location. this could.
- you cannot easily use groups for that, because they are limited
  to 32 (due to using bitmasks).
- in my opinion the cleanest solution would be to implement a "fix"
  to propagate the dummy atoms according to "rules", e.g. one dummy
  per center of mass of a molecule id (also a group), or something
  more complicated for as long as it can be done from within the fix.
  you would then do your normal simulation.

this is actually a nice and solvable project for somebody wanting
to learn programming lammps (and how things work altogether), so i
can only encourage you to go on.


Hi Axel,

Thank you for the explanation!

It's good to know the developers know what to improve:)
As long as users can easily deal with dummy atoms, it's a progress I think.
It's not really a matter how you implement it. Keep going in your direction.
As a user what I can and should do is to make 'trouble' to you;)

have a nice day!