[ase-users] Generalization of unit cells in ASE

Tue Dec 6 10:08:29 CET 2016

On 12/06/2016 12:09 AM, Ask Hjorth Larsen wrote:
> 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).

1), 3) ???

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

:-)

Jens Jørgen

>
> 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/
>>>
>>>
>>>