Recommended procedure for submitting batches

[echavarria-mqv]

What is the recommended procedure for submitting batch jobs?

Option 1: Create a QDMI_Device_Job *job that contains an entire batch (so that you can submit all circuits from a common batch at once)

Option 2: Create a QDMI_Device_Job *job that contains just one circuit from the batch (which would require submitting each circuit in separate submissions within a single session)

[ystade]

Good and interesting question, @echavarria-lrz. I would prefer the second option for two reasons:

1. as far as I know, a batch usually contains multiple jobs and not vice versa. Hence, just from the name, one job should just be one job, i.e., contain one circuit.
2. starting from the current infrastructure, I think it is easier to group multiple jobs into one batch compared to replacing the current job with another structure. For example, one could create a structure called QDMI_Batch, which is a collection of jobs. The jobs have to be created as usual, but instead of being submitted, they will be added to the batch. Then, there is a new function, QDMI_device_submit_batch, that allows the submission of a batch instead of a single job.

[echavarria-mqv]

1. I used to think about QDMI_Device_Jobs as a concept more general than just circuits. To me, a job could encompass multiple circuits, essentially serving the same purpose as a batch.

2. I also find this option interesting because it would allow submitting a QDMI_Batch containing QDMI_Device_Jobs of potentially different types. Some vendors, for example, manage calibration with a collection of scripts, each designed for different calibration procedures, with varying durations, targets, and objectives. Perhaps being able to bundle all the specific calibration procedures required at a specific moment into a single QDMI_Batch could be beneficial. (This feature might even allow for the simultaneous submission of quantum circuits and calibration jobs. However, I'm not entirely sure whether this approach would offer any real benefits.)

[burgholzer]

I generally agree with Yannick that Option 2 is most likely the preferred one here. I'd add a couple of comments though:

• a Job does not necessarily just need to be a circuit. The "payload" of a QDMI job has purposely been kept as an enumeration value. This is also how a "calibration" job is currently handled.
• the general idea of a Batch makes sense and is something that the MQSS could probably use. However, I would argue that this should not be part of the QDMI interface itself, but rather be built on top of it. Similar to a FoMaC library for the query interface, batched processing is something that I think can be built on top of the job interface. I currently see no apparent need to augment the QDMI interface for that.
• to me, it is not perfectly clear yet, whether this kind of batching is a driver-internal concept, which would mean that actual clients never see it, or whether this is something a client might actively use. My guess would be that it's rather the former than the latter. That was one of the main intentions for having separate QDMI_Job and QDMI_Device_Job classes. While the current example driver simply pipes through the jobs to the respective device, it could, in principle, perform arbitrarily complex scheduling on the device job level.
• we should keep in mind that it is a high priority for QDMI to stay as minimal of an interface as possible. If something can already be realized with the existing interface or by just adding new enumeration values, then this should be preferred over adding new types and functions.

@ystade please correct me if I am wrong, but I believe this should be possible already.

[echavarria-mqv]

Perhaps being able to bundle all the specific calibration procedures required at a specific moment into a single QDMI_Device_Job could be beneficial.

I made a mistake in my original reply, I of course meant so say QDMI_Batch instead of QDMI_Device_Job. I already edited the comment accordingly.

My guess would be that it's rather the former than the latter. That was one of the main intentions for having separate QDMI_Job and QDMI_Device_Job classes. While the current example driver simply pipes through the jobs to the respective device, it could, in principle, perform arbitrarily complex scheduling on the device job level.

I see the QDMI_Driver primarily as a message broker rather than a scheduler. I would avoid assigning a complex scheduling role to a message broker. The MQSS, for example, is intended to schedule circuit and calibration jobs before their submission, a process I find more natural than submitting first and scheduling later.

We could perhaps move the scheduling out of the QDMI_Driver like so:

Step 1: A FoMaC detects that the device's quality has dropped below a pre-defined threshold.
Step 2: The same FoMaC compiles a list of n calibration procedures that need to be triggered to solve all current issues.
Step 3: The Submitter receives an alert, obtains this list from the FoMaC and, acting as a QDMI_Client, submits n individual QDMI_Jobs to the QDMI_Driver.
Step 4: The QDMI_Driver consumes those n QDMI_Jobs, bundles them into a single QDMI_Device_Job, and then dispatches it to the QDMI_Device.

we should keep in mind that it is a high priority for QDMI to stay as minimal of an interface as possible. If something can already be realized with the existing interface or by just adding new enumeration values, then this should be preferred over adding new types and functions.

While I agree with this statement, I also believe that integrating @ystade's proposed QDMI_Batch structure into the QDMI specification would add significant value.

@mnfarooqi: Based on the experience you gained while implementing the LRZ's QDMI_Driver, what are your thoughts on all of this?

[mnfarooqi]

I will state my understanding of the why, what and how here, so that you can correct me if I have misunderstood.

Motivation:
Submitting a batch of circuits can be beneficial as some device vendors can do optimisation when a number of circuits are submitted together.
So the purpose of a batch in the interface is to let the device vendors know that a set of circuits is part of a batch.

Problem:
A batch can mean one of two things, one is a batch of jobs, where each job has a circuit (program) that can have its own format and number of shots, and the other is a batch of circuits (programs) in a single job, as is the case in Qiskit.
My understanding is that we want a solution for the latter case?

Solution:
There are two ways to solve the problem that will not break the existing interface

1. as suggested is to add QDMI_Device_Batch (device interface) and QDMI_Batch (client interface) opaque pointers. Also, QDMI_device_batch_add_job, QDMI_device_submit_batch functions and possibly QDMI_device_cancel_batch ... or
2. add an enumeration QDMI_DEVICE_JOB_PARAMETER_PROGRAMNUM that specifies the number of circuits (programs) in a job that can be submitted by calling QDMI_device_job_set_parameter with QDMI_DEVICE_JOB_PARAMETER_PROGRAM that many times. e.g.

QDMI_device_session_create_device_job(session,&job)
QDMI_device_job_set_parameter(job, QDMI_DEVICE_JOB_PARAMETER_PROGRAMNUM, sizeof(size_t), 2)
QDMI_device_job_set_parameter(job, QDMI_DEVICE_JOB_PARAMETER_SHOTSNUM, sizeof(size_t), 1024)
QDMI_device_job_set_parameter(job, QDMI_DEVICE_JOB_PARAMETER_PROGRAMFORMAT, sizeof(QDMI_Program_Format), QDMI_PROGRAM_FORMAT_QASM2)
QDMI_device_job_set_parameter(job, QDMI_DEVICE_JOB_PARAMETER_PROGRAM, circuit1.size(), circuit1.c_str())
QDMI_device_job_set_parameter(job, QDMI_DEVICE_JOB_PARAMETER_PROGRAM, circuit2.size(), circuit2.c_str())
QDMI_device_job_submit(job)

I would vote for the enum option to keep the changes to the interface as minimal as possible, the other option can also be added later if some use cases emerge.

[Gistbatch]

Hi,
from my pov. having a QDMI_Batch has significant value when scheduling. In the worst-case scenario where a device can not deal with a batch, we can still "unbatch" and submit individual jobs.
The first option @mnfarooqi mentioned, i.e. different circuits of different lengths would be also useful if we want to optimize the utilization of the device, although I'm not sure if the hardware can deal with a "per shot" reconfiguration if we have different parameters.

@echavarria-lrz for scheduling this is a general question I had. How much logic should be in the driver? I'm currently building a simple scheduling setup over RPC which has the scheduling logic outside of the driver, using the existing example driver to just forward jobs to the correct device.