[ase-users] atomic numbers outside the physical range

[Jens Jørgen Mortensen]

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?

> -----
>
> 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 (`@classmethod`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).

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.fysik.dtu.dk/pipermail/ase-users/attachments/20170322/6692f9be/attachment.html>