Comments (18)
You can see in the Siesta code that the simple estimation of nsc
is in fact done only via max-orbital ranges and the lattice parameters. But it is often different than the simple one.
from sisl.
I agree, it would be nice to put the supercells into the placeholder that really uses them.
In this case it would be the Geometry
class.
Considerations for alternate names,
neighbour_cells
supercells
aux_cells
- others?
I kind of have a hard time going around the plurals
,neighbour_cell
only signifies one direction in this case. @tfrederiksen please chip in here as well.
from sisl.
I think of it as just a bigger cell, so I don't have a problem with removing the plural 😅
from sisl.
What about supercell_shape
? Or variants hereof: supercell_size
, supercell_range
...
from sisl.
What about
supercell_shape
? Or variants hereof:supercell_size
,supercell_range
...
Kind of like supercell_size/range/extent
, has meaning and clarity.... But still a bit long... Hmm...
from sisl.
So should this be a class in it-self, probably that would be the best thing. Since Geometry
, Grid
should use this feature.
from sisl.
Could Supercell
be a child of Lattice
with the extra info about a supercell_size
etc?
from sisl.
As @pfebrer pointed out this would still be a bit ambiguous. The supercell is intrinsically connected to some ranged property (orbital in this case) + the lattice vectors. So it is not only due to the Lattice, it is some combination of the Atom + coordinates + Lattice that results in the supercell. At least conceptually. Users may then overwrite the intrinsic supercells.
The idea that Lattice
has pbc
would be useful, but it might also be a bit problematic downstream if pbc[i] == True
but nsc[i] == 1
, what to do then?
from sisl.
The part I don't understand about SIESTA's way of handling supercells is why aren't atoms moved into the unit cell for computing neighbors. Because then computing the number of supercells needed would be much simpler, no? E.g. you would be able to tell if you need nsc > 3
just from the maxR
of your Atoms
object and if pbc=True
you could assume nsc >= 3
. So computing nsc
would then not depend on the coordinates and would be just a function of Lattice
and Atoms
.
from sisl.
The idea that Lattice has pbc would be useful, but it might also be a bit problematic downstream if pbc[i] == True but nsc[i] == 1, what to do then?
In principle a structure can be periodic even if orbitals don't overlap, no? So pbc=True, nsc=1
is not contradictory by itself. Maybe not common, but possible.
from sisl.
I guess pbc
is something that the user can decide and set to whatever they want, but nsc
is not something that the user should be able to set arbitrarily.
from sisl.
The part I don't understand about SIESTA's way of handling supercells is why aren't atoms moved into the unit cell for computing neighbors. Because then computing the number of supercells needed would be much simpler, no? E.g. you would be able to tell if you need
nsc > 3
just from themaxR
of yourAtoms
object and ifpbc=True
you could assumensc >= 3
. So computingnsc
would then not depend on the coordinates and would be just a function ofLattice
andAtoms
.
That's not entirely true. It might be for simple cells, but for some cells with angles very large/small the calculation of supercells is not merely a case of orbital ranges. Secondly, in some cases you can shrink the required supercell depending on atomic positions since their overlaps do depend on positions.
In principle a structure can be periodic even if orbitals don't overlap, no? So
pbc=True, nsc=1
is not contradictory by itself. Maybe not common, but possible.
True, ok, but what about pbc=False, nsc=3
that would be weird no... But I agree, pbc is a lattice setting (Poisson problem), nsc is an orbital range setting (matrix hoppings).
I guess
pbc
is something that the user can decide and set to whatever they want, butnsc
is not something that the user should be able to set arbitrarily.
Agreed, but manually overriding nsc
has turned out to be extremely handy when dealing with truncations of connections. :)
So it would be ideal to keep its manual setting in some form.
from sisl.
Comment for remembering: the object holding nsc
should also reference the Lattice
since a table of offsets are created based on nsc
and the internal isc_off
table.
from sisl.
Would it make sense to make nsc part of geometry
, that is the only class that has all the information.
Grid
does not use it unless an associated geometry is hosted, and lattice also doesn't need it.
from sisl.
And who will store the supercell offsets?
from sisl.
Agreed, it just becomes clunky to have a class which collects the geometry and the lattice, but then it gets stored in the geometry.
Wouldn't it be better if the geometry contained the integer offsets, and when requesting real offsets, they are calculated (very simple MM).
from sisl.
The part I don't understand about SIESTA's way of handling supercells is why aren't atoms moved into the unit cell for computing neighbors. Because then computing the number of supercells needed would be much simpler, no? E.g. you would be able to tell if you need
nsc > 3
just from themaxR
of yourAtoms
object and ifpbc=True
you could assumensc >= 3
. So computingnsc
would then not depend on the coordinates and would be just a function ofLattice
andAtoms
.
I also start to wonder about this. For instance this behaviour seems a bit odd to me:
>>> g = sisl.geom.graphene()
>>> g.xyz[0] += 10 * g.cell[0] # translate atom by multiple of lattice vector
>>> for ia in g:
... print(ia, g.close(ia, R=1.5)) # no neighbours found because nsc = [3, 3, 1]
...
0 [0]
1 [1]
>>> g.optimize_nsc(R=20)
array([35, 19, 3], dtype=int32)
>>> for ia in g:
... print(ia, g.close(ia, R=1.5))
...
0 [ 0 1947 2013 2015]
1 [ 1 1976 1978 2044]
In the first close
call no first neighbours are found (although due to periodicity there are physical neighbours). In the second call, they are found but nsc
is ridiculously large for the problem.
Thus, it seems that having atoms outside the primitive cell is prone to complications or errors.
from sisl.
Thats a current known bug in sisl... :(
My plan was to revisit this when #393 gets in (I am just too busy at the time being).
from sisl.
Related Issues (20)
- sisl.nodes warnings in tests HOT 1
- Usability suggestions -- Atom, bilayer HOT 15
- Reading wannier Hamiltonian with out '_centres.xyz' present HOT 6
- tests running with FORTRAN=OFF
- Rename `stdoutSileVASP` to `outcarSileVASP` HOT 4
- Dispatch methods does not work
- Documentation of SileBinder methods HOT 2
- Math in sisl documentation HOT 5
- Change CLI to click HOT 1
- how can i use param_circle for graphene HOT 4
- use tocartesian HOT 11
- Change neighborfinder returns to a tuple of indices and supercell indices HOT 21
- Sisl files not available in readthedocs documentation HOT 18
- Ufuncs could support external classes HOT 4
- `Geometry ` coordinates as f-contiguous array HOT 4
- Streamlining spin/index arguments on `read_grid` methods
- Writing Hamiltonian with sisl from Wannier HOT 3
- `translate2uc` should use boundary conditions (?) HOT 7
- Transport routines within the kubo approach HOT 16
- Disentangle overlap matrix and *other matrices*
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sisl.