Closed jboes closed 8 years ago
Is this a new error? i.e. one that used to work and now does not?
Jacob Boes writes:
There seems to be an error in the atom sorting process for slabs created from bulk atoms objects. The following example:
from ase.lattice.cubic import FaceCenteredCubic as fcc from ase.lattice.surface import surface from ase.constraints import FixAtoms from ase.visualize import view atoms = fcc('Cu', latticeconstant=3.7865) # Create the ground state structure at 50% Cu for j in range(1, 3): atoms[j].symbol = 'Pd' # view(atoms) atoms = surface(atoms, (1, 1, 1), 5) atoms.center(vacuum=6., axis=2) constraint = FixAtoms(mask=[atom.position[2] < 8.5 for atom in atoms]) atoms.set_constraint(constraint) # view(atoms) from jasp import * JASPRC['queue.ppn'] = 8 JASPRC['queue.walltime'] = '24:00:00' with jasp('atoms-order-problem', xc='PBE', encut=250, kpts=(3, 3, 1), ibrion=2, isif=2, nsw=40, atoms=atoms) as calc: calc.get_required_memory() calc.prepare_input_files() with jasp('atoms-order-problem') as calc: calc.calculate()
Results in the following error:
Traceback (most recent call last): File "<stdin>", line 33, in <module> File "/home-research/jboes/python/jasp/jasp/jasp.py", line 701, in __enter__ calc = Jasp(**self.kwargs) File "/home-research/jboes/python/jasp/jasp/jasp.py", line 263, in Jasp compatible_atoms_p(atoms0, atoms) File "/home-research/jboes/python/jasp/jasp/jasp.py", line 173, in compatible_atoms_p a1, a2)) Exception: Incompatible atoms. /home-research/jboes/research/tests/atoms-order-problem contains Atoms(symbols='Cu10Pd10', positions=..., cell=[[5.354919653925725, 0.0, 0.0], [-2.6774598269628624, 4.637496455524253, 0.0], [0.0, 0.0, 20.74454717714607]], pbc=[True, True, True], constraint=FixAtoms(indices=[0, 1, 2, 3, 10, 11, 12, 13])) but you passed Lattice(symbols='CuPd2Cu2Pd2Cu2Pd2Cu2Pd2Cu2Pd2Cu', positions=..., cell=[[5.354919653925725, 0.0, 0.0], [-2.6774598269628624, 4.637496455524253, 0.0], [0.0, 0.0, 20.74454717714607]], pbc=[True, True, False], constraint=FixAtoms(indices=[0, 1, 2, 3, 4, 5, 6, 7])), which is not compatible
Attempting to perform the calculation without first preparing the input files results in a calculation without correct constraints.
You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jkitchin/jasp/issues/59
Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
It's been around for a while. I've seen it a bunch of times. It has to do with the check for incompatible atoms. I haven't looked into the cause of the error, but I've found that rerunning the calculation usually fixes it. On May 3, 2016 11:33 AM, "John Kitchin" notifications@github.com wrote:
Is this a new error? i.e. one that used to work and now does not?
Jacob Boes writes:
There seems to be an error in the atom sorting process for slabs created from bulk atoms objects. The following example:
from ase.lattice.cubic import FaceCenteredCubic as fcc from ase.lattice.surface import surface from ase.constraints import FixAtoms from ase.visualize import view atoms = fcc('Cu', latticeconstant=3.7865) # Create the ground state structure at 50% Cu for j in range(1, 3): atoms[j].symbol = 'Pd' # view(atoms) atoms = surface(atoms, (1, 1, 1), 5) atoms.center(vacuum=6., axis=2) constraint = FixAtoms(mask=[atom.position[2] < 8.5 for atom in atoms]) atoms.set_constraint(constraint) # view(atoms) from jasp import * JASPRC['queue.ppn'] = 8 JASPRC['queue.walltime'] = '24:00:00' with jasp('atoms-order-problem', xc='PBE', encut=250, kpts=(3, 3, 1), ibrion=2, isif=2, nsw=40, atoms=atoms) as calc: calc.get_required_memory() calc.prepare_input_files() with jasp('atoms-order-problem') as calc: calc.calculate()
Results in the following error:
Traceback (most recent call last): File "<stdin>", line 33, in <module> File "/home-research/jboes/python/jasp/jasp/jasp.py", line 701, in __enter__ calc = Jasp(**self.kwargs) File "/home-research/jboes/python/jasp/jasp/jasp.py", line 263, in Jasp compatible_atoms_p(atoms0, atoms) File "/home-research/jboes/python/jasp/jasp/jasp.py", line 173, in compatible_atoms_p a1, a2)) Exception: Incompatible atoms. /home-research/jboes/research/tests/atoms-order-problem contains Atoms(symbols='Cu10Pd10', positions=..., cell=[[5.354919653925725, 0.0, 0.0], [-2.6774598269628624, 4.637496455524253, 0.0], [0.0, 0.0, 20.74454717714607]], pbc=[True, True, True], constraint=FixAtoms(indices=[0, 1, 2, 3, 10, 11, 12, 13])) but you passed Lattice(symbols='CuPd2Cu2Pd2Cu2Pd2Cu2Pd2Cu2Pd2Cu', positions=..., cell=[[5.354919653925725, 0.0, 0.0], [-2.6774598269628624, 4.637496455524253, 0.0], [0.0, 0.0, 20.74454717714607]], pbc=[True, True, False], constraint=FixAtoms(indices=[0, 1, 2, 3, 4, 5, 6, 7])), which is not compatible
Attempting to perform the calculation without first preparing the input files results in a calculation without correct constraints.
You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jkitchin/jasp/issues/59
Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/jkitchin/jasp/issues/59#issuecomment-216567810
It's probably a bug in incompatible atoms then. That code is kind of hacky and tries cover some gaps between reading and writing floats especially if there are 32 and 64 bit translations happening.
On Tuesday, May 3, 2016, Prateek Mehta notifications@github.com wrote:
It's been around for a while. I've seen it a bunch of times. It has to do with the check for incompatible atoms. I haven't looked into the cause of the error, but I've found that rerunning the calculation usually fixes it. On May 3, 2016 11:33 AM, "John Kitchin" <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Is this a new error? i.e. one that used to work and now does not?
Jacob Boes writes:
There seems to be an error in the atom sorting process for slabs created from bulk atoms objects. The following example:
from ase.lattice.cubic import FaceCenteredCubic as fcc from ase.lattice.surface import surface from ase.constraints import FixAtoms from ase.visualize import view atoms = fcc('Cu', latticeconstant=3.7865) # Create the ground state structure at 50% Cu for j in range(1, 3): atoms[j].symbol = 'Pd' # view(atoms) atoms = surface(atoms, (1, 1, 1), 5) atoms.center(vacuum=6., axis=2) constraint = FixAtoms(mask=[atom.position[2] < 8.5 for atom in atoms]) atoms.set_constraint(constraint) # view(atoms) from jasp import * JASPRC['queue.ppn'] = 8 JASPRC['queue.walltime'] = '24:00:00' with jasp('atoms-order-problem', xc='PBE', encut=250, kpts=(3, 3, 1), ibrion=2, isif=2, nsw=40, atoms=atoms) as calc: calc.get_required_memory() calc.prepare_input_files() with jasp('atoms-order-problem') as calc: calc.calculate()
Results in the following error:
Traceback (most recent call last): File "<stdin>", line 33, in <module> File "/home-research/jboes/python/jasp/jasp/jasp.py", line 701, in __enter__ calc = Jasp(**self.kwargs) File "/home-research/jboes/python/jasp/jasp/jasp.py", line 263, in Jasp compatible_atoms_p(atoms0, atoms) File "/home-research/jboes/python/jasp/jasp/jasp.py", line 173, in compatible_atoms_p a1, a2)) Exception: Incompatible atoms. /home-research/jboes/research/tests/atoms-order-problem contains Atoms(symbols='Cu10Pd10', positions=..., cell=[[5.354919653925725, 0.0, 0.0], [-2.6774598269628624, 4.637496455524253, 0.0], [0.0, 0.0, 20.74454717714607]], pbc=[True, True, True], constraint=FixAtoms(indices=[0, 1, 2, 3, 10, 11, 12, 13])) but you passed Lattice(symbols='CuPd2Cu2Pd2Cu2Pd2Cu2Pd2Cu2Pd2Cu', positions=..., cell=[[5.354919653925725, 0.0, 0.0], [-2.6774598269628624, 4.637496455524253, 0.0], [0.0, 0.0, 20.74454717714607]], pbc=[True, True, False], constraint=FixAtoms(indices=[0, 1, 2, 3, 4, 5, 6, 7])), which is not compatible
Attempting to perform the calculation without first preparing the input files results in a calculation without correct constraints.
You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jkitchin/jasp/issues/59
Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/jkitchin/jasp/issues/59#issuecomment-216567810
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jkitchin/jasp/issues/59#issuecomment-216570761
John
Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Same error on a checkout made pre-exception handler so this was an existing error.
Unusual that I've never seen it until now. Re-running this particular example does not solve the issue, so this may be unrelated to Prateek's previous experiences.
Mapping atom chemical symbols to a standard ASE surface has not fixed the issue as I originally thought.
This is reminiscent of the ase-sort errors which we corrected a few years ago. That's just a gut feeling at this point though.
Just to clarify, by rerunning I meant to say deleting the files and resubmitting the job.
What seems to be happening is that you are passing in,
'CuPd2Cu2Pd2Cu2Pd2Cu2Pd2Cu2Pd2Cu'
but the check for compatibility reads in
'Cu10Pd10'
and throws the error.
I've seen something similar when I have had the structure created as something like,
'MgOMgOMgOMgO' and the check reading it in as 'Mg4O4'.
It seems pretty similar to what you have, I'm not sure why deleting and resbumitting fixes it for me though.
On Tue, May 3, 2016 at 9:33 PM, Jacob Boes notifications@github.com wrote:
Same error on a checkout made pre-exception handler so this was an existing error.
Unusual that I've never seen it until now. Re-running this particular example does not solve the issue, so this may be unrelated to Prateeks previous experiences.
Mapping atom chemical symbols to a standard chemical slab has not fixed the issue as I originally thought.
This is reminiscent of the ase-sort errors which we corrected a few years ago.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jkitchin/jasp/issues/59#issuecomment-216717123
Prateek Mehta Chemical Engineering PhD Student University of Notre Dame (412) 417-0152
@Actually, what seems to be happening is that when we try to read atoms from an unsubmitted job, the error is thrown.
If I do something like below, it seems to work fine.
#+BEGIN_SRC python
from ase.lattice.cubic import FaceCenteredCubic as fcc
from ase.lattice.surface import surface
from ase.constraints import FixAtoms
from ase.visualize import view
from jasp import *
atoms = fcc('Cu', latticeconstant=3.7865)
# Create the ground state structure at 50% Cu
for j in range(1, 3):
atoms[j].symbol = 'Pd'
# view(atoms)
atoms = surface(atoms, (1, 1, 1), 5)
atoms.center(vacuum=6., axis=2)
print atoms.get_chemical_symbols()
with jasp('atoms-order-problem',
xc='PBE',
encut=250,
kpts=(1, 1, 1),
atoms=atoms) as calc:
calc.calculate()
with jasp('atoms-order-problem') as calc:
a = calc.get_atoms()
print a.get_chemical_symbols()
#+END_SRC
#+RESULTS:
: ['Cu', 'Pd', 'Pd', 'Cu', 'Cu', 'Pd', 'Pd', 'Cu', 'Cu', 'Pd', 'Pd', 'Cu', 'Cu', 'Pd', 'Pd', 'Cu', 'Cu', 'Pd', 'Pd', 'Cu']
: ['Cu', 'Pd', 'Pd', 'Cu', 'Cu', 'Pd', 'Pd', 'Cu', 'Cu', 'Pd', 'Pd', 'Cu', 'Cu', 'Pd', 'Pd', 'Cu', 'Cu', 'Pd', 'Pd', 'Cu']
My best guess is that we don't with deal sorting correctly like Jake said, while reading from an unsubmitted POSCAR.
This doesn't seem to fix the problem for me... Which version of ASE you using?
Edit: Sorting issue does not occur with ase-3.9.1.
This is likely related to the updated functionality of ase.io.read in ase-3.10.
I'm on the gitlab version from February 2. Not sure if that includes the change in ase.io.read. I tried running your code before I made the change here https://github.com/prtkm/jasp/commit/d47644aca4b69f44701052197af9d02325512311 and got the same error as you.
I got it to run without errors after the change in the PR. I think it makes sense, because if we simply do ase.io.read('POSCAR') we may not get the same sort order as the atoms we pass in.
You're probably using something other than ase-3.10
I think the example above is probably not specific to the ordering problem I'm getting. You should create a separate pull request for that fix.
The ordering error I'm struggling with isn't specific to atoms type and will happen even for very simple examples:
from jasp import *
from ase.constraints import FixAtoms
from ase.lattice.surface import fcc111
atoms = fcc111('Cu', size=(1, 1, 5), vacuum=6.0, a=3.7865)
atoms[1].symbol = 'Pd'
constraint = FixAtoms(mask=[atom.tag > 3 for atom in atoms])
atoms.set_constraint(constraint)
with jasp('temp',
xc='PBE',
encut=250,
kpts=(3, 3, 1),
ibrion=2,
isif=2,
nsw=3,
ediff=1e-2,
atoms=atoms) as calc:
calc.calculate()
This is dangerous for anyone running relaxations with constraints.
That is so strange. Do you still get an incompatible atoms error? I just pulled the latest ASE master and it still seems to be working fine for me. We might be talking about two diiferent things...
#+BEGIN_SRC python
from jasp import *
from ase.constraints import FixAtoms
from ase.lattice.surface import fcc111
from ase.visualize import view
atoms = fcc111('Cu', size=(1, 1, 5), vacuum=6.0, a=3.7865)
atoms[1].symbol = 'Pd'
constraint = FixAtoms(mask=[atom.tag > 3 for atom in atoms])
atoms.set_constraint(constraint)
JASPRC['restart_unconverged'] = False
print atoms.get_chemical_symbols()
print [atom.tag for atom in atoms]
view(atoms)
with jasp('temp',
xc='PBE',
encut=250,
kpts=(1, 1, 1),
ibrion=2,
isif=2,
nsw=3,
ediff=1e-2,
atoms=atoms) as calc:
calc.calculate()
with jasp('temp') as calc:
a = calc.get_atoms()
view(a)
print a.get_chemical_symbols()
print [atom.tag for atom in a]
#+END_SRC
#+RESULTS:
: ['Cu', 'Pd', 'Cu', 'Cu', 'Cu']
: [5, 4, 3, 2, 1]
: ['Cu', 'Pd', 'Cu', 'Cu', 'Cu']
: [5, 4, 3, 2, 1]
Edit: It seems like the constraints are in the same place
It seems something has changed, maybe with ase.io.read. The order of atoms is definitely an issue. it seems to be fixed by what Prateek did, simply resorting the atoms after they are read in. I will push a fix tomorrow.
I can confirm that the initial example runs with Prateek's fix, but the error seems to be unrelated to the problems I was experiencing.
Switching to ase-3.9.1 seems to allow me to avoid it for now and my queue time is taken so I cannot produce a better working example to re-create it for the time being.
It may be a result of some personal modifications to the ase code or have been patched since the 3.10 release since Prateek can't seem to recreate the error.
To avoid further confusion, I'm considering this closed for now pending John's fix tomorrow. I will create a separate issue if needed.
I added some resort indexes to the places in Jasp where we read atoms from the POSCAR. The errors go away with that. Could you check if the right thing is getting done? thanks.
The following test can be used for verification:
from jasp import *
from ase.lattice.cubic import FaceCenteredCubic
import os
import shutil
atoms0 = FaceCenteredCubic('Cu')
atoms0[1].symbol = 'Pd'
with jasp('calling-atoms-test',
xc='PBE',
encut=250,
kpts=(3, 3, 3),
atoms=atoms0) as calc:
calc.prepare_input_files()
# Specify the atoms object, this will raise an Exception
# if the POSCAR differs from the given atoms object.
with jasp('calling-atoms-test',
atoms=atoms0) as calc:
atoms = calc.get_atoms()
# Test that the order has not changed
if not atoms.get_chemical_symbols() == \
atoms0.get_chemical_symbols():
raise Exception('Incompatible atoms.\n'
'{0} contains {1}'
' but you passed {2}, which is not '
'compatible'.format(os.getcwd(),
atoms, atoms0))
# Do not specify the atoms object
with jasp('calling-atoms-test') as calc:
atoms = calc.get_atoms()
# Test that the order has not changed
if not atoms.get_chemical_symbols() == \
atoms0.get_chemical_symbols():
raise Exception('Incompatible atoms.\n'
'{0} contains {1}'
' but you passed {2}, which is not '
'compatible'.format(os.getcwd(),
atoms, atoms0))
# Clean up test files
shutil.rmtree('calling-atoms-test')
My original error was the result of calling from a corrupted trajectory file. ase-3.10 declares a (unnecessary?) flag requiring the atoms object to be sorted if no atoms object is explicitly passed to the xdat2traj function. This results in a second sorting which distorts the correct positions.
This is only a problem when using trajectories (i.e. jaspsum -t, MD simulation, etc...) so It's likely no one else in the group has experienced any trouble.
Here is an example which reproduces the error:
from jasp import *
from ase.constraints import FixAtoms
from ase.io import Trajectory
from ase.lattice.surface import fcc111
atoms = fcc111('Cu', size=(1, 1, 5), vacuum=6.0, a=3.7865)
atoms[1].symbol = 'Pd'
constraint = FixAtoms(mask=[atom.tag > 3 for atom in atoms])
atoms.set_constraint(constraint)
with jasp('xdat2traj-error-test',
xc='PBE',
encut=250,
kpts=(3, 3, 1),
ediff=0.01,
ibrion=2,
isif=2,
nsw=4,
atoms=atoms) as calc:
atoms = calc.get_atoms()
nrg = atoms.get_potential_energy()
xd = xdat2traj('out.traj', calc=calc)
xd.convert()
images = Trajectory('out.traj')
# Pd is fixed, so its position should not change
for i, s in enumerate(atoms.get_chemical_symbols()):
if s == 'Pd':
for j in abs(atoms[i].position - images[1][i].position):
if j > 1e-5:
raise Exception('Xdat2traj Ordering error')
Haha. I may have been the one who pushed that change into ASE. There was a problem in xdat2traj where the forces were not being mapped correctly to the atoms due to sorting issues (you may find it handy when you are training your neural nets ;).
See: https://gitlab.com/ase/ase/merge_requests/113
As far as I had tested, it seemed to be working correctly...
On Thu, May 5, 2016 at 2:37 PM, Jacob Boes notifications@github.com wrote:
My original error was the result of calling from a corrupted trajectory file. ase-3.10 declares a (unnecessary?) flag requiring the atoms object to be sorted if not atoms object is explicitly passed to the xdat2traj function. This probably results in a second sorting which distorts the correct positions
This is only a problem when using trajectories (i.e. jaspsum -t, MD simulation, etc...) so It's likely no one else in the group has experienced any trouble.
Here is an example which reproduces the error:
from jasp import *from ase.constraints import FixAtomsfrom ase.io import Trajectoryfrom ase.lattice.surface import fcc111
atoms = fcc111('Cu', size=(1, 1, 5), vacuum=6.0, a=3.7865) atoms[1].symbol = 'Pd'
constraint = FixAtoms(mask=[atom.tag > 3 for atom in atoms])atoms.set_constraint(constraint) with jasp('xdat2traj-error-test', xc='PBE', encut=250, kpts=(3, 3, 1), ediff=0.01, ibrion=2, isif=2, nsw=4, atoms=atoms) as calc:
atoms = calc.get_atoms() nrg = atoms.get_potential_energy() xd = xdat2traj('out.traj', calc=calc) xd.convert() images = Trajectory('out.traj') for i, s in enumerate(atoms.get_chemical_symbols()): if s == 'Pd': if (atoms[i].position != images[1][i].position).any(): raise Exception('Xdat2traj Ordering error')
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jkitchin/jasp/issues/59#issuecomment-217237053
Prateek Mehta Chemical Engineering PhD Student University of Notre Dame (412) 417-0152
So I ran your code, but I did an SCF, expecting nothing to change. I find that the sort order is consistent, but the positions are slightly different. It might just be a precision issue...
#+BEGIN_SRC python
from jasp import *
from ase.constraints import FixAtoms
from ase.io import Trajectory
from ase.lattice.surface import fcc111
from ase.visualize import view
atoms = fcc111('Cu', size=(1, 1, 5), vacuum=6.0, a=3.7865)
atoms[1].symbol = 'Pd'
constraint = FixAtoms(mask=[atom.tag > 3 for atom in atoms])
atoms.set_constraint(constraint)
with jasp('xdat2traj-error-test2',
xc='PBE',
encut=250,
kpts=(1, 1, 1),
ediff=0.01,
lwave=False,
lcharg=False,
atoms=atoms) as calc:
atoms = calc.get_atoms()
nrg = atoms.get_potential_energy()
#view(atoms)
xd = xdat2traj('out.traj', calc=calc)
xd.convert()
images = Trajectory('out.traj')
#view(images)
for atom in images[0]:
print atom
print
for atom in atoms:
print atom
print
for i, s in enumerate(atoms.get_chemical_symbols()):
print (atoms[i].position != images[0][i].position).any()
#+END_SRC
#+RESULTS:
#+begin_example
Atom('Cu', [2.6774598403501617, 1.545832159570578, 5.9999999382050344], index=0)
Atom('Pd', [0.0, 0.0, 8.186136867111772], index=1)
Atom('Cu', [1.338729900094132, 0.77291606819154779, 10.372273588573037], index=2)
Atom('Cu', [2.6774598403501617, 1.545832159570578, 12.558410310034303], index=3)
Atom('Cu', [0.0, 0.0, 14.74454723894104], index=4)
Atom('Cu', [0.0, 1.5458321518414171, 6.0000000000000009], tag=5, index=0)
Atom('Pd', [0.0, 0.0, 8.1861367942865186], tag=4, index=1)
Atom('Cu', [1.3387299134814405, 0.7729160759207141, 10.372273588573037], tag=3, index=2)
Atom('Cu', [2.6774598269628531, 1.5458321518414118, 12.558410382859574], tag=2, index=3)
Atom('Cu', [0.0, 0.0, 14.74454717714611], tag=1, index=4)
True
True
True
True
True
#+end_example
Looks like a combination of precision and wrapping changes.
Edited the above example to account for precision loss.
The error is actually occurring because of a bad rebase I did with ase-3.10, so there is no error to reproduce for anyone else but me...
Thanks for the help Prateek. I probably would have given up otherwise.
killing me man... ;)
There seems to be an error in the atom sorting process for slabs created from bulk atoms objects. The following example:
Results in the following error:
Attempting to perform the calculation in a single jasp call will result in a calculation without correct constraints.