theochem/ModelHamiltonian

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 the adjacency matrix, it’s also called connectivity_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 parameter r_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:
    1. Provide adjacency matrix (parameter adjacency) explicitly, and then one body term is populated using it.
    2. Don’t provide the adjacency matrix. In this case the default behaviour is to assume that atoms, between which distance is provided, are adjacent.

API changes

  1. Rename connectivity_matrix to adjacency. Parameter connectivity shouldn’t be changes
  2. Change the logic inside the PPP hamiltonian:
    1. 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
    2. If system provided in the form (3) and adjacency is provided, then we build one body term as beta * adjacency. If adjacency 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 as beta * adjacency, unless we have heteroatoms

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.

Tasks

  1. RichRick1 giovanni-br

Is it problematic if "everything is connected to everything". If I remember the appropriate formulas correctly, usually the values of $\beta$ and $\gamma$ would decay to zero when the distance is large.

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 $\gamma$ matrix, if it's not provided

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