Classes for electronic structure
This issue discusses ideas for some slightly higher-level classes in ASE, mostly for electronic structure stuff but also in general.
Most ASE calculators support just energy and forces. Recently, ASE has been gaining a lot of useful functions for handling crystal structures, k-points, and band structures. These functions mostly work on primitive arrays which is okay.
However we could provide some powerful classes to make things really neat. And then make a push for multiple calculators to support band structures and other fancy things instead of producing tuples with ndarrays, None, and so on.
What we need is probably:
-
A UnitCell object which provides access to the many cell-related functions. Thus, advanced functions of the unit cell object can be made available without 'polluting' the namespace of the Atoms class. Unfortunately we already have Atoms.cell and it is just an array. So what's a not-too-terrible way of offering a different class alongside this? Fictional examples:
atoms.unitcell.get_crystal_system()
,icell = atoms.unitcell.reciprocal()
,rcell = ase.unitcell.niggli_reduce()
. -
High-level (P)DOS objects for saving, plotting, ... (WIP by @AlTy)
-
We already have the BandStructure object
-
Perhaps a crystal system object which knows about special points, paths, and building k-points. But maybe it won't really be needed, provided the cell object can do the job well enough.
Currently the bandgap()
function works directly on a calculator [EDIT: I see now that you can also provide an eigenvalues array, so this argument is not entirely valid]. But what if you just have the energies in an array, and you want the bandgap, but you don't have a calculator? It must be possible for these 'small' utility functions to work on simple objects instead of infrastructure-heavy calculators. Hence:
- An ElectronicStructure or EnergyEigenstates object, or something like it. In general it would need to encapsulate energies, (occupations?), kpoints, kpoint weights (now it is a bit non-trivial because sometimes we have raw kpoints and sometimes we have reduced kpoints, so we should be sort of careful about how to do this). This kind of object could be produced by calculators, the Phonons class, or e.g. by the GW class in GPAW which also isn't a calculator.
Going beyond electronic structure, it would be nice to have a Phonons object that represents actual phonons, and not the current Phonons class which is both a phonon calculator as well as the things that it calculated. It should be possible to produce a Phonons object by reading something from a file which potentially comes from another program. (There are probably many other examples in ASE where an object does too many jobs, so that it cannot solve only one of them when you need just that)