[ase-users] Question about error in VASP calculator

Sat Jun 4 09:12:32 CEST 2022

I think you’re making it more complicated than it has to be when changing an error to a warning would suffice. VASP users who explicitly define a non-3D periodicity of the atoms object probably has a good reason for doing so.

The reason it became an issue for us is that we are working with 2D materials and their 3D precursors, keeping track of calculations using the ASE database functionality. It is convenient to define the 2D materials having PBC in two directions since we are using routines to optimize the unit cell of the 2D material and then we need to know which of the unit cell vectors to optimize. And it’s also good for identifying which materials in the database are 3D and which are 2D.

We have workarounds for all this, but which are more ad hoc than changing an error to a warning. Just my thoughts on the matter.

Best wishes,
Jonas

On 3 Jun 2022, at 19:24, Gaël Donval <gdonval at pm.me<mailto:gdonval at pm.me>> wrote:

Then we need another Atoms subclass for that (or probably a different Atoms ancestor). Ignoring attributes that are there and bear meaning is surprising (in bad sense). Just in the same way ignoring existing velocities or forces would be surprising and probably lead to mistakes. I can already see other people comming saying they don't understand why things are wrapping around when they've set pbc to False, thinking something magical might have happened.

I stand by what I said: to go from 1D or 2D to pseudo-3D, you need some sort of transformation. That transformation is not unique. There is not even a reasonable default for this. The fact that some tools provide pre-vacuumed structures does not change this (actually we should probably remove that functionality from those tools and factor that out in a function that does just that).

-------- Original Message --------
On 3 Jun 2022, 18:04, Tristan Maxson < tgmaxson at gmail.com<mailto:tgmaxson at gmail.com>> wrote:

I think the problem arises from doing something like fcc111("Pt") and getting a surface with the z-direction being non-periodic.  VASP users don't have the option to set which directions are periodic so I also agree personally that this property should more or less be ignored.  This is the sort of thing that tends to cause weird problems for new users who aren't even aware that the PBC property is there (because they don't need it since they only work in VASP for example).  It makes sense in codes which do something different with PBC set, but in codes that don't support PBC it should throw a warning rather than throwing an exception.

As a middle ground, we could make a tag on the VASP calculator of "ignore_pbc" to make it easy to write into the calculator definition that we are ignoring pbc.

Thank you,
Tristan Maxson

On Fri, Jun 3, 2022 at 11:56 AM Gaël Donval via ase-users <ase-users at listserv.fysik.dtu.dk<mailto:ase-users at listserv.fysik.dtu.dk>> wrote:
Hi both,

The reason it's like this is Vasp is using planewaves and is intrinsically 3D periodic.

There should be no reason ever to use a less-than-3D input file for use with Vasp or if that's the case, you have to specify how your less-than-3D structure must be converted to an approximately equivalent 3D one. There is *always* some amount of manual intervention involved. If that transform was unambiguous and unique, a warning might have been enough.

What I suggest instead is defining a function to explicitly transform non-pbc structures into 3D-periofic-with-vacuum ones, setting all pbcs to true. If it's not already in ASE, I would definitely be for adding something like that somewhere like in ase.geometry. It's clean, it does what you want and it does not have to break any assumption anywhere.

I also want to stress that

struct.pbc = True

is literally all you have to write if you don't care. ase.io.read might even have a pbc argument (don't quote me on this, I'm unsure).

Again, pbc is an important property and lying about them to everyone depending on the calculator is not a good idea.

Best,
Gaël

-------- Original Message --------
On 3 Jun 2022, 10:55, Petr Grigorev via ase-users < ase-users at listserv.fysik.dtu.dk<mailto:ase-users at listserv.fysik.dtu.dk>> wrote:

Hello everyone,

I oftenly use VASP in the scenario described by Jonas and would agree with him that warning would be more suitable.

Best regards,
Petr

Le ven. 3 juin 2022 à 10:02, Jonas Björk via ase-users <ase-users at listserv.fysik.dtu.dk<mailto:ase-users at listserv.fysik.dtu.dk>> a écrit :
Hi!

“Recent” versions of the VASP calculators give the following error when the Atoms object does not have periodic boundary conditions in all three directions:

ase.calculators.calculator.CalculatorSetupError: Vasp cannot handle non-periodic boundaries. Please enable all PBC, e.g. atoms.pbc=True

It seems a bit unnecessary. In some cases it is convenient to have the PBC of the Atoms object set in 1D or 2D even when performing calculations with VASP using vacuum in directions of non-periodicity, just to store information about the material’s periodicity.

To me, it seems appropriate to replace this error message with a warning.

Best wishes,
Jonas

---------------------------------------------------------------------
Jonas Björk, PhD
Senior Lecturer of Theoretical Chemistry

Materials Design Division
Department of Physics Chemistry and Biology, IFM
Linköping University
Sweden

Phone: +46 13 28 25 61
Google scholar: https://bit.ly/3GvptJQ
---------------------------------------------------------------------

_______________________________________________
ase-users mailing list
ase-users at listserv.fysik.dtu.dk<mailto: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<mailto:ase-users at listserv.fysik.dtu.dk>
https://listserv.fysik.dtu.dk/mailman/listinfo/ase-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.fysik.dtu.dk/pipermail/ase-users/attachments/20220604/88d45270/attachment-0001.htm>