Thanks for the prompt reply, Axel!
Assuming I want to extract the topology in a gather_atoms() fashion, in
which variable is this info stored? Atom info is in lmp->atom->… but where
can I find the bonds? Probably I need furthermore an nlocal counter for the
number of bonds, since the number of nlocal does not match the number of
local bonds. Maybe you know a function to which I can refer as a blueprint?
persistent bond information is stored with atoms in the atom class in
those are all per-atom arrays and may be NULL, if the atom style does
not support bonds.
compute_bond_local() uses that information to compile the local bond lists.
thus my suggestion that the approach requiring the least amount of
changes, would be to add a scalar compute function to compute
bond/local, that triggers the local compute, but also stores the
number of local bonds in a scalar number. that would not require any
changes to the library interface. you just query the compute twice
(and the result of the local compute would be cached, so it should
come at no additional cpu cost).
Since we're on the subject, how does the command extract_box() command work?
I did several approaches but was not able to extract the periodicity or
anything using this command.
are you talking about the C interface or the python wrapper?
the C interface should be obvious from the prototype and a look at library.cpp
for python, you would have to create suitably dimensioned and typed
ctype arrays and pass them as arguments.
in python/lammps.py you have:
self.lib.lammps_extract_box.argtypes = \
so you have pointers to an array of 3 doubles for boxlo, boxhi, then
pointers to 1 double for xy, xy, yx, then 3 ints for periodicity and a
pointer to a single int for box_change.
Furthermore, thanks for the hints when changing the bond topology. I plan to
use create_bonds or delete_bonds (or maybe fix bonds/create) directly from a
LAMMPS input script to build new topology and avoid the problems you’ve
mentioned. The python function should just identify atom IDs and store them
in variables for later use.
if you are working on something like this, it is probably advisable to
work off of the unstable branch from github (or bitbucket) and keep
that up-to-date with each patch release.
python support is under active development, and if you stick with an
old version, you may later have a really bad time to port it to the
latest version. doing this incrementally is usually much less effort.