How to random a clique embedding

• 

  Aljoscha A  (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
• 

  Aljoscha A  (Report)

  April 30, 2025 08:03

  Hi Thomas,

  Thank you for your questions. I agree with your reasoning that hardware related errors should occur at different keys upon permutations within one embedding.

  Based on your questions I am assuming that you are trying to reduce noise or generally alter the quality of the result by modification or displacement of the embedding. Averaging over spin reversal transformations and key permutations enables you to eliminate some sources of noise to leading order and is recommended best practice. If some qubits or couplers are noisier we would expect the chain break rate to be higher on those components after averaging over key permutations. However, one confounding factor is that not all chains are equal in a clique embedding: the length of chains and/or the coupling patterns can vary (https://arxiv.org/abs/2006.04913).

  A translation of the embedding does indeed give you information on the distribution of noise and can help to isolate the impact of QPU non-ideality from embedding distortion, since under ideal calibration and neglecting noise we expect no change in the distribution of noise under translation.

  Ocean provides you with some tools to find multiple embedding points, although they can be slow for large embeddings. See e.g.:

  minorminer.utils.parallel_embeddings.find_multiple_embeddings
  minorminer.utils.parallel_embeddings.find_sublattice_embeddings
  dwave_networkx.pegasus_sublattice_mappings (or chimera/zephyr)

  I hope I this was helpful to you. Please let us know if there are more questions.

  Thanks,
  Aljoscha

   

  0

  Comment actions Permalink

Please sign in to leave a comment.