VirtualGraphComposite eating into my QPU time

Hi,

I have this line in my code "sampler = VirtualGraphComposite(sampler_wo_e, embeddings)"

After executing this statement I was surprised to see 4.5 seconds taken off from my QPU time. (I get only 60 seconds a month given my developer access)

My question is - I am not even sampling on the QPU hardware - then why is the call to this API taking so much time?

I don't see this problem with a call to EmbeddingComposite. In fact not even when I sample with 1000 reads.

Regards,

Manoj

 

0

Comments

10 comments
  • Hi Manoj,

    What are you using for "sampler_wo_e"?

    Also, can you provide more context for the code you are running?

    0
    Comment actions Permalink
  • Hi Manoj,

    In order to help figure out where this time usage is coming from, could you provide the minimal example that is causing this to happen with calls to the composites, etc?

    I tried running the VirtualGraphComposite constructor, and it didn't appear to use any time.

    Thanks in advance!

    Dave.

    0
    Comment actions Permalink
  • Thanks for your comments Thomas and Dave.

    I observed a bit more closely. Not sure if the problem is with VirtualGraphComposite.

    But this time when I ran my Jupyter notified I was shocked to see my QPU time fall by 8 seconds without doing a single sample.

    The Leap dashboard usage log (Problem status) is not updated in real time so I am unable to pin point the exact line. But they do show up so many lines after a single partial run of my jupyter notebook (after roughly two minutes of running of the last jupyter cell I am posting below)

    This does not happen with other versions of my program (using EmbeddingComposite for example)

    0
    Comment actions Permalink

  • 0
    Comment actions Permalink

  • 0
    Comment actions Permalink
  • You can now see that the jupyter notebook run (of what I posted) starts from (5:06:37) to (5:06:48)

    What in this notebook is causing so many entries in my Leap dashboard?

    Manoj

    0
    Comment actions Permalink
  • For what its worth ……...

    manoj@Ubuntu-MSHV-Virtual-Machine:~/.config/dwave$ cat dwave.conf
    [defaults]
    client = qpu

    [prod]
    endpoint = https://cloud.dwavesys.com/sapi
    token = DEV-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    solver = DW_2000Q_2_1

     

     

     

    0
    Comment actions Permalink
  • Hello Manoj,

    VirtualGraphComposite applies flux biases when it is first constructed. If no values are provided, then the flux biases are calibrated through a series of calls to the QPU. The following line of code, although not solving an Ising or QUBO problem, uses QPU access time:

    sampler = VirtualGraphComposite(sampler_wo_e, embeddings)

    The calibration is cached so subsequent uses of this sampler will not need to calibrated again.

    We apologize for this error, since it caused you to use QPU time without knowing. We will be updating the documentation shortly to make sure it is clear that this construction uses QPU time.

    0
    Comment actions Permalink
  • Thanks Luca.

    Where is the caching done - on the client end (my program) or at the QPU end?

    Question is - how do I enable this caching. If my problem size (variable n in the code above) changes then wouldn't this caching get invalid?

     

    Manoj

    0
    Comment actions Permalink
  • Hi Manoj,

    As far as I understand it, the caching happens for subsequent calls to sample.

    QPU time is used on the initial instantiation of the VirtualGraphComposite (i.e. every time you call the constructor).

    Dave.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Didn't find what you were looking for?

New post