Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Hardware path] cudaq.observe() incorrectly returns 0.0 when there is only a single spin op term #2382

Open
3 of 4 tasks
bmhowe23 opened this issue Nov 15, 2024 · 0 comments

Comments

@bmhowe23
Copy link
Collaborator

Required prerequisites

  • Consult the security policy. If reporting a security vulnerability, do not report the bug using this form. Use the process described in the policy to report the issue.
  • Make sure you've read the documentation. Your issue may be addressed there.
  • Search the issue tracker to verify that this hasn't already been reported. +1 or comment there if it has.
  • If possible, make a PR with a failing test to give us a starting point to work on!

Describe the bug

When using a single spin-op term, running cudaq::observe() from C++ (or cudaq.observe() from Python) returns incorrect results when running with --emulate for C++ (or emulate=True for Python). It returns 0.0 instead of a true expectation calculation.

Steps to reproduce the bug

Starting with the targettests/execution/cudaq_observe.cpp test already in the repo, if one were to modify h to a single term (e.g. cudaq::spin_op h = i(0) * z(1);), the resulting energy is 0.0 when running with --emulate and it is non-zero when running without --emulate.

For example, generate this test file (test.cpp):

#include <cudaq.h>
#include <cudaq/algorithm.h>

// The example here shows a simple use case for the `cudaq::observe`
// function in computing expected values of provided spin_ops.

struct ansatz {
  auto operator()(double theta) __qpu__ {
    cudaq::qvector q(2);
    x(q[0]);
    ry(theta, q[1]);
    x<cudaq::ctrl>(q[1], q[0]);
  }
};

int main() {

  // Build up your spin op algebraically
  using namespace cudaq::spin;
  cudaq::spin_op h = i(0) * z(1); // <-- MAKE THIS CHANGE HERE
  // cudaq::spin_op h = 5.907 - 2.1433 * x(0) * x(1) - 2.1433 * y(0) * y(1) +
  //                    .21829 * z(0) - 6.125 * z(1);

  // Make repeatable for shots-based emulation
  cudaq::set_random_seed(13);

  // Observe takes the kernel, the spin_op, and the concrete
  // parameters for the kernel
  double energy = cudaq::observe(ansatz{}, h, .59);
  printf("Energy is %.16lf\n", energy);
  return 0;
}

And then run the following two tests, you will see different answers. The answers should be the same.

$ nvq++ --target oqc --emulate test.cpp
$ ./a.out
Energy is 0.0000000000000000
$ nvq++ --target qpp-cpu test.cpp
$ ./a.out
Energy is 0.8309406791001634

Expected behavior

The answers should match.

Note that the example provided in this bug report only deals with the --emulate path, but based on partner feedback, I believe the bug exists when using real hardware as well.

Is this a regression? If it is, put the last known working version (or commit) here.

Not a regression

Environment

  • CUDA-Q version: 0.8.0
  • Python version: N/A
  • C++ compiler: N/A
  • Operating system: N/A

Suggestions

I have tracked down at least one of the problems to this section of code:

// If there are multiple codes, this is likely a spin_op.

That section of code is assuming that if there is a single circuit that was run (like for a single spin op), that it was not actually an observe calculation. This needs to be updated to be correctly ascertain whether the parent request originated from an observe call rather than just inferring it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant