Closed liwt31 closed 1 year ago
very nice. Just to note that in cv/finitet.py
and the finiteT_cv
function in mps/mpo.py
, the qn
has been designed in the form of array([[0, 1], [1, 0]])
.
very nice. Just to note that in
cv/finitet.py
and thefiniteT_cv
function inmps/mpo.py
, theqn
has been designed in the form ofarray([[0, 1], [1, 0]])
.
oh you just rewritten these two parts I mentioned above. Thanks
very nice. Just to note that in
cv/finitet.py
and thefiniteT_cv
function inmps/mpo.py
, theqn
has been designed in the form ofarray([[0, 1], [1, 0]])
.
Actually I'm not sure if the cv part is implemented correctly. The internal qn representation in cv happens to be compatible with the new implementation. It will be nice if you can run more tests and see if there are any more bugs.
Base: 85.12% // Head: 85.23% // Increases project coverage by +0.11%
:tada:
Coverage data is based on head (
897dde3
) compared to base (bac8bed
). Patch coverage: 94.80% of modified lines in pull request are covered.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
The quantum chemistry tests are sensitive to the initial guess. On my local machine, the test can pass with M=24 or more. On the CI machine, the test can pass with M=22 but not M=24. So I increase M to 30 for robustness.
The quantum chemistry tests are sensitive to the initial guess. On my local machine, the test can pass with M=24 or more. On the CI machine, the test can pass with M=22 but not M=24. So I increase M to 30 for robustness.
Will fixing a random seed be useful?
The quantum chemistry tests are sensitive to the initial guess. On my local machine, the test can pass with M=24 or more. On the CI machine, the test can pass with M=22 but not M=24. So I increase M to 30 for robustness.
Will fixing a random seed be useful?
In principle it should work but in practice it does not. I didn't delve into the problem and simply solve by increasing M
extremely good PR, the one I have been looking for many years!
extremely good PR, the one I have been looking for many years!
Thanks. The new quantum number feature is not widely tested though. It may take more effort to make it work for production-level scripts.
very nice. Just to note that in
cv/finitet.py
and thefiniteT_cv
function inmps/mpo.py
, theqn
has been designed in the form ofarray([[0, 1], [1, 0]])
.Actually I'm not sure if the cv part is implemented correctly. The internal qn representation in cv happens to be compatible with the new implementation. It will be nice if you can run more tests and see if there are any more bugs.
I also examined in cases apart from the test case in the package, I think the implementation is correct.
very nice. Just to note that in
cv/finitet.py
and thefiniteT_cv
function inmps/mpo.py
, theqn
has been designed in the form ofarray([[0, 1], [1, 0]])
.oh you just rewritten these two parts I mentioned above. Thanks
I don't think Weitang has touched these two parts. Only the zeroT cv subroutine is consistent with the current qn implementation. But not the finiteT subroutine. Maybe, the finiteT subroutine can reuse some parts of the new implementation. But they have subtle differences.
One improvement of the current PR is to generalize the current arithmetic +
(qntot = qn1 + qn2) to fulfill more general U1 symmetry.
For example in Abelian point group symmetry, the arithmetic +
is replaced with the product of irrep representation (A \times B = C). It is helpful for QC calculation of symmetry molecules.
Of course, this kind of improvement can be added in a future PR.
One improvement of the current PR is to generalize the current arithmetic + (qntot = qn1 + qn2) to fulfill more general U1 symmetry.
This is an interesting direction. How much effort we plan to invest into the implementation depends on how much we want reno to be capable of handling electronic structure problems. From my point of view, these improvements are marginal if we stick to the current MPS/MPO backend. I'd prefer first look at how to increase M to 1000 before utilizing the symmetry.
It will be a big improvement if reno can routinely handle \~40 spatial orbitals with M\~1000.
The new commit fixes the document problem in Op
and BTW enhances the __str__/__repr__
formatting of BasisSet
class
Another quick enhance to add product
method for OpSum
is included below
Quantum numbers are internally represented as
np.ndarray
. If one quantum number is used and the bond dimension is two, the quantum number at one bond has the formarray([[0], [1]])
. The old form is[0, 1]
. If two quantum numbers are used and the bond dimension is two, the quantum number at one bond has the formarray([[0, 1], [1, 0]])
. The conserved quantum number (qntot
) is also represented asnp.ndarray
.To specify multiple quantum numbers, pass in a container of integers instead of an integer as quantum number arguments when constructing
BasisSet
andOp
. The old interface for a single quantum number is not broken.The current code is only tested on ab initio Hamiltonian. Bugs for more general cases are expected but they should be easy to fix.
The PR contains a backward-incompatible change:
nexciton
in function arguments is renamed toqntot
for consistency.