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

[John Kitchin]

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



>>
>> Suggestions, protests, ...?
>
> I like both suggestions.  It will be nice to get rid of the default 
> [[1,0,0],[0,1,0],[0,0,1]] cell we have now.
>
> Jens J?rgen
>
>>
>> Best regards
>> Ask
>> _______________________________________________
>> ase-users mailing list
>> ase-users at listserv.fysik.dtu.dk
>> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-users
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 5 Oct 2016 08:29:58 +0200
> From: Michael Walter <Michael.Walter at fmf.uni-freiburg.de>
> To: Jens J?rgen Mortensen <jensj at fysik.dtu.dk>
> Cc: "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:
> 	<CA+Xf-=57J53G7Nk7tfrXgqiEpEVAC1_jXF7ab9kdjk+22px4zg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2016-10-05 8:06 GMT+02:00 Jens J?rgen Mortensen via ase-users <
> ase-users at listserv.fysik.dtu.dk>:
>
>> 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.
>>>
>>> Suggestions, protests, ...?
>>>
>>
>> I like both suggestions.  It will be nice to get rid of the default
>> [[1,0,0],[0,1,0],[0,0,1]] cell we have now.
>>
>
> I can agree also.
>
> In particular the restriction of the chemical symbols was annoying when one
> is working with eg. force fields, where different "versions" of the same
> element appear.
>
> Nevertheless flexibility always comes with the price of complexity. Maybe
> we can create a more flexible Atoms base class (eg. named Structure) and
> can keep the simpler Atoms class as it is now in addition. A "Structure"
> could then consist of virtually anything that is connected to a potential
> and/or forces.
>
> Michael
>
>
>>
>> Jens J?rgen
>>
>>
>>
>>> Best regards
>>> Ask
>>> _______________________________________________
>>> ase-users mailing list
>>> ase-users at listserv.fysik.dtu.dk
>>> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-users
>>>
>>
>> _______________________________________________
>> ase-users mailing list
>> ase-users at listserv.fysik.dtu.dk
>> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-users
>>


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