LAMMPS python interface

Hi all - now that I’ve sorted out my basic missing package confusion, on to my real question.

Should a statement like
  np.array(lmp.gather_atoms("x",1,3))
work? On the creation of the np.array I get
  RuntimeWarning: Item size computed from the PEP 3118 buffer format string does not match the actual item size.
and then any attempt to use or print the np.array give the error
  TypeError: object of type 'float' has no len()
traced to to the line that uses the np.array.

Does anyone have any ideas as to what might be wrong? I’m using python 2.7.5 and numpy 1.7.1 (the joys of working with RedHat/CentOS and not wanting to compile your own python distribution).

            thanks,
            Noam

Hi all - now that I’ve sorted out my basic missing package confusion, on to my real question.

Should a statement like
        np.array(lmp.gather_atoms("x",1,3))
work?

it works for me on Fedora 22 / x86_64 which has python 2.7.10 and numpy 1.9.1

On the creation of the np.array I get
        RuntimeWarning: Item size computed from the PEP 3118 buffer format string does not match the actual item size.
and then any attempt to use or print the np.array give the error
        TypeError: object of type 'float' has no len()
traced to to the line that uses the np.array.

Does anyone have any ideas as to what might be wrong? I’m using python 2.7.5 and numpy 1.7.1 (the joys of working with RedHat/CentOS and not wanting to compile your own python distribution)

and which version of RHEL/CentOS would that be? on what architecture?
.

I’ll add that if you use the extract_atom()
library call it will return a pointer to the internal
LAMMPS memory storing the coordinate array
(on each processor, if running in parallel).

You should be able to get numpy to accept that
pointer and build a numpy 2d (or 1d) array
that wraps the LAMMPS internal memory directly.

The function you are using gather_atoms() will
do a copy into a C array (in addition to whatever
bumpy does).

Steve

I'll add that if you use the extract_atom()
library call it will return a pointer to the internal
LAMMPS memory storing the coordinate array
(on each processor, if running in parallel).

You should be able to get numpy to accept that
pointer and build a numpy 2d (or 1d) array
that wraps the LAMMPS internal memory directly.

Which sounds appealing, but then it’s my job to deal with the mapping of atom id’s, right?

The function you are using gather_atoms() will
do a copy into a C array (in addition to whatever
bumpy does).

For the moment I’m not that worried about the copy, if I can get it to work.

                Noam

I'll add that if you use the extract_atom()
library call it will return a pointer to the internal
LAMMPS memory storing the coordinate array
(on each processor, if running in parallel).

You should be able to get numpy to accept that
pointer and build a numpy 2d (or 1d) array
that wraps the LAMMPS internal memory directly.

a quick dig with google shows that numpy has a module to directly deal
with ctypes, either ctypes arrays or pointers:
http://docs.scipy.org/doc/numpy/reference/routines.ctypeslib.html

axel.

Hi all - now that I’ve sorted out my basic missing package confusion, on to my real question.

Should a statement like
        np.array(lmp.gather_atoms("x",1,3))
work? On the creation of the np.array I get
        RuntimeWarning: Item size computed from the PEP 3118 buffer format string does not match the actual item size.
and then any attempt to use or print the np.array give the error
        TypeError: object of type 'float' has no len()
traced to to the line that uses the np.array.

for the record, this also works for me with an installation of CentOS
6.6 (the oldest linux i have around as a virtual machine for testing)
which comes with python 2.6.6 and numpy 1.4.1.

axel.

Which sounds appealing, but then it’s my job to deal with the mapping of atom id’s, right?

correct. However if you are running on 1 proc and use atom_modify sort 0
(to turn sorting off), then atoms will remain in order (1 to N).
In parallel, you’d have to worry about atom ownership/order regardless.

Steve

Which sounds appealing, but then it’s my job to deal with the mapping of atom id’s, right?

correct. However if you are running on 1 proc and use atom_modify sort 0
(to turn sorting off), then atoms will remain in order (1 to N).

Good idea. For my small systems, sorting probably isn’t helping much anyway

In parallel, you’d have to worry about atom ownership/order regardless.

Either I’m misunderstanding this statement, or I’m misunderstanding this section of the documentation:

Gather_atoms() orders the atoms by atom ID while extract_atom() does not. (3) Gathert_atoms() returns a list of all atoms in the simulation

I expected to have to deal with local and ordering issues for extract_atom (but get the benefit of fewer copies and direct addressing of memory), but not if I do gather/scatter atoms.

Noam

yes, gather_atoms() does as you says, collecting atoms
from all procs and ordering them (hence the copy).

my comments about ordering were referring to the extract_atom()
lib function. If you use it in parallel (sorting on or off) you’d
have to worry about re-ordering yourself. E.g also
do an extract_atom() for the atom IDs.

Steve