traj file incorrect for EOS of a single atom cell systems

[marcindulak]

When performing EOS for a single atom cell the resulting traj file contains unscaled cell configurations (only the first atoms.set_cell seems to be applied). Tested against ase 3486:

import numpy as np

from ase.lattice import bulk
from ase.io import write
from ase.calculators.calculator import kpts2mp
from ase.io.trajectory import PickleTrajectory

from espresso import espresso

element = 'Na'

atoms = bulk(element, 'bcc')#, orthorhombic=True)  # two-atom cell OK!
atoms.set_pbc((1,1,1))

kpts = tuple(kpts2mp(atoms, 3.0, even=True))
calc = espresso(mode='scf', kpts=kpts, outdir=element)
atoms.set_calculator(calc)

cell = atoms.get_cell()

traj = PickleTrajectory(element + '.traj', 'w')
for x in np.linspace(0.95, 1.05, 5):
    atoms.set_cell(cell * x, scale_atoms=True)
    traj.write(atoms)

[vossjo]

Fixed in the following commit: https://github.com/vossjo/ase-espresso/commit/070806a71cdc8973d94c71b5fb79537d7df15b4f

[marcindulak]

Thanks, works for me. Incorporating the ase-espresso interface into the ASE (new interface style, see https://wiki.fysik.dtu.dk/ase/development/proposals/calculators.html) would simplify the code a lot, and offer also automatic testing (see https://ase-buildbot.fysik.dtu.dk/waterfall). ASE base calculator class implements already general checks for differences in atoms objects (an error there was the source of this bug). See e.g. check_state in https://trac.fysik.dtu.dk/projects/ase/browser/trunk/ase/calculators/calculator.py

[vossjo]

Integration into the ASE sounds like a good idea. The early versions of the espresso interface we had on our own svn are older than the new interface proposal, but I have added the parameters that calculators are supposed to support according to the proposal (e.g. kpt-density, etc.) What is your take on the dynamic binding of espresso to python which our interface performs and on special calculators we have which manage running several espresso calculators in parallel (NEB) and another that reuses KS potentials during frequency calculations? Is this going beyond what you would like to have an ASE calculator according to the proposal?

[marcindulak]

Parallel NEB is exactly something that's being discussed now http://listserv.fysik.dtu.dk/pipermail/ase-developers/2014-January/002010.html and we definitively want it for all calculators - this should be also possible for frequency calculations. Dynamic binding is also something of interest (e.g. for reusing a KS guess as you mention). Please write to ase-developers and describe the details how have you implemented these features. Espresso is a nice program and it would be good to have it accessible under a unified ASE interface, and as i mentioned have it automatically tested. Here is the original post announcing the work on the unified interface: http://listserv.fysik.dtu.dk/pipermail/ase-developers/2013-March/001732.html

[vossjo]

Thanks for the links. I'll post information about the approach used here to ase-developers soon.