Default Lattice.nsc and relation to periodic/nonperiodic directions

[tfrederiksen]

I've noticed that the default Lattice.nsc = [1, 1, 1] is obtained when reading a geometry from file (XV, CONTCAR, fdf, etc). However, this prevents a function like .translate2uc() to take effect unless one first changes nsc[i] > 1 or explicitly sets axes=True (how I came across this issue).

Suggestion: Perhaps nsc[i] = 0 should be allowed to denote a nonperiodic direction, while a value of 1 would mean periodicity (but without explicit reference to neighbour cells)? This would be consistent with the pbc-parameter written to the xyz-header (obtained from pbc = ['T' if n else 'F' for n in nsc]).

With this definition, we could simply redefine the default axes=None in translate2uc to:

-            axes = (self.lattice.nsc > 1).nonzero()[0]
+            axes = (self.lattice.nsc >= 1).nonzero()[0]

[zerothi]

So you propose that there is no pbc storage, but that nsc always refers to the perodicity >0, and otherwise it has periodicity and it determines the number of auxiliary supercells.

I like the idea. But... :)
There are quite a bit of places where nsc * X or prod(nsc) is used to calculate number of supercells. Therefore it would be more natural to have an actual pbc field that determines this.

Also, the problem is still open in #553. The nsc is a property determined by the combination of Geometry and Lattice whereas pbc is a property of the lattice it self.

I would propose:

• adding pbc to Lattice and then translate2uc and friends can use pbc. It would make sense that siesta and vasp/qe/PW-codes has pbc = True.
• solve nsc should not belong to Lattice #553, as that is the more underlying problem. The above point would not complicate nsc should not belong to Lattice #553, as far as I can see.

[tfrederiksen]

Thanks for reminding me of #553, I agree these issues are related. I guess the concept of nsc is only strictly meaningful for LCAO-type calculations, whereas a geometry is a more general concept.

[zerothi]

Thanks for reminding me of #553, I agree these issues are related. I guess the concept of nsc is only strictly meaningful for LCAO-type calculations, whereas a geometry is a more general concept.

Indeed, and that turns out to be difficult to generalize...

[tfrederiksen]

Would it be possible to associate nsc only with sparse_geometry?

[zerothi]

But I think this is more a property of the geometry and interaction ranges. For instance it may also be used for neighbour finding (which need not be used in the context of a sparse matrix).

It seems to me to belong to the geometry in conjunction with the lattice.

[zerothi]

So the question is whether we need some kind of Coordinate class #258 (somewhat related).