[ase-users] atomic numbers outside the physical range

[Gaël Donval]

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?

-----

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

Overall, I really like it (list-like object, new attributes and
interaction with the current code included).

Gaël
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3199 bytes
Desc: not available
URL: <http://listserv.fysik.dtu.dk/pipermail/ase-users/attachments/20170321/b60dbbf1/attachment.bin>