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 (https://en.wikipedia.org/wiki/Visitor_pattern
which basically provides a way to extend the behavior of Instruction instances at runtime.
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’);
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?
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!)
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