Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [xacc-dev] tnqvm abstraction

Hey Raphael, 

Adding the xacc-dev list, since this is a great discussion for it (head over to to subscribe) 

Man I’m really glad you’ve spent some time building all this and working with it. You ask great questions!

There is a lot going on under the hood when you use the XACC high-level API to compile/execute kernels, and even more in the VQE app. First off, an appropriate Compiler instance is selected and the source code is given to it for compilation, which results in an instance of the XACC intermediate representation (IR). That IR is a container for Function instances, and Functions are ultimately executed by Accelerators. Check out the architecture picture I’m attaching, it shows these interfaces and the primary methods on them. These Functions end up being structured as n-ary trees of Instruction instances, where nodes of the tree are other Functions, and leaves are concrete Instructions. In this way we are able to provide a polymorphic representation of compiled programs for various models of quantum computing, and potentially other post-Moore technologies. 

Accelerator execute methods walk this tree and perform appropriate operations according to the type of the tree node. The ‘tree-walking’ is usually done with Instruction Visitors (, which basically provides a way to extend the behavior of Instruction instances at runtime. 

As for the function chain that gets called when you call tnqvm.execute() - what’s happening is TNQVM picks an appropriate visitor instance (we have an ITensorMPSVisitor and are still working on the ExatensorVisitor) and uses that visitor in walking the provided Function tree (see lines 85-98 of At each node, a visit() method is called for the corresponding Instruction (Hadamard example 

You could modify this behavior (for example I’d like to enhance ITensorMPSVisitor with support for additional, optional unitary noise) by just subclassing ITensorMPSVisitor and overriding the appropriate visit() methods. I imagine in the future developing new visitors for different tensor types - peps, mera, etc. You then publish your subclass as a plugin and the framework picks it up, then you could run something like 

auto tnqvm = xacc::getAccelerator(‘tnqvm’);

xacc::setOption(‘tnqvm-visitor’, ‘raphaels-visitor’);

tnqvm->execute(buffer, function);

Creating Functions dynamically can be done in 2 ways: (1) the usual kernel string definition that gets compiled, or (2) using the IR, Function, Instruction subclasses directly (here’s an example, lines 53-107

Of course there are also python bindings for all of these classes too, here’s an example of creating a Function in python - first Cell of

I hope this helps in getting started. We can keep this discussion going if you’re looking for more detail. What are you looking to do with lower-level access to TNQVM?



On Feb 22, 2018, at 5:12 PM, Pooser, Raphael C. <pooserrc@xxxxxxxx> wrote:

Hey guys,
Do you have an easy way to get to a lower level entry point to tnqvm? Right now I am looking through the code and the examples are at very abstract levels. I’d like to access the machinery that is abstracted away. For instance, the example in tnqvm’s git repo for the 100 qubit simulation (or the vqe example) is magic at the moment, essentially because all gate execution is wrapped up in tidy xacc functions.  I just hit vqe.execute, and boom, I get a nice plot with a ground state energy curve as a function of angle. I’m impressed that it’s so tidy. However, I do not know what’s going on 😊
Do you guys have something like a flowchart that shows the function chain that I can use to trace it down to the function where one gate after another is called on the register? I don’t think what I’m looking for is in your arxiv; it’s essentially a high level description of the xacc objects/classes and how they fit together.
My goal is: I don’t want VQE (or other algorithms we develop) to be black boxes within Xacc. I’d like to read and understand the machinery that xacc is wrapping. OTOH, the way it is presented in XACC is perfect for someone who wants it to just work, or for someone who already has a firm grasp on the behind-the-scenes stuff and doesn’t need to bother himself with keeping track of it all. Unfortunately I am neither person yet. Let me know where I should look (perhaps in some execute method somewhere!)
Raphael Pooser
Team Lead: Quantum Sensing
Devices Focus Area Lead; Quantum Computing Institute
Senior Research Scientist; Quantum Information Science Group
Computational Sciences and Engineering Division
Oak Ridge National Laboratory

Back to the top