[ase-users] calc.get_eigenvalues(), get_occupations()

[Ask Hjorth Larsen]

Hi!

In this MR, one can get the eigenvalue/occupations arrays by as
calc.eigenvalues and calc.occupations for some calculators:

  https://gitlab.com/ase/ase/merge_requests/518

The arrays always have the same shape (spin x kpt x nbands).  Else
scripting becomes quite tricky.

It would be good to decide whether we want this, or something else.

Best regards
Ask


2017-02-09 18:34 GMT+01:00 Gaël Donval via ase-users
<ase-users at listserv.fysik.dtu.dk>:
> Hi,
>> > >
>> > >
>> > > I'm OK with a calc.eigenvalues attribute.  The shape should then
>> > > be
>> >
>> > (spins,
>> > > k-points, bands) - right?
>> >
>> > Hmm, I actually said k-points x spins x bands.  But spins x k-
>> > points x
>> > bands is fine by me.  Is there any reason why one would be
>> > preferred?
>> >
>>
>> I would prefer  k-points x spins x bands, or even leave kpoint out in
>> case
>> of no periodic axis.
>
> I guess we have to choose:
>
> * Either use that ordering (which is fine) but don't drop any dimension
> ever;
> * or order by how common the quantity is so that a simple elimination
> rule is provided.
>
> What I mean is that if len(calc.eigenvalues.shape) == 2, you have no
> way to guess which dimension was removed: was it spins or kpoints?
>
> A rule like "it depends on your calculations: whether or not you use
> pbc and spin-polarization" would be confusing and would make our life
> excessively harder when writing new algorithms as we cannot infer
> anything from dimensions alone.
>
> A rule like: "the order is band x kpoint x spin, if len(eig.shape) ==
> 2, it is band x spin if len(eig.shape) == 1 it is band" would be more
> useful.
>
> However if we don't drop any dimension, any order would do...
>
>>
>> Best,
>> Michael
>>
>>
>> > By the way there do exist programs (Molcas) which can actually have
>> > different numbers of states for different spins.  But that feature
>> > is
>> > way too esoteric from our perspective, so we should not worry about
>> > it.
> At worse, we could make the unused states NaNs or Molcas calculator
> could provide a custom object which could be smarter...
>
> Gaël
>> >
>> > Best regards
>> > Ask
>> >
>> > >
>> > > I think we could also get away with changing
>> > > calc.get_eigenvalues() so
>> >
>> > that
>> > > it returns the whole 3-d array.  It would break some scripts out
>> > > there,
>> >
>> > buteigenvalues[10
>> > > it wouldn't be the end of the world.
>> > >
>> > > Jens Jørgen
>> > >
>> > > > Cheers,
>> > > > Gaël
>> > > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > 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
>> >
>> > _______________________________________________
>> > 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
>
> _______________________________________________
> ase-users mailing list
> ase-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/ase-users