Accessing atom properties as an array during run

Hi all,

I want to access unscaled atom coordinates of all atoms during a run and pass the whole array to a fix python/invoke in the same run. I need to do this multiple times and on the fly. For more efficiency, I am avoiding dump-files-route.

According to the manual, my options to access the coordinates are:

  1. compute c1 all property/atom x y z OR,

  2. fix x1 all store/state N x ()

Next part of my plan was to use fix vector:

fix vec1 all vector 10 v_x1 v_y1 v_z1
variable coords vector f_vec1

to pass ‘${coords}’—the computed array—to my python script (which would evaluate the data and send it back to the LAMMPS script).

However, from my understanding, is that the compute and store/state fixes only handle scalars, or may be vectors. But not arrays. Here lies the problem.

How does one solve this? If I must write a custom fix for this, can anyone tell me where to find more information on that?

Thanks a lot for your help,

Praneeth

Hi all,

I want to access unscaled atom coordinates of all atoms during a run and
pass the *whole* array to a fix python/invoke in the same run. I need to
do this multiple times and on the fly. For more efficiency, I am avoiding
dump-files-route.

​if you care about efficiency, do *not* ​go this route. position data is
distributed across processors, global data is not. so to follow your
strategy, you would first have to gather all data from all processors and
then broadcast it. this is *very* inefficient.

According to the manual, my options to access the coordinates are:

   1. compute c1 all property/atom x y z OR,
   2. fix x1 all store/state N x (<repeat for y and z coordinates>)

Next part of my plan was to use fix vector:

fix vec1 all vector 10 v_x1 v_y1 v_z1
variable coords vector f_vec1

to pass '${coords}'---the computed array---to my python script (which
would evaluate the data and send it back to the LAMMPS script).

However, from my understanding, is that the compute and store/state fixes
only handle scalars, or may be vectors. But not arrays. Here lies the
problem.

​store/state​ stores *per-atom* data, i.e. have atom properties distributed
with the atoms. in fact, its stored information migrates with the
corresponding atoms from processor to processor.​

How does one solve this? If I must write a custom fix for this, can anyone
tell me where to find more information on that?

​the better approach is to not collect the data and pass it to a python
function in the very complex and inefficient way, but rather pass - at best
- some global control data, but that access the per-atom data via the
LAMMPS python wrapper directly from inside the python function and do
whatever calculation you want to do in parallel.​

​axel.​

Dear Axel,

Thank you for your prompt reply. I will work on the LAMMPS python wrapper route. I do realise that passing all this data to the python function is already inefficient, and hence wanted to avoid any other messy complications with dumps.

My main intention was to build an approximate neighbour list to categorize and sort various clumps of atoms in my simulation box. I looked into prev discussions () and decided to use python scipy KDTree to implement the tasks. This is where an array of atom coordinates would be needed.

I would still prefer directly accessing the neighbour list within LAMMPS but I am apprehensive of straying away from my main research problem in the quest to write the perfect script.

Thanks again for your help,

Praneeth

Dear Axel,

Thank you for your prompt reply. I will work on the LAMMPS python wrapper
route. I do realise that passing all this data to the python function is
already inefficient, and hence wanted to avoid any other messy
complications with dumps.

My main intention was to build an approximate neighbour list to categorize
and sort various clumps of atoms in my simulation box. I looked into prev
discussions (http://lammps.sandia.gov/threads/msg13443.html) and decided
to use python scipy KDTree to implement the tasks. This is where an array
of atom coordinates would be needed.

​but that is also where you would serialize the code and kill any benefit​
from parallel processing. even more so, doing this in python - which you
can assume is about 100x slower than C++ for these kind of things - is not
really a good idea.

​there are several computes inside LAMMPS (written in C++) that use a
neighbor list to efficiently process neighbor lists, that are (efficiently)
generated by LAMMPS (cf. compute rdf, compute cluster/atom, compute
orientorder/atom, compute cna/atom).

I would still prefer directly accessing the neighbour list within LAMMPS
but I am apprehensive of straying away from my main research problem in the
quest to write the perfect script.

​by doing the massive hacks that you are describing, you are actually
making your life much harder than it needs to be and in addition, you will
slow down your simulations, too, and interfere significantly with parallel
scaling. as far as i can tell from your description, you are going to be
wasting time and effort by trying to avoid doing things "the right way(tm)".

axel.