Reduced Density matrix Interface

[weinbe58]

Reduced Density matrix

Defining the subsystem

I think we can all agree that the subsystem should be defined in terms of a label that includes the register's name and/or the qubit index inside that register:

qubit_id = QubitId(reg: str, index: int)
register_id RegisterId(name: str)

which can be easily validated concerning the kernel being executed.

Task level interface vs Simulation State level interface

I would prefer to have a task-level interface for this because ideally, the task is what defines how a kernel is executed. For example if the task has not been executed How do I interpret the following?

task = sim_device.task(kernel, args, kwargs)

ids = [RegisterId(...), QubitId(...), ...]

task.state.rdm(ids)

in this case since state is a property indicating that this is the state of the system before executing the kernel because the task.run() method has not been called. in this way one would need to do the following actually to extract the rdm:

task.run()
task.state.rdm(ids)

I think this implementation is also redundent because it puts the runtime implementation into state versus putting the logic inside the task object which would circumvent all of the related task infrastructure. Task holds the responsibility for executing the computation state is just a way of extracting the underlying implementation of the task for Power users who understand how the runtime works.

if we work with task owning the implementation of the calculations then it becomes clear that task.rdm(ids) is the correct interface.

[jon-wurtz]

I was chatting with @Roger-luo about exactly this on Friday. I think its okay behavior to either
a) have the state be None (or some other empty state) before run(), or
b) A call to the *.state attribute forces the program to run() first before returning the state-- aka caching.

Nonetheless, I think *.state and *.rdm might be two ways around the same requirement-- after all, *.rdm("all") can just return the global state vector. state might be an object with extra information-- for example, history of mid-circuit measurements. Maybe task.rdm(*) is just an alias for task.state.rdm(*).

Either way, the output would be a state vector, which can still (must) have a method of state.rdm() to further project the wavefunction.

[weinbe58]

The problem I have is that if you store all the methods inside the state you don't need the task anymore. everything is basically just task.state.* with the exception of task.run(). In this case why not just have task.state.run() and then every method is now you can replace task with state and we're left with task.state as the object that has the API.

[Roger-luo]

I think what @weinbe58 want here for rdm is slightly different because of the noise simulation - you want a different convention of run here to run the simulation in batch mode and average on the result. Note that some simulator has the batching option that is not just simply run the circuit multiple times but instead actually run the batch in parallel. So that deserves some special treatment here as a special convention of run. So rdm may need an extra option like rdm(n_batch=100) which runs the circuit in batch mode and average over 100 samples of noise.

[weinbe58]

Another reason why this needs to be in the task and not the state is because the task contains the kernel and the kernel has all the information about the names of the register and the size of the registers so in that sense it is required to make this work, the internal simulator state may or may not need the kernel to run, for example if the runtime is done via code-generation the state has nothing to do with the user kernel to begin with.

[weinbe58]

@jon-wurtz can we schedule a meeting to discuss this further or are you OK with just leaving the method to task?

[jon-wurtz]

I see your points here, they make sense. A task.state should have more information associated with it than just the state vector (or list of state vectors associated with every seed). For example, the time the task was completed, the final values of variables within the scope of the top-level kernel, the temperature of the CPU during execution, whatever. And pythonically, this would need to be its own object TaskState in order to work. But, I think that should be the case-- the Task is after all separate from the instantiation of the task (TaskState)-- and the quantum state is one particular part of the TaskState. Contrastingly, they are so similar that we "might as well" keep them the same object.

Ultimately, we need to be able to extract information from the task (or the state?). When Roger and I originally proposed task.state it was just returning the StateVector, but now I'm increasing the scope in confusing ways. Perhaps task.state can be a list of individual instantiations of task execution (single shots on hardware, seeds for noise) while other methods (task.rdm(), task.result, task.bitstrings, etc.) can then transpose that data to select only that field of each individual task. (transpose <=> task.state[i].bitstring <=> task.bitstrings[i].

[Roger-luo]

I don't quite understand the comment here, so do you still against task.rdm() or not? if you agree with Phil could you guys write a RFC on what rdm should look like together?

[weinbe58]

I think this is far more complicated than it needs to be. Every task supports the execution of the kernel, that it if your simulator has a state vector it has a task.state_vector() method to calculate the state vector. if it's a stabilizer simulation you can't have the state_vector method but maybe you can calculate the reduced density matrix or calculate Pauli expectation values, etc.

[jon-wurtz]

I see task.rdm() as an alias for the quantum state. The reduced density matrix should be a property of the quantum state and not the task. But then if you do want the state, you could just call task.rdm() to get the state across all qubits. And so, the following code is equivalent:

task.rdm("qubit17")
task.rdm().rdm("qubit17")
task.quantum_state().rdm("qubit17")

Here, task.rdm() returns the whole quantum state (or some efficient representation, outer product, whatever, implementation details?) and then the state also has a method to get the reduced density matrix as well. Note that the state could be several different (interoperable?) representations: StochasticWavefunction, DensityMatrix, TensorNetwork, StabilizerTableau, etc. So then task.rdm() becomes redundant, but sure def rdm(*args): return self.quantum_state().rdm(*args) is a handy shorthand.