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.

pytest should run on PR push.

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:

1. Not all methods allow for this. In particular, PQE requires an operator pool that satisfies K^2 Phi = - Phi for each K in the pool. Obviously, this depends on reference state Phi.
2. There should be a warning that to simulate an actual quantum device, you really do need to be able to prepare your state of interest via circuit.

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.

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?

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.

TODOs

Global

• Replace the many terms methods and functions with more specific names (#60)
• Make pip package
• Standardize names of print functions. smart_print should be print.

Local

• Create a nice image that shows qubit ordering/operator ordering convention
• Support qubit-to-fermion transformations other than JW
• Add code to handle fermionic quantum computer
• Print only QuantumComputer elements that are nonzero. (Nan)
• Support frozen core and virtual for Psi4. (#62)
• Do we want to keep the Openfermion adapters? They end up going through Psi4 anyways.
• A user should be able to switch from shot-based computations to "exact" computations with a single line of code.

Changes made

Global

• Class renaming (#57)
• Shorten names, e.g., QuantumComputer -> QubitComputer/QComputer/Computer? (Nick)
• Avoid passing control gate id in make_gate for single qubit operators. (Francesco, see PR #83)
• Generalize handling of sq operators (non-particle conserving) (#58) (Jonathon)
• Implement __str__ on the C++ side to avoid having to do print(obj.str()) [want to achieve this: print(obj)] (Francesco, see PR #84)
• All external codes used in adapters should be removed as hard dependencies, only used for those specific adapters.
• Nick should revamp the reference system. We should probably just assume the HF reference for all cases.
• Pass unitary that prepares the reference state (or a reference state).(Nick)

Local

• Can we catch passing in the same qubit for control and target for two qubit operators? (there are already checks in place for this. Calling 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)
• Can we pass a list of gates to the QuantumCircuit constructor, to bypass add_gate?
• Can we support add for any (Nan, PR #88)
• Reverse printing of operators? (Nan)
• Rename 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.

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's current orbital space technology has an occupied spatial space and a virtual spatial space. Francesco has expressed interest in:

• supporting spatial symmetry (maybe useful for Renke's project?)
• having support for more spaces than just occupied and virtual
• allowing spaces with different dimensions for the alpha and beta spaces (useful for open-shell systems)

Currently, the responsibility for this is in the quantum operator pool.

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?

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.

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.

Francesco 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.

molecular_info.py defines many get and set methods. These should be @property.

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.

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.

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 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.

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.

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.

QForte shouldn't bundle its own versions of external libraries, but should have acceptable versions be grabbed during the build process.

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.

Qforte needs a manual, Optimally in Jupyter Notebook format.

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?

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.

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 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.

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.

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.

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?

Minor fixes/improvements

• Fix master
• File cleanup
• One class per c++/py file
• Make circuits via strings
• Compact printing of operators/circuits
• Change gate names/labels to match OpenFermion
• Cleanup of parameter handling to QuantumCircuit

Projects

• Forte-OpenFermion plugin
• Noise models
• Implement VQE and adaptive variants
• Implement QFFT/QPE

For some reason, the built docs are incomplete and don't include, for example, the Molecule class.

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

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!

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.

• Frozen core orbitals (in molecule_adapters.py)
• Frozen virtual orbitals (in molecule_adapters.py)

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.

• Synchronize _pool_obj.terms_ and _pool... Currently de-sync'ed in PQE
• Add magic methods to SQOpPool
  • __getitem__
  • __len__
  • __iter__
• Remove all current calls to _pool with calls to _pool_obj (using the magic methods) or _pool_obj.terms()
• Eliminate the _pool member of AnsatzAlgorithm

Current code automatically runs FCI on any molecule created in Psi. This is not a sensible default to me, and should be set off.

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.

Add python and c++ documentation using sphinx

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.