[ase-users] atomic numbers outside the physical range

[Jens Jørgen Mortensen]

On 03/22/2017 03:33 PM, Gaël Donval wrote:
>> Den 21-03-2017 kl. 10:56 skrev Gaël Donval via ase-users:
>>> Hi,
>>>> On 03/01/2017 04:20 PM, Jens Jørgen Mortensen wrote:
>>>>> On 03/01/2017 01:59 PM, Noam Bernstein wrote:
>>>>>>> On Mar 1, 2017, at 4:05 AM, Jens Jørgen Mortensen
>>>>>>> <jensj at fysik.dtu.dk <mailto:jensj at fysik.dtu.dk>> wrote:
>>>>>>> Good question - I don't know.  Can xyz files have atomic
>>>>>>> numbers
>>>>>>> instead of symbols?  What file formats do you use for your
>>>>>>> calculations with Z=300 at the moment?
>>>>>>>
>>>>>> I use extxyz, which can.  Is the use of a the short symbol of
>>>>>> a
>>>>>> real
>>>>>> element for the species in xyz anything other than a
>>>>>> convention
>>>>>> anyway?
>>>>> Yes.
>>>>>
>>>>> Thanks for your input.  I'll try to write an "ASE enhancement
>>>>> proposal" describing what this could look like.  It will take
>>>>> me a
>>>>> couple of weeks as vacation is coming up for me.
>>>> Here is one possible solution:
>>>>
>>>>        https://wiki.fysik.dtu.dk/ase/development/proposals/labels.
>>>> html
>>>>
>>>> Please read it a couple of times and then we can continue the
>>>> discussion
>>>> to see if we can find a solution that works for all/most of us.
>>>>
>>>> Jens Jørgen
>>>>
>>> What would the difference between tag and label be then?
>> Tags are integers and labels are strings.  We could also include tag
>> in
>> the Kind-thing?
> Oh I see... It is a bit redundant then, but I personally don't mind.
> Tags seem like a property of a species/kind, so including them in an
> object representing such a species/kind seems the least surprising.

I've updated the proposal:

     https://wiki.fysik.dtu.dk/ase/development/proposals/labels.html
     https://gitlab.com/ase/ase/commit/57a7b73c6a

Jens Jørgen

>
>>> -----
>>>
>>> It is not clear whether or not your different kinds of `kind` are
>>> what
>>> the user provide and/or how things are represented through all the
>>> code.
>>>
>>> Assuming a "and" in the sentence above, the only single thing that
>>> I
>>> don't really like there is the incoherent interface provided by the
>>> `kind` as it is defined... I certainly don't want to check each
>>> single
>>> time which kind of `kind` I am provided with (i.e. a `str` or a
>>> `tuple`
>>> or a special `str` or a `namedtuple`)...
>>>
>>> What I propose instead is to create a `Kind` object (i.e. your last
>>> item). That object would contain multiple constructors (`@classmeth
>>> od`s
>>> ) that would create the object from any of your listed `kind`s.
>>> This
>>> way, we always provide the exact same interface while retaining the
>>> input format flexibility.
>>>
>>> As a bonus, unlike with tuples, if we ever want to add something we
>>> did
>>> not think about, it is trivially easy with the guarantee of
>>> breaking
>>> nothing (as long as the interface is unchanged).
>> Yes, I also think we should drop the tuple, but I still think the
>> simple
>> string representation would be quite convenient to have (as input).
> I agree.
>
> I suppose we could use the following approach to handle input cleanly:
>
>      https://gitlab.com/snippets/1655556
>
> (I have not run that code, so there are bugs).
>
> There is something I am still not sure about: should we put the masses,
> magnetic moments, charges and other things in there as you hinted in
> the draft? I personally don't think so as the atom object is already
> handling that and this is not really related to what a `Kind` is...
>
> That being said, little plumbing work would be needed to say "Hey ASE,
> give all `Atom` of `Kind` X in that `Atoms` a mass of 9.0."...
>
> Gaël
>
>> Jens Jørgen
>>
>>> Overall, I really like it (list-like object, new attributes and
>>> interaction with the current code included).
>>>
>>> Gaël
>>>
>>>
>>> _______________________________________________
>>> ase-users mailing list
>>> ase-users at listserv.fysik.dtu.dk
>>> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-users
>>