[ase-users] ase Atoms methods

[Jens Jørgen Mortensen]

On Fri, 2008-09-26 at 11:27 +0200, Jens Jørgen Mortensen wrote:
> On Wed, 2008-09-24 at 10:08 +0300, Pekka Koskinen wrote:
> > Dear Jens,
> > 
> > I've sub-classed ase.Atoms, having some additional methods I've found
> > convenient. They have been convenient to use both with the
> > tight-binding code HOTBIT, as well as with GPAW (post-processing).
> > Below I list some of them, and the description of what they do. It
> > would be nice it you could consider implementing, at least some of
> > them, to ase.Atoms.
> > 
> > Suggestions:
> > ==========
> > 
> > * get_name(name) / set_name()
> > With set_name('benzene') you may give the atoms a name 'benzene'. With
> > get_name() you get it, and if it is not set, the name is by default
> > the chemical formula 'C6H6' (this would be taken by compressing the
> > list of chemical symbols). This method has been handy, e.g. for naming
> > output files for post-processing (Naming becomes automatic and
> > self-explanatory; and there is often no need to change old output
> > files for new systems.)

This could be quite useful!
 
> > * get_cell_axes()
> > I frequently need, for orthorhombic cells (which is often the case)
> > only the cell axes. These usually need to be taken from the 3x3 matrix
> > that get_cell gives (requiring one line more code). This method gives
> > only the lengths of the axes as an array.

How about atoms.get_cell().diagonal()?

> > * reduce_atoms_into_cell()
> > Move atoms so that all atoms are within the unit cell. Convenient for
> > plotting (If a non-orthorhombic minimal unit cell is more natural to
> > be used in constructing the supercell.)

I have also needed this some times, but we need a better name!

> > * get_vector(ri,rj,mic=True/False)
> > Return the vector from ri to rj, either using minimum image convention
> > or not. Both ri and rj can be integers (atom indices) or arbitrary
> > position arrays. This allows flexible measuring of distances within
> > your (periodic) cell.

+1
 
> > * get_distance(ri,rj,mic=True/False)
> > The same as the existing get_distance, but either ri or rj, or both
> > can also be position arrays, like above.

+1

> > * get_size()
> > Get the spatial extent of the atoms (cluster) in all directions; i.e.
> > array( [max(x)-min(x),max(y)-min(y),max(z)-min(z)] ). This info is
> > frequently needed in post-processing.

How about:

 atoms.positions.ptp(axis=0)

> > * get_kinetic_temperature(fixed=0)
> > Transform kinetic energy into kinetic temperature; the kinetic
> > temperature is always more informative than kinetic energy in eV's.
> > With keyword fixed, you may provide the number degrees of freedom that
> > should not contribute to kinetic temperature (i.e. T=ekin * 2 /
> > ((3*N-fixed)*kB); for example for free clusters fixed should be 6
> > (translations/rotations) ).

+0
 
> > * get_moments_of_inertia(center=None)
> > Return moments of inertia and principal axes wrt. given rotation
> > center. If center==None, return them wrt. center of mass.

+0

I think it is quite difficult to draw the line between methods to add
and not to add.  I would like some discussion of this before we take any
further action.

> > * set_array(name,a) /get_array(name)
> > General-purpose methods to store and retrieve some data related to
> > atoms. This type of method I end up missing frequently in GPAW
> > calculations. This could descent into Atom-class as well, allowing
> > e.g. 
> > set_array('Bader charge',charge_array)
> > for atom in atoms:
> >     print atom.get_property('Bader charge')

This one is more tricky.  I know Jakob Schiøtz also needs something like
this - maybe he can comment on that?

> > Some of these are 'convenience' methods, but at least I found many of
> > them to be very convenient indeed. The implementations of all of these
> > are quite easy, so I think the question is more if you want these in
> > your Atoms. Better naming is welcome.
> > 
> > I attach also the source code. The implementations are old and not
> > very elegant

The implementation is the least problem.  From now on, I would like all
additions to ASE to be followed by (or better: preceeded by):

* Good docstrings
* Tests in the test-directory
* An example of use somewhere in the manual or in a tutorial.

Only from now on ;-)

> , but I did not want to work on them too much (in case you
> > would be willing to adopt them). There are also methods related to
> > bonding information (atom connectivity) that I suggested to include to
> > ase some time ago, but I don't like the way I've done it, and there is
> > space for improvement. 
> > 
> > If you have any questions or better suggestions regarding the methods
> > above, I would be happy to discuss more.
> > 
> > Best regards,
> > Pekka
> > 
> > 
> > -- 
> > Pekka Koskinen
> > NanoScience Center
> > University of Jyväskylä
> > work/työ: +358 (0)14 260 4717
> > handy/matkap.:+358 (0)40 356 4460
> > 
> 
> _______________________________________________
> ase-users mailing list
> ase-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-users