Bug in PartialTomoObjFuncEval with regards to n-qubits for qalloc() call

[amccaskey]

Take the following test of QITE

TEST(QiteWorkflowTester, checkDeuteronH2) {
  using namespace qcor;
  xacc::set_verbose(true);
  auto compiler = xacc::getCompiler("xasm");
  auto ir = compiler->compile(R"(__qpu__ void f(qbit q) { X(q[0]); })", nullptr);
  auto x = ir->getComposite("f");

  auto observable = -2.1433 * X(0) * X(1) - 2.1433 * Y(0) * Y(1) +
                    .21829 * Z(0) - 6.125 * Z(1) + 5.907;
  xacc::internal_compiler::qpu = xacc::getAccelerator("qpp");
  const int nbSteps = 25;
  const double stepSize = 0.1;
  auto problemModel = QuaSiMo::ModelFactory::createModel(x, &observable);
  auto workflow = QuaSiMo::getWorkflow(
      "qite", {{"steps", nbSteps}, {"step-size", stepSize}});
  auto result = workflow->execute(problemModel);
  const auto energy = result.get<double>("energy");
}

This is a 2 qubit problem, but at first PartialTomoObjFuncEval will be evaluating with the state preparation circuit which is on 1 qubit, and it tries to qalloc() with statePrep->nPhysicalBits(). This causes an error in the backend qpp accelerator due to mismatched n-qubits in the provided buffer vs the composite instruction being executed.

Maybe we need to update evaluate() to also take the number of qubits.

[amccaskey]

a quick hack to get this working would be adding an identity gate

  auto ir = compiler->compile(R"(__qpu__ void f(qbit q) { X(q[0]); I(q[1]); })", nullptr);

[1tnguyen]

I think this is a bug, it should do

auto tmp_buffer = qalloc(target_operator->nBits());

[amccaskey]

oh cool. I'll update with my next commit.