ornl-qci / tnqvm Goto Github PK

When building the latest commit from Sep 22, 2020, it tried to install itself in the default path of /usr/local/, instead of the one provided by -DXACC_DIR (-DCMAKE_INSTALL_PREFIX was necessary to correct this). Did something change in the build system that could cause this behavior? If not, this could be just a problem with the platform where I tried to install it.

Currently, this will setup a state vector of size 4 instead of 16 because the only gate operations are X 0, X 1.

Hey,

Not sure what im trying to do but would this library compile for arm processors? Think a simple program would execute in a timely manner on, say, a cell phone? ...lol. But really. :)

Thanks!

Best
Dave

@eugescu would like to say from python qreg.printBuffer() and see the wave function elements from TNQVM ITensor stuff.

I have installed MPI and gfortran(in MinGW)

Test case NumericalTester.checkDistribution failed with the following error:

#ERROR(CP-TAL:tensor_block_decompose_svd): ZGESVDX error           9
#ERROR(CP-TAL:tensor_block_decompose_svd): Error          22
#ERROR(exatn::runtime::node_executor_talsh): DECOMPOSE_SVD2: Attempt to execute the same operation twice: 
TensorOperation(9){
 D(u0,u1,u2,u3)+=Q1(u0,u1,c0)*Q2(c0,u2,u3)
 Q1{0:0,0:0,0:0}{2,2,4}
 Q2{0:0,0:0,0:0}{4,2,2}
 D{0:0,0:0,0:0,0:0}{2,2,2,2}
}

This failure is not consistent and may be related to LAPACK (used by ExaTN).
Hence, we temporarily disable the NumericalTester test while working on finding the root cause and proper fixes.

We need a top-level interface, called TNQVMVisitor, that extends AllGateVisitor, but also provides an initialize() and finalize() method.

Initializing the wavefunction tensor, and other init functionality, can go in initialize. In finalize(), I'd like to see ITensorMPSVisitor take its cbits from Measurements and add them to the AcceleratorBuffer so that users can call getMeasurements() and view the measurement results.

Then in execute() we'll wrap the InstructionIterator loop with visitor->initialize() and visitor->finalize().

I'd also like to see the tnqvm/ directory restructured to have TNQVM, TNQVMBuffer, and TNQVMVisitor classes only, and subdirectories itensor/ and exatensor/ that hold visitors specific to those types.

TNQVM does not work with Intel MKL (at least on some common systems like my Ubuntu 18.04 desktop). The runtime error is below:

tnqvm/tests/ExatnVisitorTester
[==========] Running 6 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 6 tests from ExatnVisitorTester
[ RUN ] ExatnVisitorTester.checkExatnVisitor
H(Rank:2, Volume: 4): [(0.707107,0)(0.707107,0)(0.707107,0)(-0.707107,0)]
CNOT(Rank:4, Volume: 16): [(1,0)(0,0)(0,0)(0,0)(0,0)(1,0)(0,0)(0,0)(0,0)(0,0)(0,0)(1,0)(0,0)(0,0)(1,0)(0,0)]
CNOT(Rank:4, Volume: 16): [(1,0)(0,0)(0,0)(0,0)(0,0)(1,0)(0,0)(0,0)(0,0)(0,0)(0,0)(1,0)(0,0)(0,0)(1,0)(0,0)]
Q0(Rank:1, Volume: 2): [(1,0)(0,0)]
Q1(Rank:1, Volume: 2): [(1,0)(0,0)]
Q2(Rank:1, Volume: 2): [(1,0)(0,0)]
X(Rank:2, Volume: 4): [(0,0)(1,0)(1,0)(0,0)]
H(Rank:2, Volume: 4): [(0.707107,0)(0.707107,0)(0.707107,0)(-0.707107,0)]
INTEL MKL ERROR: /home/div/intel/mkl/lib/intel64_lin/libmkl_avx2.so: undefined symbol: mkl_sparse_optimize_bsr_trsm_i8.
Intel MKL FATAL ERROR: Cannot load libmkl_avx2.so or libmkl_def.so.
Segmentation fault

So far in the ExaTensorMPSVisitor the (lazy) application of quantum gates builds the MPS wavefunction for all qubits upon first gate encounter. In future, I should restrict this build for only relevant qubits which will be acted upon during the evaluation of a circuits segment.

Unless I've missed it and its already setup that way, can we add a few extra hetmap key checks to enable users to specify key 'backend' for a desired target tnqvm visitor? I'd like to see this so that it will more easily fit into our qcor and qcor-mlir-tool workflow - qcor -qpu tnqvm:exatn-mps big_circuit.qasm for instance.

Running the following 1 qubit test program

#include "XACC.hpp"

const std::string src = R"src(__qpu__ statePrep(qbit qreg, double theta) {
    Rx(qreg[0], theta);
    Rz(qreg[0], theta);
}

// H = X_0
__qpu__ term0(qbit qreg, double theta) {
    statePrep(qreg, theta);
    cbit creg[1];
    H(qreg[0]);
    creg[0] = MeasZ(qreg[0]);
})src";

int main(int argc, char** argv) {

   // Initialize XACC - find all available
   // compilers and accelerators, parse command line.
   xacc::Initialize(argc, argv);

   auto qpu = xacc::getAccelerator("tnqvm");

   auto qubitReg = qpu->createBuffer("qreg", 1);

// Create a Program
   xacc::Program program(qpu, src);
   program.build();

   auto kernels = program.getRuntimeKernels();

   std::vector<xacc::InstructionParameter> params {1.0};

   kernels[1](qubitReg, params);

   // Finalize the framework.
   xacc::Finalize();
}

Here's the CMakeLists.txt file

# Start a CMake project
project(test-xacc-jupyter CXX)

# Set the minimum version to 3.2
cmake_minimum_required(VERSION 3.2)

# Find XACC
find_package(XACC REQUIRED)

set(CppMicroServicesConfig_DIR "${XACC_ROOT}/share/cppmicroservices3/cmake")
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${XACC_ROOT}/share/xacc")
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CppMicroServicesConfig_DIR}")
include(tests)
include(CppMicroServicesConfig)

# Find Boost
find_package(Boost COMPONENTS system program_options filesystem chrono thread REQUIRED)
include_directories(${Boost_INCLUDE_DIRS})

# Include all XACC Include Directories
include_directories(${XACC_INCLUDE_DIRS})

# Link to the XACC Library Directory,
link_directories(${XACC_LIBRARY_DIR})

# Create the executabe
add_executable(test-xacc-jupyter test-xacc-jupyter.cpp)

# Like the necessary libaries
target_link_libraries(test-xacc-jupyter ${XACC_LIBRARIES} ${Boost_LIBRARIES} dl pthread)

#0  0x00007fffef6bd19e in itensor::InfArray<itensor::IndStr<itensor::Index>, 11ul>::empty (this=0x0)
    at /projects/tnqvm-install/build/tnqvm-prefix/src/tnqvm/ITensor/itensor/util/infarray.h:345
#1  0x00007fffef6b8522 in itensor::RangeT<itensor::Index, 0ul>::empty (this=0x0)
    at /projects/tnqvm-install/build/tnqvm-prefix/src/tnqvm/ITensor/itensor/tensor/range.h:154
#2  0x00007fffef6b1b20 in itensor::IndexSetT<itensor::Index>::operator bool (this=0x0)
    at /projects/tnqvm-install/build/tnqvm-prefix/src/tnqvm/ITensor/itensor/indexset.h:90
#3  0x00007fffef6a98a0 in itensor::ITensorT<itensor::Index>::operator bool (this=0x0)
    at /projects/tnqvm-install/build/tnqvm-prefix/src/tnqvm/ITensor/itensor/itensor_interface.h:91
#4  0x00007fffef79658f in itensor::ITensorT<itensor::Index>::operator*= (this=0x7fffffff8110, R=...)
    at itensor_operators.cc:101
#5  0x00007fffef6a1e34 in itensor::operator*<itensor::Index> (A=..., B=...)
    at /projects/tnqvm-install/build/tnqvm-prefix/src/tnqvm/ITensor/itensor/itensor_interface.ih:373
#6  0x00007fffef68ecf0 in xacc::quantum::ITensorMPSVisitor::averZs(std::set<int, std::less<int>, std::allocator<int> >) () from /usr/local/xacc/lib/plugins/accelerators/libtnqvm.so
#7  0x00007fffef68fe1c in xacc::quantum::ITensorMPSVisitor::visit(xacc::quantum::Measure&) ()
   from /usr/local/xacc/lib/plugins/accelerators/libtnqvm.so
#8  0x00007ffff77e869b in void xacc::BaseInstructionVisitable::acceptImpl<xacc::quantum::Measure>(xacc::quantum::Measure&, std::shared_ptr<xacc::BaseInstructionVisitor>) () from /usr/local/xacc/lib/libxacc-quantum-gate.so
#9  0x00007ffff77e85a5 in xacc::quantum::Measure::accept(std::shared_ptr<xacc::BaseInstructionVisitor>) ()
   from /usr/local/xacc/lib/libxacc-quantum-gate.so
#10 0x00007fffef6e4405 in xacc::tnqvm::TNQVM::execute(std::shared_ptr<xacc::AcceleratorBuffer>, std::shared_ptr<xacc::Function>) () at /usr/include/c++/7/ext/new_allocator.h:136
#11 0x0000000000468006 in xacc::Kernel<>::operator()(std::shared_ptr<xacc::AcceleratorBuffer>, std::vector<boost::variant<int, double, float, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::complex<double> >, std::allocator<boost::variant<int, double, float, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::complex<double> > > >) ()
#12 0x0000000000459fa0 in main ()

For 2+ qubits, this code works.

• Calculation of the total fidelity: product of individual reconstruction fidelities, which will show the fidelity of the output tensor network (result).

• Floating-point precision, e.g., exatn-gen:float. Looks like already there, just need to register to the plugin registry.

• Information on total circuit depth printed (estimate how many cycles of reconstruction it will take)

• Each next reconstructing tensor network should be initialized not to a random value, but to the value of the previous tensor network, this should improve convergence. Random guess is not the best.

Currently ExaTENSOR computes the volume of a tensor as std::size_t, thus restricting us to 64 qubits at most. This needs to be extended. This is only needed for a formal intermediate declaration, no computations are to be done with such tensors obviously.

TN-QVM can compute reduced density matrices (RDM) for any number of qubits. We need to enable access to these quantities from XACC, something like Accelerator.getRDM(Qubits) --> const RDM &, where Qubits specifies a list of qubits for which the RDM is computed. RDMs are very useful, in particular they will allow plotting the entanglement entropy between any subset of qubits (1-body, 2-body, 3-body, etc.), so one will be able to dynamically observe the entanglement dynamics during gate application and plot a dynamic heat map how entanglement is evolving in the circuit during gate application. Would be a really cool feature for AIDE-QC.

Takes kernel file as input, outputs?

We need a general ITensor object. Possible requirements:

1. Templated on node type, ie GPU, CPU, etc
2. Operator/method for contraction
3. Truncation / SVD
4. Reshape - combine indices, separate indices
5. Swap axes

Need to be able to provide a custom visitor that provides ITensor data for modular exponentiation.

I am observing that the following code does not converge to the correct energy, while it does with the qpp accelerator

import xacc
xacc.qasm('''
.compiler xasm
.circuit ansatz
.parameters theta
.qbit q
U(q[0], 3.14159,-1.5708,1.5708);
U(q[2], 3.14159,-1.5708,1.5708);
U(q[0], 1.5708,-1.5708,1.5708);
U(q[1], 1.5708,0,3.14159);
U(q[2], 1.5708,0,3.14159);
U(q[3], 1.5708,0,3.14159);
CNOT(q[0], q[1]);
CNOT(q[1], q[2]);
CNOT(q[2], q[3]);
Rz(q[3], theta);
CNOT(q[2], q[3]);
CNOT(q[1], q[2]);
CNOT(q[0], q[1]);
U(q[0], 1.5708,1.5708,4.71239);
U(q[1], 1.5708,0,3.14159);
U(q[2], 1.5708,0,3.14159);
U(q[3], 1.5708,0,3.14159);
''')
ansatz = xacc.getCompiled('ansatz')

qpu = xacc.getAccelerator('tnqvm')
buffer = xacc.qalloc(4)
geom = '''
Na  0.000000   0.0      0.0
H   0.0        0.0  1.914388
'''
fo = [0, 1, 2, 3, 4, 10, 11, 12, 13, 14]
ao = [5, 9, 15, 19]
H = xacc.getObservable('pyscf', {'basis': 'sto-3g', 'geometry': geom,
                                       'frozen-spin-orbitals': fo, 'active-spin-orbitals': ao})
opt = xacc.getOptimizer('nlopt')
vqe = xacc.getAlgorithm('vqe', {
                        'ansatz': ansatz,
                        'accelerator': qpu,
                        'observable': H,
                        'optimizer': opt
                        })
xacc.set_verbose(True)
vqe.execute(buffer)
print('Energy = ', buffer['opt-val'])
print('Opt Angles = ', buffer['opt-params'])

We need to improve the way we generate measurement samples with the ITensor MPS visitor.

We need to hook this into the AcceleratorBuffer.getMeasurementStrings or just getMeasurements. Basically we should add the bit string to the existing boost::dynamic_bitset<>

Looking at the definition for CZBody...it looks like a duplicate of CNBody at L108.

It would be very convenient to have TNQVM_BUILD_TESTS and TNQVM_BUILD_EXAMPLES TRUE by default because it is really easy to forget adding these to the CMAKE configuration command whereas TESTS and EXAMPLES are needed in 99% of cases.

Previously, XACC's noise model API was designed specifically for TNQVM, e.g. limiting to 1-site channels.

We have updated the XACC noise model to be more generic while keeping the deprecated API for TNQVM only.
Hence, we need to update the TNQVM purified-mps simulator to use the new API and then remove the deprecated one in XACC.

Currently, the purified-mps simulator cannot handle 2-site channels (e.g. the one associated w/ CNOT gates); so we need to figure out a way to handle that in TNQVM.

The TN-QVM exatn-gen simulator is still trying to allocate the full wavefunction tensor somewhere after the reconstruction has finished (only a single bit-string was requested in this case).

TN-QVM should be enhanced to compute the density matrix of a noisy quantum circuit, |Psi><Psi|. The implementation will be very similar to the wavefunction computation. The initial state will consist of 2N 1-body qubit tensors in |0> state, instead of N, that is |0000><0000|. The gates will be applied to both |Psi> and <Psi|. Additionally, after each gate application the corresponding Krauss tensor (1-body, 2-body, etc.) will be inserted between |Psi> and <Psi|. The resulting tensor network will be submitted to ExaTN for evaluation. Additionally, one may want to compute only a slice of the density matrix or individual amplitudes, absolutely analogously to the corresponding wavefunction features. And, of course, we need to be able to compute expectation values of operators via tracing the density matrix with the operator. This will enable noise modelling with an arbitrary rank of correlations (1-body gate noise, 2-body gate noise, etc). And read-out noise (which is currently done via an XACC decorator?).

Currently, we only use the slicing method to handle many-qubit exp-val calculation in the exatn visitor.

The double-depth method is implemented but can only be used by custom API (observableExpValCalc)

Need to add a configuration to select b/w the two methods if needed.

By running a small code snippet shown below I noticed that TNQVM initializes/finalizes ExaTN server upon each expectation value calculation, which of course introduces additional overhead. The TNQVM-ExaTN visitor should only be initialized once when we create it (getAccelerator) and then finalized at the very end, when we finalize XACC. Currently, it looks like ExaTN is initialized every time we instantiate/execute a circuit inside the loop, that's not right.

===============================================================
#include "xacc.hpp"

int main(int argc, char** argv) {

//Initialize the XACC runtime:
xacc::Initialize(argc, argv);

//Choose the desired quantum accelerator:
//auto qpu = xacc::getAccelerator("tnqvm");//, {std::make_pair("tnqvm-visitor", "exatn")});
auto qpu = xacc::getAccelerator("tnqvm", {std::make_pair("tnqvm-visitor", "exatn")});

//Choose the desired quantum programming language:
auto xasmCompiler = xacc::getCompiler("xasm");

//Compile a quantum kernel into the quantum IR:
auto ir = xasmCompiler->compile(
R"(qpu void ansatz(qbit q, double theta) {
X(q[0]);
Ry(q[1], theta);
CX(q[1], q[0]);
H(q[0]);
H(q[1]);
Measure(q[0]);
Measure(q[1]);
})", qpu);

//Get the generated parameterized quantum circuit:
auto circuit = ir->getComposite("ansatz");

//Perform quantum/classical computation:
auto angles = xacc::linspace(-3.1415, 3.1415, 20);
for (auto & a : angles) {
auto evaled = (*circuit)({a});
auto qubits = xacc::qalloc(2);
qpu->execute(qubits, evaled);
auto exp_val = qubits->getExpectationValueZ();
std::cout << "(" << a << ") = " << exp_val << "\n";
}

//Finalize the XACC runtime:
xacc::Finalize();
}

The exaTN-Gen visitor to support two modes:

• option for a reconstruct_gates: current behavior

• option reconstruct_layers: counting layers (gates acting on disjoint subsets of qubits).

Currently, the visitor only supports reconstruction by 2-body gate counting.

The following circuit ansatz (rz evaled at optimal param)

U(1.5708,0,3.14159) q1
U(1.5708,1.5708,4.71239) q0
CNOT q0,q1
U(1.5708,-3.14159,3.14159) q2
CNOT q1,q1
U(1.5708,0,3.14159) q3
CNOT q2,q3
Rz(0.101476) q3
CNOT q2,q3
CNOT q1,q2
CNOT q0,q1
U(1.5708,0,3.14159) q3
U(1.5708,0,3.14159) q2
U(1.5708,1.5708,4.71239) q0
U(1.5708,0,3.14159) q1

produces the incorrect energy for the operator

H = createOperator('pyscf', {'basis': 'sto-3g', 'geometry': '''
Na  0.000000   0.0      0.0
H   0.0        0.0  1.914388
''', 'frozen-spin-orbitals': [0, 1, 2, 3, 4, 10, 11, 12, 13, 14], 'active-spin-orbitals': [5, 9, 15, 19]})

using the Itensor MPS TNQVM backend. The ExaTN backend produces the correct result, as well as aer and qpp.

We need to introduce the Dry Run feature in XACC/TN-QVM. I believe Thien has already done this in TN-QVM for the direct quantum circuit contraction. The goal is to be able to get the Flop count for a given quantum circuit without actually running it. So, we need to connect XACC to this new TN-QVM feature to allow XACC users to specify the DryRun option instead of the actual run. Alex, what would the best solution be on the XACC side? DryRun is a property of Accelerator, so we need to be able to modify the Accelerator behavior between ActualRun and DryRun (classical resource estimate only).

TN-QVM can compute either the full quantum circuit wave-function or its slice or individual amplitudes. We need to enable access to these quantities from XACC via some API, something like Accelerator.getWavefunction(Mask) -> const Wavefunction &, where Mask specifies which wavefunction slice we want in Thien's notation, like [0,1,0,-1,-1,-1], which will project the first three qubits [0,1,0] and let the last three qubits be free, that is, will return a slice with 2^3 elements. For the full wavefunction, one will need to supply [-1,-1,-1,-1,-1,-1] (default).

@mileschen360 @amccaskey How did you generate random circuits before? We'd like to run something akin to Figs. 1, and 6 in https://arxiv.org/pdf/1608.00263.pdf. That is, apply Hadamards at the first clock cycle and all subsequent timesteps either hit the lattice with CZ's or local gates.