How do you stack QSE with other error mitigation methods using the decorator?

[gachchami]

Hello there,

This discussion is created following the discussion thread on discord. https://discord.com/channels/764231928676089909/1227280999004766208

In the mitiq paper an example for stacking mitigation strategies is described.

The exector for qse is defined in the follow manner.
https://github.com/unitaryfund/mitiq/blob/v0.35.0/docs/source/guide/qse-1-intro.md#2-define-an-executor

Based on the above documentation we tried the below code.

@qse.qse_decorator(check_operators=check_operators, code_hamiltonian=code_hamiltonian, observable=observable)
@zne.zne_decorator(observable=observable)
@pec.pec_decorator(representations=pauli_representations, observable=observable)
@ddd.ddd_decorator(rule=rule, observable=observable)
def execute(circuit):
    return compute_density_matrix(
        circuit.with_noise(cirq.depolarize(p=0))
    )
print(execute(circuit))

This seems to fail with the error.

ValueError: Executor and observable are not compatible. Executors
                returning expectation values as float must be used with
                observable=None

this error is happening as the mitigate_executor that the decorator is calling is "changing the prototype of the executor we are defining. as we go through the stack we notice that all of this depends on type hints to ensure that the decorator has the prototype expected.

I would recommend discussing in this thread "how" to use the decorator to stack. If it is not possible today to stack then how to make it easy to identify which mitigations can be stacked together.

Thank you for your kindness in spending the time to reply.

[gachchami]

Tagging @bubakazouba who was involved in the original submissions of QSE and the decorator code (according to git blame) to get the persons views.

[purva-thakre]

Hi @gachchami, there is a similar open discussion on this. #2267 (comment)

As stated previously in our Discord discussion, the way you define your excecute function is causing issues with how you are stacking the techniques. For ZNE, PEC, and DDD, we have to define execute to return an expectation value whereas for QSE, the function is typically used to return a density matrix with some additional steps later for the expectation value. Your execute currently returns a density matrix but the qse_decorator expects to return a float.

Yes, we have open issues to update the documentation on how techniques could be stacked.

[natestemen]

Thanks for the question! We clearly have not figured out a great way to show users who are not intimately aware of the needs/requirements of these techniques what they are. As @purva-thakre mentioned in her reply, we are going to add some documentation about stacking techniques, but if you have any ideas about how we can make it more clear which techniques can be stacked or what errors to throw we'd greatly appreciate it!

[jordandsullivan]

If I could add a suggestion here, I think it would help a great deal to add type checks to each QEM method, in addition to the existing type hints. i.e.

if not isinstance(var, type):
    raise TypeError(f'var must be of type {type}')

Even when combining different techniques without using decorators, it can be difficult to tell which types are supported as input and which returned as output for different executors. If we added type checks (perhaps even running a test input to an executor to check what it returns?), it would be harder to end up with mismatching input/outputs when stacking techniques.

[gachchami]

I am assuming here that when some mitigation strategies throw this error that they are semantically different and hence stacking them does not make sense.

If that is true than I believe an error message like "you are stacking X and Y Mitigation strategies and they are not stackable" would be more prudent. Instead the current error message says "You are passing some variable to your decorator and hence something didn't work". this second error message leaves you with a hope that you can still stack them, just not the way you are doing right now.

I think we could build a static compatibility map that can be maintained based on the semantics of the mitigation strategy and then during stacking if this compatibility is violated then we fail early and more clearly.

[natestemen]

I really like the idea of of providing users with a very clear message of what the problem is like you've suggested. Currently, I'm not sure we have a way of knowing when techniques are being stacked in order to provide an error message like that. When stacking all the individual functions know is what the are taking in as input, but not the broader context of the "error mitigation pipeline".

It would be a bigger project, but adding some sort of ErrorMitigationPipeline class where the user adds multiple techniques could be a solution to this problem.

[natestemen]

static compatibility map

I like this idea, and I think this will be included in the documentation we are going to add in #2288.

[gachchami]

I was thinking about using this static map to check whats already in the decorator stack. (the decorators can be made to add themselves to the decorator stack to ensure we know what came before).

[natestemen]

Ah so are you saying create a global variable in Mitiq DECORATOR_STACK, and then have each xxx_decorator function append to the stack? Then when any execute_with_xxx is called, it checks to see what is in the stack to check for compatibility?

[gachchami]

I was thinking we could patch it into the executor. Let me do some experiment on this and get back.

[purva-thakre]

I think we could build a static compatibility map that can be maintained based on the semantics of the mitigation strategy and then during stacking if this compatibility is violated then we fail early and more clearly.

@gachchami Thank you for this feedback. Yes, one of the reasons why I created #2288 is to make it clear which techniques could be stacked and which ones could not be stacked. I figured once I have all the data, I will add some RaiseError lines in the method executors.

I am not familiar with a 'static compatibility map'. Could you please provide more information on how this might work?

[gachchami]

What I mean by static compatibility map is just a json/dict that maintains the map of what is compatible with what.

While the decorators are being built (in the closure) we can maintain a stack(list) of previously stacked mitigations. This way the current decorator can check if something is incompatible in the stack and then fail early.