UCCSD operator pool correction and integration in adapt simulator #65

kvmto · 2025-01-30T13:40:44Z

UCCSD operator pool correction and integration in adapt simulator (Issue #28)

This PR fixes #28 .

Problem

Adapt VQE did not provide correct results. The problem could be the creation of the UCCSD operators pool.

Changes

Changes so far have been applied to:

The UCCSD operator pool 'generate' function.
The Testing of the UCCSD operator pool, cpp and py files.
Tested adap_vqe for final results.

Additional notes

Further testing is needed for making sure that adapt VQE works correctly, especially in terms of molecules.

Signed-off-by: kvmto <[email protected]>

libs/solvers/lib/operators/operator_pools/uccsd_operator_pool.cpp

libs/solvers/unittests/test_operator_pools.cpp

amccaskey · 2025-01-30T14:41:59Z

Let's add a test to test_adapt.cpp that mimics the checkSimpleAdapt but uses the uccsd operator instead of the spin_complement_gsd one. Note that you'll need to update the coefficients on the operators to make them imaginary, since we assume that in adapt_simulator.cpp (line 152).

Signed-off-by: kvmto <[email protected]>

bmhowe23 · 2025-01-31T22:40:14Z

I would recommend adding the phrase "fixes #28" or "resolves #28" to the description in order to automatically link this GitHub PR with the issue. If you do this, then when the PR is merged, the issue will automatically be closed.

Ref: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword

bmhowe23 · 2025-01-31T23:09:27Z

Let's add a test to test_adapt.cpp that mimics the checkSimpleAdapt but uses the uccsd operator instead of the spin_complement_gsd one. Note that you'll need to update the coefficients on the operators to make them imaginary, since we assume that in adapt_simulator.cpp (line 152).

I think I'm missing something ... why we are updating the generic UCCSD operator pools from real to imaginary to accommodate a single assumption in adapt_simulator.cpp? Are any docs updates needed for this change?

marwafar · 2025-01-31T23:51:55Z

The uccsd operator pool is correct. However, it might not be a good idea to multiply the imaginary number "i" by the uccsd operator pool. It will not make it generic. We might use this uccsd operator pool with other algorithm such as GQE and we will need to modify this again. I would suggest multiply the imaginary number "i" somewhere within the adapt-vqe algorithm.

In addition, I would suggest to run the adapt-vqe for these two geometry with sto3g basis.

H 0.0 0.0 0.0
H 0.0 0.0 0.7474

Li  0.0  0.0  0.0
H   0.0  0.0  1.5

We need to make sure that it work for something beyond the simple H2 molecule with 4 qubits and 3 operator pools.

### Fix some issues to allow compilation of `uccsd` - Fix signed int overflow in `uccsd` - allow specifying shots in `vqe` Towards: NVIDIA/cuda-quantum#2357 --------- Signed-off-by: Anna Gringauze <[email protected]>

Signed-off-by: kvmto <[email protected]>

libs/solvers/lib/adapt/adapt_simulator.cpp

libs/solvers/lib/stateprep/uccsd.cpp

Signed-off-by: kvmto <[email protected]>

libs/solvers/python/tests/test_adapt.py

Signed-off-by: kvmto <[email protected]>

libs/solvers/unittests/test_adapt.cpp

libs/solvers/include/cudaq/solvers/operators/molecule.h

Signed-off-by: kvmto <[email protected]>

libs/solvers/unittests/test_adapt.cpp

libs/solvers/lib/adapt/adapt_simulator.cpp

amccaskey · 2025-03-06T14:44:48Z

libs/solvers/lib/adapt/adapt_simulator.cpp

+  const auto &c = pool[0].begin()->get_coefficient();
+  bool isImaginary = (c.real() == 0.0 && c.imag() != 0.0);
+
+  if (!isImaginary) {


I wonder if this could be simplified to something like

auto coeff = isImaginary ? std::complex<double>({0., 1.}) : std::complex<double>{1.,0.}; for (auto& op : pool) commutators.push_back(H * (coeff * op) - (coeff * op) * H);

This is what I tried in the past, but it does not work.
This works : commutators.push_back(coeff * (H * op - op * H));

amccaskey · 2025-03-06T14:48:54Z

libs/solvers/python/tests/test_operator_pools.py

-        'YZXI', 'XZYI', 'IYZX', 'IXZY', 'XXXY', 'XXYX', 'XYYY', 'YXYY', 'XYXX',
-        'YXXX', 'YYXY', 'YYYX'
-    ]
+    expected_pool = ["XZYIYZXI", "IXZYIYZX", "XXXYXXYXXYXXXYYYYXXXYXYYYYXYYYYX"]


The op.to_string(False) is concatenating all the terms together into one string. I think it would be better to ensure that the terms are correct instead of this concatenated string.

I thought I heard @marwafar also ask for this, so should this conversation be reopened?

I had some local changes that didn't get pushed, now they should be here as well.

I do not see any change. They are still the same ["XZYIYZXI", "IXZYIYZX", "XXXYXXYXXYXXXYYYYXXXYXYYYYXYYYYX"]

Sorry, I pushed the cpp and not the py, I will push it with the rest at this point. The test identical.

Signed-off-by: kvmto <[email protected]>

bmhowe23

I'm still trying to get this to run in my environment (probably something wrong in my environment), but here are some initial comments.

libs/solvers/include/cudaq/solvers/operators/operator_pools/qaoa_operator_pool.h

libs/solvers/include/cudaq/solvers/operators/operator_pools/spin_complement_gsd.h

libs/solvers/include/cudaq/solvers/operators/operator_pools/uccsd_operator_pool.h

bmhowe23 · 2025-03-13T19:13:00Z

libs/solvers/lib/adapt/adapt_simulator.cpp

+    std::vector<double> roundedGradients(gradients.size());
+    for (size_t i = 0; i < gradients.size(); ++i) {
+      // Round to a specific precision (e.g., 10 decimal places)
+      roundedGradients[i] = std::round(gradients[i] * 1e16) / 1e16;


Why is this here? Also, the code seems to conflict with the comments (16 digits vs 10 digits). I'm hoping this is old debugging code and no longer needed.

The rounding is necessary to avoid some repeatability issues. The 10th digits was the initial rounding, but then decided to go up again, I will put it back to 10. Thanks for spotting this.

If repeatability issues exist, this will not prevent them. One can always be right on the edge of a rounding decision (i.e. 0.100000000500001 and 0.100000000499999 are 2e-15 apart but will still round to different numbers when rounding to 10 digits), so it would be better to leave this out.

I am ok with non-repeatabilities as long as they go away when we run with OMP_NUM_THREADS=1.

bmhowe23 · 2025-03-13T19:15:07Z

libs/solvers/python/tests/test_operator_pools.py

-        'YZXI', 'XZYI', 'IYZX', 'IXZY', 'XXXY', 'XXYX', 'XYYY', 'YXYY', 'XYXX',
-        'YXXX', 'YYXY', 'YYYX'
-    ]
+    expected_pool = ["XZYIYZXI", "IXZYIYZX", "XXXYXXYXXYXXXYYYYXXXYXYYYYXYYYYX"]


I thought I heard @marwafar also ask for this, so should this conversation be reopened?

marwafar · 2025-03-13T19:28:32Z

Yes. This concatenation should change. You should have it like [['XZY', 'YZX'], ['IXZY', 'IYZX'], ['XXYX', 'XXXY', 'XYYY', 'YYXY', 'XYXX', 'YXYY', 'YYYX', 'YXXX']] . You should make sure adapt_vqe() function returns final parameters, selected pool, and final energy. . For example:
Final parameters: [0.11278279920936399]
Selected pools: [['XXYX', 'XXXY', 'XYYY', 'YYXY', 'XYXX', 'YXYY', 'YYYX', 'YXXX']]
Final energy: -1.1372838344885003

bmhowe23 · 2025-03-13T19:54:02Z

libs/solvers/lib/adapt/adapt_simulator.cpp

+    if (step >= 30) {
+      printf("TIMED OUT\n");
+      break;


This 30 should be a parameter to this function, something like maxIter.

I think we can put that as a configuration options, together with the tolerance on the energy difference between iterations. If it is okay I will do that.

Yes, that sounds good to me.

Yes. This is max iteration, we can add a default value but allow user to change this. Same for the tolerance of the energy and the tolerance for the norm of gradients.

Also, the initial theta parameter default is zero. But, we should also let user change that if they want.

Maybe also when simulation reached the maxIter, instead of only "printf("TIMED OUT\n")" You should also print or save in a file the last parameters, state , selected pools, and energy. User can later enhance the state with other classical simulation in classical post-processing Or we might also later allow user to restart simulation. Allow user to restart simulation will be a nice feature that we should add.

Maybe also when simulation reached the maxIter, instead of only "printf("TIMED OUT\n")" You should also print or save in a file the last parameters, state , selected pools, and energy. User can later enhance the state with other classical simulation in classical post-processing Or we might also later allow user to restart simulation. Allow user to restart simulation will be a nice feature that we should add.

These sound like nice features to add, but probably not part of this PR. For this PR, I think returning/printing an error if it runs longer than a new maxIter parameter should be sufficient.

bmhowe23 · 2025-03-13T19:55:54Z

libs/solvers/unittests/test_adapt.cpp

@@ -12,19 +12,67 @@
 #include "cudaq.h"
 #include "nvqpp/test_kernels.h"
 #include "cudaq/solvers/adapt.h"
+#include "cudaq/solvers/operators.h"


When I run the tests in this file w/ CUDAQ_LOG_LEVEL=info and just watch the stuff scroll by, there are lots of things that look really empty, like this:

[2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1204] Setting current circuit name to void (cudaq::state&) [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1024] Allocating 12 new qubits. [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1045] Deferring qubit 0 deallocation [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1045] Deferring qubit 1 deallocation [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1045] Deferring qubit 2 deallocation [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1045] Deferring qubit 3 deallocation [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1045] Deferring qubit 4 deallocation [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1045] Deferring qubit 5 deallocation [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1045] Deferring qubit 6 deallocation [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1045] Deferring qubit 7 deallocation [2025-03-13 19:50:21.962] [info] [CircuitSimulator.h:1045] Deferring qubit 8 deallocation [2025-03-13 19:50:21.963] [info] [CircuitSimulator.h:1045] Deferring qubit 9 deallocation [2025-03-13 19:50:21.963] [info] [CircuitSimulator.h:1045] Deferring qubit 10 deallocation [2025-03-13 19:50:21.963] [info] [CircuitSimulator.h:1045] Deferring qubit 11 deallocation [2025-03-13 19:50:22.053] [info] [CircuitSimulator.h:1189] Deallocated all qubits, reseting state vector. [2025-03-13 19:50:22.105] [info] [CircuitSimulator.h:1204] Setting current circuit name to void (cudaq::state&) [2025-03-13 19:50:22.105] [info] [CircuitSimulator.h:1024] Allocating 12 new qubits. [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 0 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 1 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 2 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 3 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 4 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 5 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 6 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 7 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 8 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 9 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 10 deallocation [2025-03-13 19:50:22.106] [info] [CircuitSimulator.h:1045] Deferring qubit 11 deallocation [2025-03-13 19:50:22.200] [info] [CircuitSimulator.h:1189] Deallocated all qubits, reseting state vector. ...

Is it possible we're running a bunch of empty circuits somehow?

The log since it repeats seems like the usage of the adapt_kernel, since it used iteratively during the optimization steps.

This is weird.

It looks like they are all coming from

cudaqx/libs/solvers/lib/adapt/adapt_simulator.cpp

Line 111 in 9ec771b

observe_async(qpuCounter++, prepare_state, commutators[i], state));

(the prepare_state kernel).

It looks like that code is assuming that all the state vectors from all the commutators will fit in GPU memory. That seems like a dubious assumption. (This was pre-existing, not new for this PR.)

The component running empty circuits is "prepare_state". It just allocates and deallocates the qubits.

__qpu__ void prepare_state(cudaq::state &state) { cudaq::qvector q{state}; }

My guess is that in order to always run useful circuits, it could could be useful to remove the get_states, and use only adapt_kernel with the various observe

I will try to skip the two get_state and see if i can get a boost,
but they seem to be redundant at the moment :)
I need a moment to address everything.

@bmhowe23 any idea why it is not possible to do :

resultHandles.emplace_back( observe_async(qpuCounter++, adapt_kernel, commutators[i], numQubits, initialState, thetas, coefficients, pauliWords, poolIndices));

I looked into this a bit more. It looks like it is indeed applying the commutators[i] spin op at the end of each circuit (via https://github.com/NVIDIA/cuda-quantum/blob/50066dd99025c4eae2af150c327664328b8249cc/runtime/nvqir/custatevec/CuStateVecCircuitSimulator.cpp#L548) ... there are no logs in that function, so reading the logs may have led us down a wild goose chase here.

That being said - we may improve the efficiency by removing the terms that have 0-valued coefficients inside the commutators.

Just done.:)
I am trying to avoid the double calculation of the state, do you happen to have an answer to the observe_async?

@bmhowe23 any idea why it is not possible to do :

resultHandles.emplace_back( observe_async(qpuCounter++, adapt_kernel, commutators[i], numQubits, initialState, thetas, coefficients, pauliWords, poolIndices));

Not off the top of my head ... what happens when you try that?

…oa_operator_pool.h Co-authored-by: Ben Howe <[email protected]> Signed-off-by: Kevin Mato <[email protected]>

…csd_operator_pool.h Co-authored-by: Ben Howe <[email protected]> Signed-off-by: Kevin Mato <[email protected]>

kvmto · 2025-03-13T22:10:15Z

libs/solvers/lib/adapt/device/adapt.cpp

@@ -15,13 +16,20 @@ adapt_kernel(std::size_t numQubits,
             const cudaq::qkernel<void(cudaq::qvector<> &)> &statePrep,
             const std::vector<double> &thetas,
             const std::vector<double> &coefficients,
-             const std::vector<cudaq::pauli_word> &trotterOpList) {
+             const std::vector<cudaq::pauli_word> &trotterOpList,
+             const std::vector<std::size_t> poolIndices) {
  cudaq::qvector q(numQubits);


Could this line the reason why we see the allocation and deallocation of qubits in the log? @bmhowe23

Yes, that would explain the allocation and deallocation, but I'm confused why I don't see any gates occurring. Could we be calling this kernel with an empty trotterOpList?

…in_complement_gsd.h Co-authored-by: Ben Howe <[email protected]> Signed-off-by: Kevin Mato <[email protected]>

bmhowe23 · 2025-03-14T04:12:02Z

libs/solvers/lib/adapt/adapt_simulator.cpp

+  auto coeff = (!isImaginary) ? std::complex<double>{0.0, 1.0}
+                              : std::complex<double>{1.0, 0.0};
+  for (auto &op : pool)
+    commutators.push_back(coeff * (H * op - op * H));


@amccaskey @kvmto @marwafar - there are a significant number of terms in these spin ops that have coefficients = 0. Is that expected? I could be mistaken, but I suspect that means some wasted computation down below.

You mean the spin op in the commutator? Yes some some spin op in the commutator operator will be zero. Because of symmetry, some excitation are not allowed. Those will be zero. We should write a function after computing the commutator to remove terms with zero coefficient.

bmhowe23 · 2025-03-14T04:22:08Z

libs/solvers/lib/adapt/adapt_simulator.cpp

+  const auto &c = pool[0].begin()->get_coefficient();
+  bool isImaginary =
+      (std::abs(c.real()) <= 1e-9) && (std::abs(c.imag()) > 1e-9);


Are you sure that c will never be 0+0j? If it is, then this isImaginary variable would potentially be incorrect.

The coefficients of operator pool will not be zero. They are either one or less than one.

The coefficients of operator pool will not be zero. They are either one or less than one.

I believe c is being set to the first term of the first spin op in the pool here. If any of the terms in the spin op can have 0-valued coefficients, then I believe this could be 0. I could be misunderstanding that, though ... looking for @kvmto to confirm that c is never 0 here.

I confirm it is never 0 :)

marwafar · 2025-03-14T12:23:17Z

libs/solvers/lib/adapt/adapt_simulator.cpp

@@ -140,16 +171,22 @@ simulator::run(const cudaq::qkernel<void(cudaq::qvector<> &)> &initialState,
    }

    // Convergence is reached if gradient values are small
-    if (std::sqrt(std::fabs(norm)) < tol || std::fabs(lastNorm - norm) < tol)
+    if (std::sqrt(std::fabs(norm)) < tol || std::fabs(lastNorm - norm) < tol ||


You should not use the same tol value for norm and lastNorm-norm. You should provide different variable names. Also, you should allow user to change those threshold value.

Also, replace fabs(norm)) with just norm, norm is already the absolute value of the gradient vector

marwafar · 2025-03-14T12:24:59Z

libs/solvers/lib/adapt/adapt_simulator.cpp

@@ -140,16 +171,22 @@ simulator::run(const cudaq::qkernel<void(cudaq::qvector<> &)> &initialState,
    }

    // Convergence is reached if gradient values are small
-    if (std::sqrt(std::fabs(norm)) < tol || std::fabs(lastNorm - norm) < tol)
+    if (std::sqrt(std::fabs(norm)) < tol || std::fabs(lastNorm - norm) < tol ||
+        ediff < 1e-6)


1e-6 should be variable name like thresholdE. Add a default value but allow user to change these value if they want

marwafar · 2025-03-14T12:27:20Z

libs/solvers/lib/adapt/adapt_simulator.cpp

      break;

    // Use the operator from the pool
    auto op = pool[maxOpIdx];
+    if (!isImaginary)
+      op = std::complex<double>{0.0, 1.0} * pool[maxOpIdx];
+
    chosenOps.push_back(op);
    thetas.push_back(0.0);


Default value should be zero. But allow user to change this too. Instead of "thetas.push_back(0.0);", you can do "thetas.push_back(initTheta)" and initTheta=0.0 default

marwafar · 2025-03-14T12:43:25Z

libs/solvers/lib/adapt/adapt_simulator.cpp

@@ -101,15 +124,23 @@ simulator::run(const cudaq::qkernel<void(cudaq::qvector<> &)> &initialState,
    double norm = 0.0;
    for (auto &g : gradients)
      norm += g * g;
+    norm = std::sqrt(norm);


This part is not clean. You are returning in line 121 the absolute value of the gradient value, then compute norm \sqrt(\sum_i (grad_i)**2).
I think you should do that and it will not change any result. return the gradient value and not the absolute value. Then compute norm as abs (\sqrt(\sum_i (grad_i)**2)). This is how we compute norm of a vector.

I need the absolute values in order to pick the max_element, somewhere I have to do the std::abs. If the order of operations does not bother I would keep it as is.

marwafar · 2025-03-14T12:47:03Z

libs/solvers/lib/adapt/adapt_simulator.cpp

-                      coefficients, pauliWords);
+                      coefficients, pauliWords, poolIndices);
+
+    if (groundEnergy < latestEnergy) {


They will be always less. This if statement is redundant

Signed-off-by: kvmto <[email protected]>

kvmto added 2 commits January 30, 2025 13:27

fix to uccsd operator pool

b763bd1

Signed-off-by: kvmto <[email protected]>

Linted files.

8cec893

Signed-off-by: kvmto <[email protected]>

kvmto requested a review from amccaskey January 30, 2025 13:40

amccaskey reviewed Jan 30, 2025

View reviewed changes

libs/solvers/lib/operators/operator_pools/uccsd_operator_pool.cpp Outdated Show resolved Hide resolved

amccaskey reviewed Jan 30, 2025

View reviewed changes

libs/solvers/unittests/test_operator_pools.cpp Show resolved Hide resolved

kvmto added 2 commits January 31, 2025 13:31

Fixed tests issue 28 and linted.

f888443

Signed-off-by: kvmto <[email protected]>

updated tests

f0bc450

Signed-off-by: kvmto <[email protected]>

kvmto requested a review from amccaskey January 31, 2025 13:52

bmhowe23 requested a review from marwafar January 31, 2025 23:12

annagrin and others added 4 commits February 3, 2025 20:07

Fix signed int overflow in uccsd (NVIDIA#64)

9114ac9

### Fix some issues to allow compilation of `uccsd` - Fix signed int overflow in `uccsd` - allow specifying shots in `vqe` Towards: NVIDIA/cuda-quantum#2357 --------- Signed-off-by: Anna Gringauze <[email protected]>

Commented operator pools.

77ebc62

Signed-off-by: kvmto <[email protected]>

Rectified insertion of i coefficient.

28d228e

Signed-off-by: kvmto <[email protected]>

Linting.

d540e7e

Signed-off-by: kvmto <[email protected]>

kvmto changed the title ~~Fix issue 28~~ UCCSD operator pool correction and integration in Adapt Simulator Feb 3, 2025

kvmto changed the title ~~UCCSD operator pool correction and integration in Adapt Simulator~~ UCCSD operator pool correction and integration in adapt simulator Feb 4, 2025

amccaskey reviewed Feb 4, 2025

View reviewed changes

libs/solvers/lib/adapt/adapt_simulator.cpp Outdated Show resolved Hide resolved

amccaskey reviewed Feb 4, 2025

View reviewed changes

libs/solvers/lib/stateprep/uccsd.cpp Outdated Show resolved Hide resolved

kvmto added 3 commits February 5, 2025 16:10

Merge branch 'NVIDIA:main' into fix_issue_28

ad420a2

Updated test adapt and adapt simulator

0f715df

Signed-off-by: kvmto <[email protected]>

New update test adapt

694d3e9

Signed-off-by: kvmto <[email protected]>

bmhowe23 reviewed Feb 5, 2025

View reviewed changes

libs/solvers/python/tests/test_adapt.py Outdated Show resolved Hide resolved

kvmto added 5 commits February 5, 2025 16:22

Finished dev of tests adapt vqe.

d354de6

Signed-off-by: kvmto <[email protected]>

Linted.

ec45a39

Signed-off-by: kvmto <[email protected]>

Merge remote-tracking branch 'upstream/main' into fix_issue_28

7cff303

Added molecules to test adapt.

be814f3

Signed-off-by: kvmto <[email protected]>

Merge remote-tracking branch 'upstream/main' into fix_issue_28

1204bf8

bmhowe23 reviewed Feb 21, 2025

View reviewed changes

libs/solvers/unittests/test_adapt.cpp Outdated Show resolved Hide resolved

kvmto requested a review from bmhowe23 February 21, 2025 23:07

bmhowe23 reviewed Feb 21, 2025

View reviewed changes

libs/solvers/include/cudaq/solvers/operators/molecule.h Outdated Show resolved Hide resolved

Tests refactored and reset

bff8818

Signed-off-by: kvmto <[email protected]>

kvmto force-pushed the fix_issue_28 branch from 65e9b7a to bff8818 Compare February 21, 2025 23:34

kvmto added 3 commits February 24, 2025 20:52

Merge remote-tracking branch 'upstream/main' into fix_issue_28

a22cf61

Merge remote-tracking branch 'upstream/main' into fix_issue_28

eb22a1d

New tests for test_adapt

00a1b67

Signed-off-by: kvmto <[email protected]>

amccaskey reviewed Mar 6, 2025

View reviewed changes

libs/solvers/unittests/test_adapt.cpp Show resolved Hide resolved

amccaskey reviewed Mar 6, 2025

View reviewed changes

libs/solvers/lib/adapt/adapt_simulator.cpp Outdated Show resolved Hide resolved

amccaskey reviewed Mar 6, 2025

View reviewed changes

kvmto added 2 commits March 13, 2025 17:07

change of norm calculation, adapt_kernel, uccsd coefficients

e42e204

Signed-off-by: kvmto <[email protected]>

Merge remote-tracking branch 'upstream/main' into fix_issue_28

dbfbfdf

bmhowe23 reviewed Mar 13, 2025

View reviewed changes

kvmto and others added 3 commits March 13, 2025 23:02

Update libs/solvers/include/cudaq/solvers/operators/operator_pools/qa…

1fe364b

…oa_operator_pool.h Co-authored-by: Ben Howe <[email protected]> Signed-off-by: Kevin Mato <[email protected]>

Update libs/solvers/include/cudaq/solvers/operators/operator_pools/qa…

0c928d8

…oa_operator_pool.h Co-authored-by: Ben Howe <[email protected]> Signed-off-by: Kevin Mato <[email protected]>

Update libs/solvers/include/cudaq/solvers/operators/operator_pools/uc…

9a00b5a

…csd_operator_pool.h Co-authored-by: Ben Howe <[email protected]> Signed-off-by: Kevin Mato <[email protected]>

kvmto commented Mar 13, 2025

View reviewed changes

kvmto and others added 2 commits March 13, 2025 22:12

Merge remote-tracking branch 'upstream/main' into fix_issue_28

d0f4629

Update libs/solvers/include/cudaq/solvers/operators/operator_pools/sp…

9ec771b

…in_complement_gsd.h Co-authored-by: Ben Howe <[email protected]> Signed-off-by: Kevin Mato <[email protected]>

bmhowe23 reviewed Mar 14, 2025

View reviewed changes

marwafar reviewed Mar 14, 2025

View reviewed changes

kvmto added 3 commits March 14, 2025 15:53

Python test of UCCSD operator pool updated.

62798e1

Signed-off-by: kvmto <[email protected]>

Introduced new options and clean up of the commutators

6df8730

Signed-off-by: kvmto <[email protected]>

Merge remote-tracking branch 'upstream/main' into fix_issue_28

c243f3b

UCCSD operator pool correction and integration in adapt simulator #65

Are you sure you want to change the base?

UCCSD operator pool correction and integration in adapt simulator #65

Conversation

kvmto commented Jan 30, 2025 • edited Loading

UCCSD operator pool correction and integration in adapt simulator (Issue #28)

Problem

Changes

Additional notes

amccaskey commented Jan 30, 2025

bmhowe23 commented Jan 31, 2025

bmhowe23 commented Jan 31, 2025

marwafar commented Jan 31, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmhowe23 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marwafar commented Mar 13, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kvmto Mar 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kvmto Mar 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmhowe23 Mar 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmhowe23 Mar 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kvmto commented Jan 30, 2025 •

edited

Loading

kvmto Mar 14, 2025 •

edited

Loading

kvmto Mar 14, 2025 •

edited

Loading

bmhowe23 Mar 14, 2025 •

edited

Loading

bmhowe23 Mar 14, 2025 •

edited

Loading