evangelistalab / qforte Goto Github PK
View Code? Open in Web Editor NEWLicense: GNU Lesser General Public License v3.0
License: GNU Lesser General Public License v3.0
Looking over the codebase, I don't see a reason why _sq_hamiltonian
exists, at least not as a class variable. We seem to only ever use it as an intermediate to construct a qubit hamiltonian. Why not just have the qubit hamiltonian as the class variable, and never save the SQ Hamiltonian?
The adapter to read a system from an external file is currently linked to molecule, despite using no molecule specific features. This should be changed to a generic system, where possible.
I'd like to ensure that the various QKD algorithms are all correct. The code is rather messy, to boot.
I'll need to do a mass cleanup to ensure that everything is working as expected.
When using DIIS, the number of gradients used is too large by a factor of two. Example:
k iteration Energy dE Nrvec ev Nrm ev* ||r||
---------------------------------------------------------------------------------------------------
1 -2.9860899165 -0.2127010021 2 234 +0.7650665850
2 -2.9917007993 -0.0056108828 4 468 +0.3189066740
3 -3.0025463635 -0.0108455643 6 702 +0.1783735372
4 -3.0121852510 -0.0096388874 8 936 +0.0756534375
5 -3.0148224454 -0.0026371944 10 1170 +0.0322852506
The VQE compute gradient function is probably incrementing Nrvec ev
, which it needs to do for scipy, but shouldn't do for DIIS algorithms. These two functionalities should be decoupled.
QForte's current orbital space technology has an occupied spatial space and a virtual spatial space. Francesco has expressed interest in:
Currently, the responsibility for this is in the quantum operator pool.
Attempts to use frozen core with QPE apparently lead to anomalous energies. @imagoulas would have further details.
We should identify the problem and fix it so that frozen orbitals can be used with QPE.
The Algorithm
class has a _tamps
member, of amplitudes, and a _pool
to represent a linear combination of the operators we're exponentiating. We don't need _tamps
if we have _pool
. Am I missing some reason for this design decision?
QForte needs to translate quantum many-body problems onto a quantum computer, and accordingly needs to deal with operators and vectors in terms of fermionic second quantized operators and in terms of qubits. In the current code, these are denoted with Sq
and Quantum
. However, Quantum
is ambiguous between we're doing quantum chemistry for quantum computers.
I favor renaming the relevant classes to Fermion
and Qubit
, for clarity.
This is a very very API-breaking change, so @nstair, please let me know when I have clearance to work on this without interrupting your work.
I have been raising value errors to prevent access to portions of the code which are not implemented or tested yet. the NotImplementedError is more appropriate.
terms
methods and functions with more specific names (#60)smart_print
should be print
.QuantumComputer
elements that are nonzero. (Nan)QuantumComputer
-> QubitComputer
/QComputer
/Computer
? (Nick)make_gate
for single qubit operators. (Francesco, see PR #83)__str__
on the C++ side to avoid having to do print(obj.str())
[want to achieve this: print(obj)
] (Francesco, see PR #84)qforte.gate('CNOT',0,0)
returns type = CNOT with target = 0, control = 0, parameter = 0 + i0 is not a valid quantum gate
in PR #83)add_gate
?add
for any (Nan, PR #88)exponentiate_single_term
to exponentiate_pauli_string
if it requires Pauli strings only (Francesco, PR #100 .Because we have DIIS-based algorithm for PQE, let's get one for VQE. I'm paranoid about whether the reason for the success of PQE over VQE in Section IIIA is due to the residual conditions or the algorithm used to achieve them.
syste/system_factory
currently takes an argument for both the system_type and the build_type. This seems unnecessary to me: it should just take one argument.
Unfortunately, this is such a major change to the QForte API that it will probably break what we reported in the paper. This will require some discussions with Francesco, probably.
Working on Apple M1 machine.
This is what I did:
[Create a complete new Python3.8 environment in Anaconda]
conda install pytest
conda install -c psi4 psi4
git clone --recurse-submodules
https://github.com/evangelistalab/qforte.git
cd gforte
python3.8 setup.py install
cd tests
pytest .
[confirmed all tests checked]
[create a new jupyter-notebook at root]
Below is what happened inside jupyter-notebook
import qforte
from qforte import *
computer = qforte.Computer(2)
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
Input In [10], in <cell line: 3>()
1 import qforte as qf
2 from qforte import *
----> 3 computer = qforte.Computer(2)
AttributeError: module 'qforte' has no attribute 'Computer'
---------------------------------------------------------------------------
Can someone help me out to use this software, or to complete the installation instructions?
After more poking around, I'm not convinced that QITE follows the same algorithm as Mario and Garnet's paper. QForte's algorithm to construct b computes it using eq. 5 of that paper, with the denominator approximate per eq. 3. As best as I can tell, that isn't what Mario and Garnet did. The b vector in their code is computed using eq. 9 of their SI. The approach of using eq. 3 and 5 of the main paper is a first order approximation to that, and in general, the two are different.
Is there a reason why we implement the eq. 3/5 strategy? I believe that eq. 9-SI is the correct one here.
There may be other issues. It'll take some time to go through them.
QForte shouldn't bundle its own versions of external libraries, but should have acceptable versions be grabbed during the build process.
Currently, the frozen_indices
keyword is only recognized by the OpenFermionMolAdapted. It isn't recognized by the Psi4MolAdapter, which blocks use of frozen core approximation for such molecules.
QForte should have documentation automatically build, like Psi4 does.
At present, the Algorithm class uses a _pool_
attribute, which represents a linear combination of fermionic second quantized operators. This is inappropriate for systems that are not fermions, or for algorithms with an operator pool for which expressing things in terms of second quantization is inconvenient. These should be replaced with an operator pool expressed solely in terms of qubit-space operators.
On my machine using the latest version of Sphinx (4.0.2) compilation of the docs via make html
in the folder /new_docs
fails. I would be curious to know if anyone else is experiencing this issue.
The error:
Running Sphinx v4.0.2
making output directory... done
WARNING: html_static_path entry '_static' does not exist
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 16 source files that are out of date
updating environment: [new config] 16 added, 0 changed, 0 removed
reading sources... [ 6%] abc/algorithm
Exception occurred:
File "/Users/fevange/miniconda3/envs/forte/lib/python3.9/site-packages/sphinx/ext/autodoc/mock.py", line 151, in mock
sys.meta_path.remove(finder)
ValueError: list.remove(x): x not in list
This seems to be an issue with the autodoc extension.
My pip setup:
Sphinx 4.0.2
sphinx-rtd-theme 0.5.2
sphinxcontrib-applehelp 1.0.2
sphinxcontrib-devhelp 1.0.2
sphinxcontrib-htmlhelp 1.0.3
sphinxcontrib-jsmath 1.0.1
sphinxcontrib-qthelp 1.0.3
sphinxcontrib-serializinghtml 1.1.4
pytest
should run on PR push.
The various MolAdapter
subclasses need to be initialized and then run. Both the initializer and runner take keyword arguments, but it isn't obvious to me when an argument should go into __init__
and when it should go into run
. Further, I can't imagine a use case for calling run
multiple times, or not immediately after __init__
. To me, these indicate that the run
functionality needs to be combined into __init__
.
@nstair, thoughts?
Add qforte to the Python Package Index (PyPI) so that the package is pip installable. This will allow us to make qforte install a little more automatic. The user shouldn't be responsible for getting OpenFermion and OpenFermionPsi4, and then they shouldn't even need to run the setup script themselves..
The AnsatzAlgorithm
class has both a _pool_obj
and a _pool
, where _pool
should just be the _pool_obj
's list. This is redundant, and _pool
should be eliminated.
_pool_obj.terms_
and _pool
... Currently de-sync'ed in PQESQOpPool
__getitem__
__len__
__iter__
_pool
with calls to _pool_obj
(using the magic methods) or _pool_obj.terms()
_pool
member of AnsatzAlgorithmFrancesco has expressed interest in generalizing the fermion operators to no longer be particle-conserving, but instead take a different number of creation and annihilation operators. This assumption is hard-coded, for example, here. There's not an immediate need to deal with non-particle-conserving operators that I'm aware of.
Old Name | New Name |
---|---|
exponentiate_pauli_string |
exp_pauli_string |
direct_op_exp_val |
expectation |
There is a comment in molecule_adapters by Nick about loading the two-electron integrals from a JSON file:
for p, q, r, s, h_pqrs in external_data['tei']['data']:
qforte_sq_hamiltonian.add(h_pqrs/4.0, [p,q], [s,r]) # only works in C1 symmetry
It is not clear why it should only work in C1, and all testing suggests it works fine with other point groups. I have ignored it in other code I've written, but am making a note of it here.
The SPQE DIIS solver and the DIIS solver in maths/optimizer.py
are near identical. They differ only in some extra variable setting they do after the end of the actual DIIS. We should determine how much of the variable setting should be synchronized between the two of them and unify the codes, to eliminate the duplication.
Some quantum computing ansatze are rigorously particle-conserving. This includes the dUCC with fermionic particle-conserving operators. Can we cast these as operations in a single Hilbert space? Using the full Fock space apparatus seems unnecessarily expensive.
At present, this is a "big picture idea" and not implementable code. The next step would be to figure out where the current code uses the fact that we have all Fock space.
QForte heavily abuses the word "terms". It's used in quantum_operator
to mean a scalar multiple of QuantumCircuit
. It's used in sq_op_pool
to mean a scalar multiple ofSqOperator
. It's used in sq_operator
to mean a scalar multiple of vacuum-normal, particle-conserving products of fermionic second quantized operators.
As a result, trying to read certain sections of the code has proven an interminable headache. The offending methods should be given more descriptive names. This is, of course, another very API-breaking change.
While there is a molecule class, several QForte algorithms are designed to work for more general systems. We can't guarantee this, because there isn't a general system class.
I need to create a class for system and confirm that everything that is supposed to work for a system, not a molecule in particular, actually does.
AnsatzAlgorithm
methods currently initialize the qubit register in the zero state and then apply a _Uprep
circuit to prepare the general reference. While this is most relevant for an actual quantum device, there's been a request from one of Scuseria's students to generalize this to allow initializing the state directly without specifying a state that constructs it. I agree with this on principle, but there are two caveats:
It's currently not possible to use a Psi4 molecule with symmetry.
When you try, for example,
mol = qforte.system.system_factory(system_type = 'molecule',
build_type = 'psi4',
basis='cc-pvdz',
mol_geometry = [('He', (0, 0, 0))],
symmetry = "c2v")
you hit
Traceback (most recent call last):
File "/Users/jonathonmisiewicz/qforte/tests/uccsd_test.py", line 113, in <module>
mol = system_factory(system_type = 'molecule',
File "/Users/jonathonmisiewicz/qforte/src/qforte/system/system_factory.py", line 46, in system_factory
return adapter(**kwargs)
File "/Users/jonathonmisiewicz/qforte/src/qforte/adapters/molecule_adapters.py", line 293, in create_psi_mol
mo_oeis = np.einsum('uj,vi,uv', C, C, mo_oeis)
File "<__array_function__ internals>", line 5, in einsum
File "/Users/jonathonmisiewicz/miniconda3/envs/p4dev/lib/python3.9/site-packages/numpy/core/einsumfunc.py", line 1350, in einsum
return c_einsum(*operands, **kwargs)
ValueError: einstein sum subscripts string contains too many subscripts for operand 0
There may be other points where using symmetry causes computation failure.
A very nice cleanup that I'll do after the qforte issue I'm currently working on cleaning:
First, instead of passing arguments to the molecule adapters explicitly, system_factory should send all of them kwargs. Now, caller-side, all three adapters take the same signature.
Second, replace the if-then structure with a dictionary that maps strings to the adapter to call. Once you have the string, read the adapter from the dictionary.
This is much less code and has much less duplication. As a further advantage, the list of allowed adapter types, which we need for the error message, can be read from the dictionary. Less code duplication!
Given Evangelista group interests, it would be very useful if we could connected QForte to an orbital optimizer (possibly one in Forte), so we can experiment with CAS-like methods.
Add python and c++ documentation using sphinx
This will allow QForte to have an internal molecule class form which useful properties can be obtained. It will be populated form via adapter classes, either OpenFermionMolAdapter or Pis4MolAdapter.
Qforte needs a manual, Optimally in Jupyter Notebook format.
For some reason, the built docs are incomplete and don't include, for example, the Molecule class.
Current code automatically runs FCI on any molecule created in Psi. This is not a sensible default to me, and should be set off.
This is a mega-issue for things that need test coverage, but we currently don't have. Setting up automatic code coverage checkers would doubtless give us more. Expect me to add to this as I go.
molecule_adapters.py
)molecule_adapters.py
)Hello guys,
I am trying to run the QForte UCCNVQE algorithm but I am trying to implement it using the Adam optimizer (as in https://pennylane.readthedocs.io/en/stable/code/api/pennylane.AdamOptimizer.html) instead of using the SciPy optimizers.
When I run this to optimize the parameter tamps
I get the following error related to the lower level C++ classes:
TypeError: add(): incompatible function arguments. The following argument types are supported:
1. (self: qforte.qforte.SQOpPool, arg0: complex, arg1: qforte.qforte.SQOperator) -> None
Invoked with: , <autograd.numpy.numpy_boxes.ArrayBox object at 0x7ff8fb9c8280>, -1.000000 ( 0^ 2 )
+1.000000 ( 2^ 0 )
As far as I am concerned, this happens because the class SQOperator can only have numbers as inputs (instead of this autograd numpy arrayboxes). Transforming this autograd numpy arrayboxes to numpy arrays seems to break the optimization process so this is not an option.
Any idea on how to make this work?
Thanks a lot.
molecular_info.py
defines many get and set methods. These should be @property
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.