Hello all,
I am interested in dumping individual stress components from individual interactions, particularly when using Hybrid/overlay, and also potentials with many individual component interactions present (for example granular pair_styles and lubricate pair_styles).
What would be the simplest way to go about this? Any suggestions about pieces of code to look at would be helpful. Thanks in advance.
Hello all,
I am interested in dumping individual stress components from individual
interactions, particularly when using Hybrid/overlay, and also potentials
with many individual component interactions present (for example granular
pair_styles and lubricate pair_styles).What would be the simplest way to go about this? Any suggestions about
pieces of code to look at would be helpful. Thanks in advance.
the simplest way for these kind of things would probably be to use rerun
multiple times with only the interactions of interest active. but i am not
certain whether this is compatible to granular pair styles requiring a
history.
axel.
I take it you are envisioning this as an intermediate output step and carrying a dummy dump file that I keep repopulating whenever I want to sample the virial. Then analyze with rerun on the fly?
Would it be difficult to carry additional force variables (rather than a superposition of them) and simply feed those and the pair separations to compute pressure? Of course what I have in mind would probably be a pain to integrate into every lammps update…
I take it you are envisioning this as an intermediate output step and
carrying a dummy dump file that I keep repopulating whenever I want to
sample the virial. Then analyze with rerun on the fly?
something along those lines. at the moment it would be pretty messy to do
any of this on the fly. so recording a trajectory and then computing
components from it would be the way to proceed.
Would it be difficult to carry additional force variables (rather than a
superposition of them) and simply feed those and the pair separations to
compute pressure? Of course what I have in mind would probably be a pain
to integrate into every lammps update...
yes. ...and i think it would try to address the problem from the wrong
directions. because recently multiple people have been asking about having
a more fine-grained access to intermediate data, i have been discussing
with steve to implement a mechanism that would allow to register a compute
that would have a particular function run whenever Pair::ev_tally() (and
possibly its siblings) are called. this would then allow the compute to
collect the data (e.g. force/stress per atom pair) and store it in whatever
way it wants, without having to re-write hundreds of pair styles, or - in
your case - making pair_hybrid.cpp even messier than it already is. yet, no
code has yet been written for it.
axel.
The compute pair/local command already has some of
the capability Eric is asking about. It loops over the
neighbor list, calls the pair->single() function for
each pair and can calculate distance and force components.
From that you could calculate stress tensor components
for each pair of atoms. E.g. some additional keywords
could be added to compute pair/local. The values can then be dumped
via the dump local command.
Note that pair/local can also access special quantities that
specific pair styles compute in their singe() method.
This is already the case the for the granular pair styles (see
the pair_gran doc page at the bottom) which store
the tangential force components so they can be
accessed by pair local.
I thought there was an option to allow this to
work with pair hybrid (i.e. request that pair/local access
a particular sub-style), but I’m not seeing it. I don’t think
an option for that would be hard to add.
Axel - if an enhanced compute pair/local satisfies your collaborators,
it would be simpler than adding hooks to ev_tally(). It solves
the issue of where the (large) amount of tallied data is stored
and how to output it.
Steve
Thanks for the other option Steve – I’ll take a look at how this is set up in the implementation of the granular pair styles in a bit. Would it be difficult to output the pair separation distance in vector form? (Technically with these two options I should be able to reconstruct all I need, though data intensive it is.)
Also 2 quick follow-ups: Is the ordering in pair_local vectors constructed as particle i, i+1:N -> i+1, i+2:N -> … -> N-1,N?
Are the granular pair styles the only pair styles that have P1:P4 defined, or is it every pair style exhibiting a torque component?
The way to think about this is that compute pair/local is simply a wrapper
on the single() function. Compute pair/local can output whatever you
want it to (if you add keywords), e.g. the rx,ry,rz components as a vector.
Or stress components if you can calculate what you want from the
output of the single() method. The order of output from compute pair/local
is whatever the neighbor list is. Since pair I,J can be stored by atom
I or atom J, all the neighs of atom I will not be grouped. But there is
a compute property/local which can annotate the output with the I,J values,
so the dump local file can be post-processed with that info. Note there
will be no consistency from timestep to timestep in the dump file, b/c
reneighboring may have occurred.
Compute pair/local can only process/output info that a pair style produces
in its single() method. So extra info could be added to any pair style,
but few have info beyond the args to single().
Steve