Submission: Aqarios Constrained Quantum Optimizer on Maximum Independent Set

[dbucher97]

This PR presents results from the Aqarios Constrained Quantum Optimization Algorithm.

Summary

Problem	# Variables	Best Objective Value	Optimal Solution
es60fst02	186	88	88
es60fst04	162	78	78
sloane_1dc_128	128	16	16
sloane_1zc_128	128	18	18
sloane_2dc_128	128	5	5

Algorithm Description

The algorithm is an Iterative-Warm-Start QAOA variant with fixed angles and XY-mixers
for one-hot constraint enforcement. Since cliques in MIS can be reduced to a single clique constraint
sum(x_clique) <= 1, we add a binary slack variable to obtain sum(x_clique) + y = 1, turning the clique constraint into a one-hot constraint that can be encoded with XY-mixers.

For more details, see the Preprint.

Here is a short overview of the inner workings:

1. Preprocessing
   • Find all set-packing constraints and identify non-overlapping cliques.
   • If the model is a MIS, apply reductions by fixing pendant and simplicial nodes where possible.
   • Identify which constraints can be handled by XY-mixers.
   • Add remaining constraints to the objective as quadratic penalties.
   • Rescale the cost function so that fixed QAOA angles yield reasonable results.
2. Algorithm Phase
   • Build the Qiskit circuit and initialize with a uniform warm-starting state.
   • Sample from the circuit.
   • Apply classical post-processing (greedy) on the samples.
   • Estimate a warm-starting probability distribution via a Boltzmann-weighted mean over each variable's outcomes.
   • Update the warm-start probabilities and iterate.

[mlschicker]

Hi @dbucher97 ,

thank you for your submission!
All automated tests pass.

Your averaged total runtimes seem very long compared with the CPU and QPU runtimes.
I assume you reported the cumulative runtime over all 5 runs for each instance.
The total runtime should be the average total end-to-end per execution time.
Please update this in your submission.

Why do you not provide TTS?

Do you have numbers on how many clique constraints you can extract for each instance and which nodes are contained?
I think this could be valuable information for future methods.

Looking forward to your response!

Thank you.

Best,
Max

[dbucher97]

Hi @mlschicker,
Thank you for your response!

Regarding your points:

1. Indeed, the runtimes were cumulating over the individual runs and are all off. We will update the corrected results later.
2. About TTS: We can still provide you with the TTS numbers. Do you want TTS in terms of wall-clock time until the optimal has been found?
3. You can already find the clique sizes in the workflow description. Below, you can find the actual nodes that comprise the cliques. It only applies to the sloane instances; no cliques were found in the es60fst instances.

sloane_1dc_128

[10, 18, 19, 20, 22, 38, 42, 74]
[7, 11, 13, 14, 15, 23, 39, 71]
[16, 24, 28, 30, 31, 32, 48, 80]
[43, 75, 83, 85, 86, 87, 91, 107]
[58, 90, 106, 114, 115, 116, 118, 122]
[25, 41, 49, 50, 51, 53, 57, 89]
[47, 55, 59, 61, 62, 63, 95]
[36, 68, 70, 72, 76, 84, 100]
[81, 97, 98, 99, 101, 105, 113]
[44, 52, 54, 56, 60, 92, 108]
[21, 26, 27, 29, 45, 77]
[93, 109, 117, 121, 123, 125]
[46, 78, 88, 94, 110]
[4, 6, 8, 12]
[34, 35, 67, 82]
[79, 103, 104, 111]

sloane_2dc_128

[14, 22, 23, 26, 27, 38, 39, 42, 43, 44, 45, 46, 47, 51, 52, 53, 54, 55, 59, 75, 77, 78, 83, 86, 87, 90, 91, 103]
[50, 57, 58, 82, 85, 89, 98, 99, 100, 101, 102, 105, 106, 107, 109, 113, 114, 115, 117, 121]
[8, 12, 15, 16, 20, 24, 28, 36, 40, 68, 70, 71, 72, 76, 79, 84]
[29, 30, 31, 61, 93]

sloane_1zc_128

[4, 8, 12, 20, 36, 68]
[16, 24, 28, 30, 31, 32]
[13, 14, 15, 29, 45, 77]
[40, 72, 100, 102, 103, 104]
[49, 50, 51, 53, 57, 113]
[58, 90, 106, 114, 121, 122]
[66, 67, 69, 73, 81, 97]
[63, 95, 111, 119, 123, 125]
[22, 70, 82, 85, 86]
[43, 44, 47, 59, 107]
[83, 84, 87, 91, 115]
[6, 7, 21, 37]
[46, 48, 62, 110]
[10, 26, 42, 74]
[56, 88, 116, 118]
[61, 93, 109, 117]
[11, 19, 25, 27]

[mlschicker]

Hi @dbucher97 ,

thank you for your response.
Yes, TTS should be wall-clock time.

Thank you for providing the cliques - these are very interesting in my opinion.

Best,
Max

[mlschicker]

Hi @dbucher97 ,

what method do you use to extract the cliques from the graph?
And what is the runtime you spend on this process?

Thank you!

Best,
Max

[dbucher97]

Hi @mlschicker,

We use a combination of igraph largest_clique (link) for sparse graphs and cliquematch get_max_clique(use_heuristic=True) (link) for denser graphs. The algorithm iteratively finds the largest clique -> removes it from the graph, then continues finding the largest clique until no more cliques with $>3$ nodes can be found.

The runtime of the preprocessing for the five graphs is given below:

Name	Runtime
es60fst02	18ms
es60fst04	18ms
sloane_1dc_128	42ms
sloane_2dc_128	206ms
sloane_1zc_128	33ms

[mlschicker]

Hi @dbucher97 ,

thank you for the clarification.

There is one thing I would like to flag and discuss in detail:
From the graphs, you extract the maxiMUM cliques.
This problem is, in general, as difficult as finding the maxiMUM independent set.
Thus, the method does not seem to be scalable nor applicable to general graphs.

One idea to fix this issue is to extract (maxiMAL) cliques heuristically, i.e., without proving that they are optimal.
This would further improve runtimes and be much more scalable for bigger, harder, and denser instances.

I'm looking forward to your response.

Best,
Max

[dbucher97]

Hi @mlschicker,

Currently, the exact method is only employed with sparse graphs. For dense graphs, we rely on the cliquematch get_max_clique method with the use_heursitic=True parametrization. According to the docs this is a heuristic method designed to find large cliques but not designed to give the maximum clique here.

So I think your concern is not entirely valid, as your suggestion to fix this issue is alredy in use. (Btw, in all sloane istances the heurisitic is used).

Please let me know if you have further questions.

Best,
David

[mlschicker]

Hi @dbucher97 ,

thank you for the quick response!

I checked the docs again.
And there is a caveat that I stumbled over multiple times.

The method has use_dfs as an additional parameter which is set to True on default.
Setting use_heuristic to True (which is also default), the lower bound for the exact clique search is tighter at the start of the search which improves performance.

Nonetheless, as you document the function call, the library documentation suggests that the proven maximum clique is computed.
This can be changes by adding use_dfs=False to the function call.

Best,
Max

[dbucher97]

Hi @mlschicker,

Thank you for pointing out this caveat. Actually, in our code, we set use_dfs to False. Because I remember we observed exploding runtimes when it wasn't set. However, I missed mentioning that before.

Best,
David

[mlschicker]

Hi @dbucher97 ,

wonderful!
Thanks for checking.

Can you add a README describing your exact method with the caveats mentioned in this discussion?
I think this is the best way to avoid confusion about this in the future.

I will update the website to also include method description READMEs as I think the small workflow section is often not enough to describe the method in full detail.

Thank you!

Best,
Max