You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Goal is to "modernise" QuantumInstance and run_circuits logic for execution of circuits on the backend given advances in capability of Terra and IBM Q Provider since some this aforementioned logic was written. This includes areas such as
Moving over to use of the ibm q job manager when the remote provider is IBM Q.
More reliable operation with backend Qiskit/qiskit-aqua#910
And in conjunction with 3 above perhaps looking to allow a job to be cancelled and resubmitted on behalf of an algorithm when the job seems to be stuck. Not sure how much this is catered to in 1 above. But since a variational algo can send in many jobs having it get stuck as it progress and having to restart the entire algo is less than desirable. Auto-recovery needs to be looked at but maybe it (also) can be done in conjunction with some user supplied code in a the job monitor callback which would signal to cancel/retry.
Algorithms can require multiple circuits; since there is a backend limit on experiments per job currently they are split into multiple jobs if the limit is exceeded. Some like QuantumKernel do a circuit for each data pair and group by a batch size. If the grouping is more for execution efficiency rather than algorithmic reasons it might be better to inform such grouping via the QI rather than expect an end user to know things like max experiments and have to configure things manually (in QK case via some batch size param)
Goal is to "modernise" QuantumInstance and run_circuits logic for execution of circuits on the backend given advances in capability of Terra and IBM Q Provider since some this aforementioned logic was written. This includes areas such as
These are related to improving execution etc too
The text was updated successfully, but these errors were encountered: