Introduce distance matrix
Closed this issue · 4 comments
Description
There a logical issue when computing the connectivity matrix in the case when geometry of the system is defined using the distances between atoms. Specifically, we assume that everything is connected with everything, resulting that Huckel term is computed incorrectly if only nearest neighbours affect the hopping term. The potential solution to this problem to introduce additional parameter r_xy
that corresponds to distance between atoms X, and Y.
There are 3 possible choices to define the system:
-
[('C1', 'C2', 1), ('C2', 'C3', 1), ('C3', 'C4', 1), ('C1', 'C4', 1)]
. In this case, no distance is provided, only theadjacency
matrix, it’s also calledconnectivity_matrix
. In the case of Hubbard and Huckel model it’s straightforward: we are treating connectivity as adjacency matrix. -
[('C1', 'C2', 1), ('C2', 'C3', 1), ('C3', 'C4', 1), ('C1', 'C4', 1)]
. This is the same as first case, but we want to construct the$\gamma$ matrix. User needs to provide the distance matrix. We can do this, by allowing parameterr_xy
as input of the hamiltonian. -
[('C1', 'C2', 1.5), ('C2', 'C3', 1.5), ('C3', 'C4', 1.5), ('C1', 'C4', 1.5), ('C1', 'C3', 2.12), ('C2', 'C4', 2.12)]
. This system represents pair-wise distances of the square of carbon atoms. We can clearly populate the gamma matrix, but we need to know about the adjacency. User has options:- Provide adjacency matrix (parameter
adjacency
) explicitly, and then one body term is populated using it. - Don’t provide the adjacency matrix. In this case the default behaviour is to assume that atoms, between which distance is provided, are adjacent.
- Provide adjacency matrix (parameter
API changes
- Rename
connectivity_matrix
toadjacency
. Parameterconnectivity
shouldn’t be changes - Change the logic inside the PPP hamiltonian:
- If system is provided in the form (2) and gamma is not provided, we require user to provide distance matrix
r_xy
. After that we build adjacency assuming that atoms connected as user provided in the list of tuples. At this point all of the parameters has to be given to properly build one and two body term - If system provided in the form (3) and
adjacency
is provided, then we build one body term asbeta * adjacency
. Ifadjacency is None
we assume pairs of atoms are connected, if they appear in the tuple. Once adjacency matrix is build, we can build the one body term asbeta * adjacency
, unless we have heteroatoms
- If system is provided in the form (2) and gamma is not provided, we require user to provide distance matrix
Note:
I wouldn’t expect the logic of Pariser-Parr module to change during all the above changes.
UPD:
There is a very elegant solution to this problem, that does involve changing the API of Pariser-Parr module.
Is it problematic if "everything is connected to everything". If I remember the appropriate formulas correctly, usually the values of
In theory, it shouldn't be a problem but the issue is that there is no explicit formula for computing beta that depends on distance (only the orbital overlap). This issue arose during making a demo for the rauk and ppp module.
I think the best option is to separate adjacency matrix from the distance matrix. Adjacency matrix is responsible for the Huckel term, while the distance matrix is used to build
The rest of this issue is just a discussion on how to handle cases when user provides one, but doesn't provided another.
@RichRick1 Any idea about how to deal with the zero body term?
This has been done