[ase-users] Generalization of unit cells in ASE

Ask Hjorth Larsen asklarsen at gmail.com
Wed Dec 7 13:10:39 CET 2016 

2016-12-06 10:08 GMT+01:00 Jens Jørgen Mortensen <jensj at fysik.dtu.dk>:
> 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?
>
> :-)
>

Often the formatting of replies in HTML e-mails (the vertical lines
rather than ">") make it impossible for the reply-formatting function
to distinguish how the replies are nested, and they will all be nested
with one reply level (>).  This makes the whole thing an unreadable
jumble.  In this case I notice that it *did* in fact distinguish
correctly, so apologies for top-posting.  But I say this now because I
am about to write another, unavoidable top-post.

Best regards
Ask

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

More information about the ase-users mailing list