nstair / qforte Goto Github PK

Still need a general function to to apply SQOperator class to Computer class.

• add Computer::apply_sq_operaotor() to computer.cc
• add test case, compare to randomized state output using jw transformed apply_operaotr() function.
• verify test case passes

No new code required, but would be nice to have some benchmarks for applying the SQOperator directly vs using the jw transformed version for medium-large sized 'computers' (maybe 16-20 qubits). There is some example code that applies the Hamiltonian (operator) for molecular systems to a state vector found in qforte/Tutorials/3-Molecular-hamiltonains.ipynb.

Try making more than two hydrogens, i.e. change the 2 hydrogen example
geom = [('H', (0., 0., 0.0)), ('H', (0., 0., 1.50))]

to a 4 hydrogen example
geom = [
('H', (0., 0., 0.0)),
('H', (0., 0., 1.50)),
('H', (0., 0., 3.00)),
('H', (0., 0., 4.50))
]

and eventually to a 10 hydrogen example... and then see if your function for applying the Hamiltonian is faster.

*Note that the number of qubits will be twice the number of hydrogens in the above example.

We need some functions (in the c++ layer) that copy the data (and shape and strides) from a numpy array to our tensor object (and vice versa). This doens't need to be super efficient at the moment, but will be really nice for debugging and testing.

we will need tests for a wide variety of BLAS calls. As a note, BLAS functions can be organized in c-syle [row-major] (cblas) memory layout (traversing the row of a matrix is fast), OR fortran-style [column-major] (fblas), we use c-sytle memory layout for everyting so far.

Also, you may see stuff like "zaxpy" or "daxpy" or "faxpy" or "caxpy", where the first letter is acually just indicating what the core data type for the operation is (single precision real is "f" for example, double precision complex always uses a "z").

currently the BLAS headers are defined as math_<function_name> in blas_math.h, and the definitions are in blas_math.cc.

need to make sure all BLAS functions in blas_math.h:

1. Have a Tensor class implementation, (see Tensor::zaxpy as an example)
2. Are exposed to python
3. Are tested against numpy

Speed/clean up the general_transpose function (in tensor.cc). Currently the last for loop in

Tensor Tensor::general_transpose(const std::vector<size_t>& axes) const 
{
    if (axes.size() != ndim()) {
        throw std::invalid_argument("Invalid axes permutation");
    }

    std::vector<size_t> transposed_shape(ndim());
    for (size_t i = 0; i < ndim(); ++i) {
        transposed_shape[i] = shape_[axes[i]];
    }

    // std::shared_ptr<Tensor> transposed_tensor(new Tensor(transposed_shape));
    Tensor transposed_tensor(transposed_shape);

    std::complex<double>* transposed_data = transposed_tensor.data().data();
    // const std::complex<double>* original_data = data_.data();

    // This works but probably can be made more efficient.
    // Fix if it turns out to be a bottleneck
    for (size_t i = 0; i < size_; i++){
        std::vector<size_t> tidx_trans = vidx_to_tidx(i);
        size_t t_vidx = transposed_tensor.tidx_to_trans_vidx(tidx_trans, axes);
        transposed_data[t_vidx] = data_[i];
    }

    return transposed_tensor;  
}

is maybe doing too much work, if you have time and see a way to optimize then give it a try. Try to transpose a large tensor (30x30x30x30) or someting and see if it is faster.

1. Continue testing edge cases for new Tensor, SQOperator, and TensorOperator classes.

2. Make sure tests include at least 1 or 2 random cases with some of the tensor dimensions on the order of ~10-15 (biger than can be check by eye)

3. Include some cases with complex numbers (numpy arrays with complex need the specification dtype=complex128).

There is a bug in the original Jordan Wigner Transformation when the user tries to add a term containing a vector of creators that consists of 2 indices that are the same, followed by an index of 0. The exact line of code is as follows:

h3 = 1.0
sq_op.add_term(h3, [1, 1, 0], [])

In theory, applying these creators from right to left, after applying the '0', the 2 '1''s should cancel each other out and completely wipe the state vector. In the original implementation, this does not happen. This bug is most likely a result of trying to cut corners by trying to recognize that two of the same index can be ignored rather than being treated as something that would wipe the entire vector. We need to look into the Jordan Wigner Transformation implementation and figure out where this is happening and modify it accordingly.

We need a member function in SQOperator that returns a list of new SQOperators each with only 1 rank. Calling ranks_present() for any of these new operators should return a list of length one, with the only element equaling the rank of that operator.

Description

There is a bug in the add_sqop_of_rank function in the TensorOperator class that leads to incorrect behavior when using it on a Tensor Operator with odd dimensions, such as [5, 5], [3, 3], etc. It seems to work fine with even dimensions though.

Code Sample

        shape = [5, 5]

        my_tensor = qf.Tensor(shape, "My Tensor")
        imported_tensor = qf.Tensor(shape, "Imported Tensor")

        random.seed(999)

        for i in range(shape[0]):
            for j in range(shape[1]):
                rand_coeff = random.uniform(0.1, 10.0)
                my_sqop.add_term(rand_coeff, [i], [j])
                my_sqop.add_term(rand_coeff, [j], [i])

        a = np.load('zip_files/norm_test5.npz')
        data = a['data0']

        ablk1, bblk1 = my_sqop.get_largest_alfa_beta_indices()
        dim = (max(ablk1, bblk1) + 1)
        split_list = my_sqop.split_by_rank(True)

        my_operator = qf.TensorOperator(1, dim)
        imported_operator = qf.TensorOperator(1, dim)

        imported_operator.fill_tensor_from_np_by_rank(2, data.ravel(), shape)
        my_operator.add_sqop_of_rank(split_list[0], 2)

Additional Information

zip_files/norm_test5.npz is a zip file that was saved from a seperate environment with the same seed and initialization as my_sqop. Each function was tested to isolate that the issue was within add_sqop_of_rank. All data aligns as intended until that function is called.