How to random a clique embedding

• 

  Aljoscha Auer  (Report)

  April 01, 2025 21:21

  Hi Thomas,

  Thank you for your question. The seed in find_clique_embedding is used to handle defects in the graph. The behaviour you observed is expected, if you are embedding the nodes into a defect-free graph or for small cliques. If this is not the case for you, we would be thankful for a minimal code example to reproduce your observed behaviour and investigate.

  You can always randomise the key to value mapping for clique embeddings:

  import random
  vals = list(embedding.values())
  random.shuffle(vals)
  embedding_new = {k: v for k, v in zip(embedding.keys(), vals)}

  regardless of what method is applied to find the embedding in the first place. Noise and embedding distortion can in part be understood and mitigated by averaging (or optimising) over these embeddings.

  I hope this was helpful. Please let us know if you have further questions.

  Thanks,
  Aljoscha

  0

  Comment actions Permalink
• 

  Thomas P  (Report)

  April 16, 2025 13:39

  Hi Aljoscha,

  thanks for the answer. Its a clique of size 45.

  A given sample info states (with extra low intrachain coupling strength):

  {'timing': {'qpu_sampling_time': 244880.0, 'qpu_anneal_time_per_sample': 5.0, 'qpu_readout_time_per_sample': 96.86, 'qpu_access_time': 259755.64, 'qpu_access_overhead_time': 2812.36, 'qpu_programming_time': 14875.64, 'qpu_delay_time_per_sample': 20.58, 'total_post_processing_time': 1.0, 'post_processing_overhead_time': 1.0}, 'problem_id': '6b7927df-3403-4660-8dbd-fb108c062496', 'embedding_context': {'embedding': {...}, 'chain_break_method': 'majority_vote', 'embedding_parameters': {}, 'chain_strength': 1.1}, 'warnings': [{'type': <class 'dwave.system.warnings.ChainBreakWarning'>, 'message': 'Lowest-energy samples contain a broken chain', 'level': 40, 'data': {'target_variables': (1322, 1323, 3484, 3485, 3486, 3487), 'source_variables': [7], 'sample_index': 0}}, {'type': <class 'dwave.system.warnings.ChainBreakWarning'>, 'message': 'Lowest-energy samples contain a broken chain', 'level': 40, 'data': {'target_variables': (1186, 1187, 1188, 3349, 3350, 3351), 'source_variables': [38], 'sample_index': 0}}]}

  Now, it was my initial intention to change the embedding to see if the origin of the broken chains are hardware-related or BQM-related. Therefore, I intented to exclude certain qubits or at least to vary the embedding across the hardware graph. Indeed, your trick (given above) allows only for permutations within the embedding, however the embedding still stretches across on the same hardware qubits.

  Nevertheless, your idea was helpful as by that I was able to confirm that the broken chains (see above warning info) must be attributed to the BQM and not to the hardware. It is my understanding, that after applying the permutations as you suggested hardware related issues would yield then different chain breaks (i.e. with different "keys") which however involve the same qubits (i.e. same "values"). And this is not what I realized.

  Would you agree to the reasining?

  Would you suggest to use the qubit permutations within the clique also in combination with the spin-reversal transformation?

  Thanks,

  Thomas

  0

  Comment actions Permalink

Please sign in to leave a comment.