[ase-users] ase-users Digest, Vol 100, Issue 3

[Ask Hjorth Larsen]

Hi

2016-10-05 15:58 GMT+02:00 John Kitchin via ase-users
<ase-users at listserv.fysik.dtu.dk>:
>> Message: 1
>> Date: Wed, 5 Oct 2016 08:06:10 +0200
>> From: Jens J?rgen Mortensen <jensj at fysik.dtu.dk>
>> To: Ask Hjorth Larsen <asklarsen at gmail.com>,
>>       "ase-users at listserv.fysik.dtu.dk"       <ase-users at listserv.fysik.dtu.dk>
>> Subject: Re: [ase-users] 'Compatibility' of Atoms object with other
>>       codes
>> Message-ID: <479efb61-24d8-2371-8d41-87ae05824c00 at fysik.dtu.dk>
>> Content-Type: text/plain; charset="windows-1252"; format=flowed
>>
>> Den 03-10-2016 kl. 18:39 skrev Ask Hjorth Larsen via ase-users:
>>> Hello
>>>
>>> Maybe we have discussed this before, but I am not quite sure.
>>>
>>> With ASE you can call other codes, and this is never much of a problem
>>> when ASE defines what the code should do.  However, for reading data
>>> produced with other codes, the Atoms object frequently falls short on
>>> two counts:
>>>
>>>    1) The Atoms object always has a 3x3 cell, and many codes have
>>> either no cell, irregular shapes, or something else.
>>>    2) In ASE, each atom has a chemical symbol which corresponds
>>> one-to-one with an atomic number.  Many codes allows arbitrary names
>>> for species or something entirely different.
>>>
>>> I suggest somehow improving these two things.
>>>
>>> We could allow the 'cell' could be None.  This will undoubtedly be an
>>> annoyance, although only when something wrong was happening in the
>>> first place.  One could also define a boolean or something more
>>> complex to describe the cell when an array is not appropriate.
>>>
>>> An extra optional array of 'labels' could represent names when
>>> something more than the chemical symbol is necessary.  I know we
>>> already have 'tags', which are numbers.
>
> Isn't there already an info dictionary that can accommodate this?
>
> I think it is worth sketching out how this would be used. For example,
> are you sure an array is what you want for labels? Numpy arrays usually
> have just one data type in them, unless you specify the type of each
> element (and then you have to keep the order straight). A list could
> have all kinds of things in it.
>
> For example, the first result here is false because 4 is cast as a
> string.
>
> #+BEGIN_SRC python
> import numpy as np
>
> print(4 in np.array(['aa', 'b', 4]))
> print(4 in ['aa', 'b', 4])
> #+END_SRC
>
> #+RESULTS:
> :RESULTS:
> False
> True
> :END:
>
> That is an example where you might want to filter on some label
> criteria. Filtering can be done with tags pretty nicely too (although I
> always refer to
> http://kitchingroup.cheme.cmu.edu/dft-book/dft.html#orgheadline63
> Advanced Tagging) to remember how to do it!).
>
> Anyway, if labels end up being just an array or list of strings, I do not think we gain much
> over just the tags.

When slicing or otherwise manipulating an Atoms object, the functions
can never know how to handle the contents of 'info' because this is
something the user decides.  But if something is a per-atom array,
then it will be obvious what to do with it.  Therefore, if we
acknowledge that it is worth being able to label atoms, we must also
do it with a systematic mechanism.

A real-life application is if you are using the spacegroup module to
construct a system out of a list of atoms, then you want the tags and
associated information duplicated systematically (presently tags are
neglected, which is something I might fix).  Else you would have to
use a hack.  Consider a case where we have Al and Al-2, which are
distinct species.  Then we substitute Pu for Al2 so they can be
distinguished, build the crystal, and then search for the Pu atoms to
identify those that are really Al-2.

In the above example, 'tags' would work.  But nothing is as good as
being able to represent the information that many other atomistic
codes have.

Best regards
Ask