OpenPulse frontend - assembler module

[nkanazawa1989]

Summary

This is the final piece of #1713, built on #2108. This convert pulse schedule to qobj and execute it on the backend.

Details and comments

execute_schedule() internally calls assemble_schedule() to create PulseQobj and execute this on the given backend.

opts = {
    'shots': rabi_shots,
    'meas_level': 1,
    'meas_return': 'avg',
    'memory_slot_size': 1
}

job = execute_schedules(schedules, backend, user_lo_dict, **opts)

• We still need to discuss the interface of LOs for multiple schedules and frequency sweep. Adding restriction to the length of user_lo_dict could be the best solution so far #41

• We can find the mismatch between execute interfaces of pulse and circuit.

• We should provide schedule validator to verify at least meas_map (I'm writing this in another PR)

[itoko]

Example codes:

[Case - No LO settings]
# compose schedule
schedule = pulse.Schedule()
#... compose schedule ...
execute_schedules(schedule, backend, **opts)

[Case - 1 schedule : n lo_configs]
# compose schedule
schedule = pulse.Schedule()
#... compose schedule ...

# set LO frequency
lo_configs=[]
for drive_lo_freq in drive_lo_freqs:
    freq_d0 = freq_d0_default + drive_lo_freq
    lo_configs.append(UseLoDict({device.q[0].drive: freq_d0}))

execute_schedules(schedule, backend, lo_configs, **opts)

[Case - n schedules : 1 lo_config]
# compose schedules
schedules = []
for ii in pulses:
    #... compose ii-th schedule ...
    schedules.append(schedule)

# set LO frequency
lo_config = UseLoDict({device.q[0].drive: freq_d0})

execute_schedules(schedules, backend, lo_config, **opts)

[Case - n*m schedules : n*m lo_configs from n schedules * m lo_configs]
# compose n schedules
schedules = []
for ii in pulses:
    #... compose ii-th schedule ...
    schedules.append(schedule)

# m LO frequency settings
lo_configs=[]
for drive_lo_freq in drive_lo_freqs:
    freq_d0 = freq_d0_default + drive_lo_freq
    lo_configs.append(UseLoDict({device.q[0].drive: freq_d0}))

exp_schedules, exp_lo_configs = [], []
for sched in schedules:
    for los in lo_configs:
       exp_schedules.append(sched)
       exp_lo_configs.append(los)
assert(len(exp_schedules) == len(exp_lo_configs))

execute_schedules(exp_schedules, backend, exp_lo_configs, **opts)

[taalexander]

This is coming along @nkanazawa1989 and @itoko but I think requires some major revisions with respect to schedule configuration.

Also, how should we update execute.execute to account for schedules? Thoughts @ajavadia?

[taalexander]

Could this just be registered with a class attribute upon the application of bind_instruction, rather than performing introspection of the class attributes?

[taalexander]

If this is required, should it be a more general ExpConfig or something along these lines?

[taalexander]

fyi, the above review was intended to be of Request Changes, but I misclicked.

[nkanazawa1989]

Thank you @taalexander ! I added some major changes for lo related stuff with another PR #44. I think it makes the thing more simpler.

ConditionedSchedule comes from @itoko. Of course we can pass UserLoConfig to assembler without making ConditionedSchedule. I think it is introduced to explicitly bind schedule and LO configuration.

[taalexander]

I updated the PR to remove run_config and move to passing keyword arguments as suggested by @ajavadia offline.

[ajavadia]

can you make sure the signatures of assemble_schdules and execute_schedules are grouped in the same order? for example qobj_header appears before schedule_los in one and after in the other.
The two functions should have almost identical signatures (except obvious things like execute takes a backend). After all execute is supposed to be a simpler wrapper around making a schedule, then assembling it and running it. Can you make sure there's good reason if their signatures diverge in any place?