Composite experiment with existing sub-experiments about qiskit-experiments HOT 8 CLOSED

I think it is going outside the intent of composite experiments. Composite experiments are intended for batching experiments together in a single execution.

If you want to do analysis of data from multiple experiments such as Q3 T1 from a single experiment, and Q3 T1 from a parallel experiment you should probably manually combine the relevant experiment data objects after the separate experiments have been run and then re-run run analysis on the joint data (im not sure if this combining of experiment data is implemented yet though).

from qiskit-experiments.

Need to define a policy, what are the constraints when the experiment_data parameter of run is not None, with an exception when one of the constraints is violated.

from qiskit-experiments.

In this issue, do we want to address CompositeExperiment or regular Experiment when their parameter ExperimentData is not None? or both cases?

from qiskit-experiments.

I think BaseExperiment, which includes also CompositeExperiment

from qiskit-experiments.

I'll start a list here of properties we would like to check:
For composite experiments, need to check the following:

• Same experiment type (already checked in ExperimentBase)
• Same physical qubit(s) (already checked in ExperimentBase)
• Same p0 for analysis_options (if not None)

For parallel experiments, need to check the following:

• Experiments on different qubits
• Do we want to raise a warning for experiments on adjacent qubits (depending on the device)?

Feel free to add additional items we should check.

from qiskit-experiments.

General comment: currently we have a handful of implemented experiments. When that list grows, maintaining the checking logic of composite and parallel experiments can become complex and burdening, as there might be unique compositing constraints for certain experiments and not the others, contradicting constraints and other complications hard to predict now.

So I think we should decide which approach we are taking at this stage:

1. Performing vary basic checks - those which are generic and experiment oblivious and are common to all experiments
2. Develop a mechanism by which each experiment exposes its compositing constrains, and the framework classes handle those generically and yield a warning/error if constraints are violated.

I think at this stage we should go with the simple approach (#1), and support just the bare minimum checks for proper compositing.

from qiskit-experiments.

@merav-aharoni @eliarbel Can we close this issue?

from qiskit-experiments.

@yaelbh , In my opinion, we can close the issue. It makes more sense to me to provide checks per development item, as needed.

from qiskit-experiments.