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

[John Kitchin]

> 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.

Fair enough. the info is on the atoms, and this is a proposal to attach
labels to an atom.

>
> 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).

This should definitely be fixed.

> 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.

That is a hack for sure, and one that might not be needed if tags were
duplicated. 

>
> 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.

I do not argue with the utility of the labels! Just what the tradeoffs
in syntax are, if you get capability that isn't currently possible, or
is currently hard, and how you actually use them. Your example is also like
a filter example where you might do something like:

for atom in atoms:
    if 'Al-2' in atom.labels:
        atom.chemical_symbol = 'Pu'

It is the syntax of the second line, and what it enables that I want to
think through.

With tags it could look like:

AL_2 = 1

for atom in atoms:
    if atom.tag == AL_2:
        atom.chemical_symbol = 'Pu'

I am for the idea, I just want to see how people would try to use it
before it is implemented.


> Best regards
> Ask
>
>
> ------------------------------
>
> _______________________________________________
> ase-users mailing list
> ase-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-users
>
> End of ase-users Digest, Vol 100, Issue 5
> *****************************************


-- 
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu