[ase-users] Generalization of unit cells in ASE

Tue Dec 6 00:09:22 CET 2016

Right now if someone forgets to set the cell, GPAW (or ASAP?) would
just perform a garbage calculation.  GPAW would fail because it tries
to evaluate a projector at grid points (-8, -8, -8) which is outside
the cell.  This very commonly happens when one builds h2o from the g2
database and runs a calculation without setting the cell.  I think an
error message saying clearly that one needs to specify a cell is the
best option.  After all right now, if the calculation succeeds and the
user does not bother, then it was garbage in, garbage out as they say
:)

One could also make an automatic cell.  But that's a larger step and I
would do that "some day".

So I would say 1) and some day we can think of 3).

A complication of 3) is that if the calculation actually happens with
a well-defined cell defined by the code, then the trajectory saved
would not contain that cell, which would be extremely annoying.  Of
course the optimizer/calculator protocol could be made to deal with
this stuff but it seems complicated.  If the Atoms object is changed
dynamically (option 2), then that's a nightmare and would cause all
but the stoutest of users to instantly lose their sanity.

Best regards
Ask

2016-11-29 14:19 GMT+01:00 Jens Jørgen Mortensen <jensj at fysik.dtu.dk>:
> On 11/29/2016 11:27 AM, Jakob Schiøtz wrote:
>>
>> Hi,
>>
>> What is a reasonable behaviour for a calculator such as ASAP when it
>> encounters an Atoms object with an incomplete unit cell?
>> It could
>>
>> 1) Just give up, with a sensible error message.
>>
>> 2) Modify the atoms by creating one or more “missing” unit vectors in a
>> way that is sensible for the calculator.   Asap when running serial just
>> needs a direction if there are free boundaries in that direction.  But in
>> parallel runs it can be important for performance that the unit vector is
>> similar to the system size.
>>
>> 3) As above, but somehow store the missing vectors internally instead of
>> modifying the atoms.
>>
>> 4) Something else…
>
>
> I would recommend 3 - definitely not 1 or 2.  I think the
> Atoms.get_cell(complete=True) method call will give you what you need.
>
> Jens Jørgen
>
>
>>
>>
>> Best regards
>>
>> Jakob
>>
>>
>>> On 24 Nov 2016, at 10:43, Jens Jørgen Mortensen via ase-users
>>> <ase-users at listserv.fysik.dtu.dk> wrote:
>>>
>>> On 11/22/2016 05:53 PM, Ask Hjorth Larsen via ase-users wrote:
>>>>
>>>> Dear all
>>>>
>>>> I should remember to mention that due to the *cough* fickle minds of
>>>> the higher powers, the strategy has been changed (again), so don't
>>>> worry about nx3: The new plan is to always have 3x3 cells, but
>>>> communicate infinite directions by some vectors being zero.
>>>
>>> The new branch is here:
>>>
>>>     https://gitlab.com/ase/ase/merge_requests/352
>>>
>>> You can see a short summary of the changes here in the release notes.
>>> See the "Git master branch" section:
>>>
>>>
>>> https://gitlab.com/ase/ase/blob/f73734ab4eab0469790958f9b1928d1a8c9fbf66/doc/releasenotes.rst
>>>
>>> Please-please give it a try.  We need as many of you as possible to test
>>> it:  Do some calculations with your favorite calculator and read/write some
>>> files in you favorite I/O-format.  And run the test-suite with the
>>> calculators that you have available turned on like this:
>>>
>>>     $ python -m ase.test --calculators=abinit,nwchem,whatever
>>>
>>> Comments and questions are welcome.
>>>
>>> Jens Jørgen
>>>
>>>> (This means any function which 'trusts' the values in the cell vectors
>>>> will be liable to produce wrong results.  For example calculating an
>>>> angle between cell vectors of the default cell, or trying to normalize
>>>> one, will produce NaN)
>>>>
>>>> Meanwhile the trouble with nx3 cells was that if the cell has only one
>>>> vector [0,0,a], which is the z axis, and atoms.center() triggers
>>>> generation of the other cell vectors, then the resulting cell could
>>>> become something like [[0, 0, a], [b, 0, 0], [0, c, 0]], which is
>>>> technically correct but quite unconventional.
>>>>
>>>> Best regards
>>>> Ask
>>>>
>>>> 2016-11-02 15:23 GMT+01:00 Ask Hjorth Larsen <asklarsen at gmail.com>:
>>>>>
>>>>> Dear developers
>>>>>
>>>>> We are trying to generalize unit cells in ASE so it's possible to
>>>>> specify that the system is infinite one or more directions.  This
>>>>> improves compatibility with many codes that are not
>>>>> planewave/realspace DFT.
>>>>>
>>>>> Cell will have shape nx3, with n=0 to 3, and pbc becomes n booleans.
>>>>>
>>>>>>>> from ase import Atoms
>>>>>>>> Atoms()
>>>>>
>>>>> Atoms(symbols='', pbc=[], cell=[], positions=...)
>>>>>
>>>>> See more examples at the end.
>>>>>
>>>>> There is a WIP merge request for this:
>>>>> https://gitlab.com/ase/ase/merge_requests/321
>>>>>
>>>>> We need YOUR help to test and adapt existing calculators and IO
>>>>> formats.  Would you be able to run tests for any calculators that you
>>>>> normally use and report back?
>>>>>
>>>>> Probably it is pretty simple to fix any trouble, but not everyone has
>>>>> access to all codes (VASP licenses, banned by Gaussian, etc.)
>>>>>
>>>>> Functions in ase.build have not been changed yet, so they will
>>>>> typically yields old-style pbc/cell.
>>>>>
>>>>> To ease the transition, atoms.get_cell(complete=True) always returns a
>>>>> 3x3 cell, but with extra orthonormal vectors added as necessary.
>>>>>
>>>>> Examples:
>>>>>
>>>>> Old behaviour can be obtained like this:
>>>>>>>>
>>>>>>>> Atoms(pbc=False)
>>>>>
>>>>> Atoms(symbols='', pbc=[False, False, False], cell=[1.0, 1.0, 1.0],
>>>>> positions=...)
>>>>>
>>>>>>>> a = Atoms('H')
>>>>>>>> a.center(vacuum=3.)
>>>>>>>> print(a)
>>>>>
>>>>> Atoms(symbols='H', pbc=[False, False, False], cell=[6.0, 6.0, 6.0],
>>>>> positions=...)
>>>>>
>>>>> New options:
>>>>>>>>
>>>>>>>> Atoms(pbc=[True])
>>>>>
>>>>> Atoms(symbols='', pbc=[True], cell=[[1.0, 0.0, 0.0]], positions=...)
>>>>>>>>
>>>>>>>> Atoms(pbc=[False, True])
>>>>>
>>>>> Atoms(symbols='', pbc=[False, True], cell=[[1.0, 0.0, 0.0], [0.0, 1.0,
>>>>> 0.0]], positions=...)
>>>>>
>>>>> Specifying cell as three numbers works as before:
>>>>>>>>
>>>>>>>> Atoms(cell=[1., 2., 3.])
>>>>>
>>>>> Atoms(symbols='', pbc=[False, False, False], cell=[1.0, 2.0, 3.0],
>>>>> positions=...)
>>>>>
>>>>> But if cell is a 2D structure:
>>>>>>>>
>>>>>>>> Atoms(cell=[[1., 2., 3.]])
>>>>>
>>>>> Atoms(symbols='', pbc=[False], cell=[[1.0, 2.0, 3.0]], positions=...)
>>>>>>>>
>>>>>>>> Atoms(cell=[[2.,3.,4.], [1.,2.,3.]])
>>>>>
>>>>> Atoms(symbols='', pbc=[False, False], cell=[[2.0, 3.0, 4.0], [1.0,
>>>>> 2.0, 3.0]], positions=...)
>>>>>
>>>>> Best regards
>>>>> Ask
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --
>> Jakob Schiøtz, professor, Ph.D.
>> Department of Physics
>> Technical University of Denmark
>> DK-2800 Kongens Lyngby, Denmark
>> http://www.fysik.dtu.dk/~schiotz/
>>
>>
>>
>