backend.validate(qobj)

[jaygambetta]

I would like to have a command to check that a qobj can be run on a backend.

I want to be able to go

val_test = backend.validate(qobj) 

and what this does is sends this to the backend and the backend does some simple checks.

1. All the instructions are in its gate set or allowed by the connectivity
2. is the number of circuits small enough
3. the depth is not too long

I am not sure about the return type I would personally like this to be a token and then

backend.run(val_test) 

would run the same way as a qobj.

This is requested by many now and is a lot of the questions we get so I would like to have some solution for this.

[jaygambetta]

@nonhermitian can you add to this the requests you have received about this as well.

[diego-plan9]

For Aer, most (if not all) of the simulators do have a private backend._validate() method which we can "promote" to a first-class citizen indeed.

I'm more curious about the remotes, which are arguably the ones where this validation provides real value. Does it basically imply that we need help from the API (ie. a new endpoint) in order to perform those simple checks, to avoid hard-coding values and make it easier to adjust to changes in the limits of the devices, or are you thinking of something that can be done fully locally?

[jaygambetta]

I think this needs to call the remote.

[ewinston]

It looks like the information needed could be retrieved when the provider identifies backends. Could it be conveyed between configuration and properties?

[jaygambetta]

I don't think so I would like to run a small calculation before we add it to queue to see that it would run.

[delapuente]

This is tracked in #871: an outgoing Qobject must pass two schema validations (that can be generalized to two general validations).

Anyway, @jaygambetta, I would want to understand what are the advantages of providing this "try and send" workflow instead of the simpler: backend.run(circuit)?

[jaygambetta]

this is not a schema validation. It is a resource calculation on the qobj that depends on the backend. Ie if i'm hardware that only support 1000 gates it will say the qobj will not run.

For the Clifford simulator, it would check all that gates are Cliffords.

There are things we can do that don't waste the time off being in the queue that will let you know the job will fail or not be useful. currently, we let it run and it errors and then we return an error.

[ajavadia]

Other examples of backend.validate() (i.e. things that cannot be checked with schema):

• For some devices and simulators, check all measurements are at the end.
• Check local hardware spec and give a warning if it cannot handle an Aer simulation (too many qubits, circuit too deep).
• For hardware that supports feedback, some estimate of the feedback time can be included (on top of just depth). This can be contrasted with the T1 to ensure sanity.

[delapuente]

Pinging @pacomf @jelcaf @francabrera to make them aware of this proposal.

[pacomf]

Yes, I think that we need a microservice in the cloud to check these things of the qobj

[jaygambetta]

closing with #4105