Qiskit-terra: Make large (100Q) Pulse backend mock

[lcapelluto]

Purpose

The pulse module of Qiskit has yet to be benchmarked. The purpose of benchmarking is to provide a deterministic way to assess performance of software over time. There is room for improvement in the performance of pulse operations; building benchmarks will allow us to quantify progress and justify code refactors.

Description

The first step in building a benchmark is creating mocked (faked) data to operate with. For pulse, we need a faked backend to test certain operations. There's a few reasons not to use real backends for this; for instance, real backends change over time -- we want our tests to be deterministic, we want to be able to run tests locally without an internet connection, and we want to avoid external dependencies.

There are already 2Q and 3Q pulse backend test mocks. The first deliverable will be to build a 100Q version, implemented in a similar way. This can as simple as handwriting the required values, and copy/pasting where it makes sense, but it is probably easier to generate with code (not sure, myself). It's a good opportunity to understand each of the backend attributes between PulseDefaults, BackendProperties, and BackendConfiguration.

The backend attributes for OpenPulse systems are described here: https://arxiv.org/pdf/1809.03452.pdf

Here is the 3Q mock: https://github.com/Qiskit/qiskit-terra/blob/master/qiskit/test/mock/fake_openpulse_3q.py

Alternative/Improvement: Parameterized backend

This task would be to create a util method or a script to generate reasonable Pulse-enabled backends, given a list of parameters to fill the backend data.

[taalexander]

Maybe we could make this parameterizable?

[IceKhan13]

@lcapelluto @taalexander if you give me initial direction to start I can try to work on that if you do not mind :)

[lcapelluto]

Hi @IceKhan13! Thank you for your interest in this issue. We really appreciate the contributions you have been making to Pulse! This time, given the expanding scope of this project, we're planning to work on this in house. I apologize for the outdated label, I'll update it now. If anything changes, I will be sure to let you know.

[taalexander]

Thanks for your interest @IceKhan13, if you want help find something else to dig your teeth into in Qiskit please let me know and I'll do my best to find something interesting 😄 !

[IceKhan13]

@taalexander I'm all in! I'm letting you know 😄

[taalexander]

• Would you be interested in working on a disassembler for the pulse schedule, #2294 ?
• Or fixing acquire to only apply to a single qubit, #2262?

I think both are mediumish projects to undertake.

[IceKhan13]

@taalexander let me take acquire one, if I will be able to finish it I'll jump to disassembler

[taalexander]

Awesome, thank you @IceKhan13!.

[taalexander]

Hello @IceKhan13, any update on this?

[IceKhan13]

@taalexander finishing https://github.com/Qiskit/qiskit-terra/pull/3574 and will jump on https://github.com/Qiskit/qiskit-terra/issues/2294

Regarding this issue @lcapelluto said that you will be doing it inhouse

[taalexander]

Awesome, thanks a lot!

[lcapelluto]

If you follow the nice format in: qiskit-terra/qiskit/test/mock/backends/fake_almaden.py, then the requirement for this issue would be to create 4 files:

• test/mock/backends/fake_100q.py
• conf_100q.json
• props_100q.json
• defs_100q.json

[nkanazawa1989]

I'm bit worried about data size of those files. Since mock backends are placed under qiskit.test.mock, adding them may increase the time to import qiskit. Can we think about transfering them under test if those json files are very large?

[lcapelluto]

I could be wrong, but I don't think mocks have to be imported by default. I doubt that including these files will have too much of an effect at import time. This would be up to @ajavadia