`Advantage.init` method - time measurements & `penalty_weights` related to `find_clique_embedding`

[basiav]

Issues related to the find_clique_embedding presence in the Advantage.init method - penalty_weights and time measurements (elapse_times) affected.

1. Please take a look at the Advantage.init method:

(screenshot of basia/sampleset_info_extraction

QHyper/QHyper/solvers/quantum_annealing/dwave/advantage.py

Line 89 in 3750127

if use_clique_embedding:

merged with your penalty_weights fix kacper3615/bug_fixes

QHyper/QHyper/solvers/quantum_annealing/dwave/advantage.py

Line 82 in b91adea

args = self.penalty_weights if self.penalty_weights else []

)

A. You issued that there is the elapse_times flag in .init and not only elapse_times and return_metadata in .solve

As long ago we put the find_clique_embedding func. call in the .init (and rightly, follows later on why) and the timing measurements are optional, some flag needs to determine it.

Please note that a similar issue occurs with penalty_weights due to the same reason of find_clique_embedding in the .init.

2. What might be tempting as a solution - moving find_clique_embedding to the .solve method similarily as with find_embedding

-> better it stays in .init

3. Why find_clique_embedding should stay in .init and not go to .solve:

The first time the user installs and runs QHyper the find_clique_embedding function executes the embedding search (takes minutes). The next calls to the function are accessing the cache (takes seconds). Unless the cache is cleared https://docs.dwavequantum.com/en/latest/ocean/api_ref_minorminer/source/clique_embedding.html#class, and so the process repeats then (first call - search, later calls - accessing cache).

Because of our API, the user will observe this phenomenon:

If we put it to .solve, the user wouldn't know why for heuristic the .solve takes long, and for clique at first long, then short.

Similarly as in Qommunity's API:

For clique: long initialization of the sampler at the first time of use, then quick in the hierarachical run. Then fast initializations of the sampler always.
For heuristic: short initialization of the sampler always, long hieararchical runs always.

Solution/suggestion:

I suggest we introduce a functionality to clear the cache, so that the user can e.g. measure the time of clique embedding calculation (calculation, which is only at the first call, not access at the later calls).

I have worked on it a little and I'd be happy to implement it.

This + keeping the find_clique_embedding in the .init + some user warning/information would enable the user to measure time of the clique embedding search.

4. Suggestion:

• Keeping the find_clique_embedding in the .init,
• keeping elapse_times accordingly, modify penalty_weights accordingly - not done, they crash when the problem has constraints,
• implement cache clearing functionality with warning/user information about the cache status - enabling her/him to measure the time of clique embedding search, not just cache access. Described above.

Originally posted by @basiav in #55 (comment)