✨ Redesign of simulation view

[TooMuchDakka]

Problem Statement

As stated in the related UI/UX improvements issue (#28) it is rather difficult to determine the value of qubits for the various simulation runs. Additionally, the user is not able to simulate only a subset of all possible input states but rather has to simulate all possible ones.

Proposed Solution

The current view could be split into three separate ones that share the same functionality:

• Define and simulate a subset of all possible input states:

• Execute all possible input states:

• Define and simulate input states loaded from a file (Expected schema of .json file could reuse the structure currently used in the synthesis tests). A restriction in this view is that when loading simulations from a file the expected output states must be also defined:

After all simulation runs were defined, execution would present the following overview:

[TooMuchDakka]

@burgholzer Is their anything that you would like to add/remove from these mockups?

[burgholzer]

Those look good to me. What I could image that could be useful is a workflow where you do not specify the expected output, then generate the outputs from simulations, and then store that as the expected input-output mapping which could be used as a reference for testing another component with the same semantics.

[TooMuchDakka]

Those look good to me. What I could image that could be useful is a workflow where you do not specify the expected output, then generate the outputs from simulations, and then store that as the expected input-output mapping which could be used as a reference for testing another component with the same semantics.

• I am assuming that when storing expected input-output mappings created either manually or updated during the execution of the simulations (if expected outputs were not defined) that one would only be able to load these "cached" results if the future quantum computation under test potentially has the same semantics (i.e. the number of data qubits (number of total qubits - number of ancillary qubits) in the quantum computation matches the number of qubits in the cached input states while the labels of the quantum registers (and thus qubits) between the quantum register and cached input state do not need to match). Would you agree with this definitions or should the data qubit labels also match?
• Additionally, in all views one would only be able to define the value of the data qubits of a quantum computation since ancillary qubits are assumed to be initialized with zero (qubits storing integer constants are initialized in the quantum computation using X gates).
• One can cache the input-output mapping of at most one quantum computation with updates to the cache being performed via the provided views. Otherwise, an additional view to manage the cache entries would be needed.

The updated mockups of the views would now look like the following:

• Define and simulate a subset of all possible input states (one can now load/clear/save cached simulation runs and is able to delete simulation runs):

• Execute all possible input states (one can now load/clear/save cached simulation runs):

• Define and simulate input states loaded from a file (Expected schema of .json file could reuse the structure currently used in the synthesis tests). Since the loaded from file functions as the single source of truth, no interactions with the cache would be possible.

• After all simulation runs were defined, execution would present the following overview (in case that the expected outputs were not specified one would be able to cache the expected results of the simulation runs):
  • If the expected output values were defined the view shown in the issue description would be shown.
  • Otherwise, a simplified view is shown in which one is able to cache the determined output input-output values after all simulation runs have completed:

[burgholzer]

Would you agree with this definitions or should the data qubit labels also match?

I agree 👍🏼

Additionally, in all views one would only be able to define the value of the data qubits of a quantum computation since ancillary qubits are assumed to be initialized with zero

That also makes sense to me.

One can cache the input-output mapping of at most one quantum computation with updates to the cache being performed via the provided views. Otherwise, an additional view to manage the cache entries would be needed.

I would have probably not solved this with a cache, but by allowing people to save and load files. Gives a little more flexibility allows you to reuse the results from one session on another session.
So basically the "Save to file" option from the third screenshot, but for the other tabs. Does that make sense?

[TooMuchDakka]

I would have probably not solved this with a cache, but by allowing people to save and load files. Gives a little more flexibility allows you to reuse the results from one session on another session. So basically the "Save to file" option from the third screenshot, but for the other tabs. Does that make sense?

This would certainly simplify things for the better. But I wanted to clarify another issue, assuming that I have defined some simulation runs that could have also been loaded from a file then for how long should this data be available? Since we are requiring the user to manually hit the 'Save to file' button to save his changes, the currently defined simulation runs would be discarded when either closing the simulation view window (with an approriate warning that unsaved changes exist)/switching tabs in the simulation view without saving.

[burgholzer]

assuming that I have defined some simulation runs that could have also been loaded from a file then for how long should this data be available?

Good question. I would say that it is reasonable to assume that the results are only "cached" for the current tab selection and that a warning would pop up when either switching tabs or closing the window, if the window contains unsaved results. A user could then select whether to proceed without saving anyway or to save the results to a file.

[TooMuchDakka]

@burgholzer I did some prototyping and stumbled upon some potential issues with the current mockups that I wanted to check with you:

• What number of simulation runs should we assume that a user is going to check/define with the simulation view on average, if we can make such an assumption?
• Should we assume that the simulation view will primarily be used to determine the "output" values of the data qubits of the synthesized circuit or will be used as a verification tool to check expected and actual data qubit values. The latter could also be performed via the mqt-syrec python or C++ library which should also result in faster simulation run executions.
  • I am not sure whether a user would manually define a "larger" set of simulation runs (>=100 simulation runs) with the simulation view instead of loading them from a file and only make modifications from the loaded simulation runs.
• Should we place some restrictions on the tab usable to define/execute all possible data qubit value combinations since the number of potential simulation runs increases exponentially with the number of data qubits in the quantum computation?

The expected number of simulation run instances managed by the simulation view will influence the following two points:

• Currently we are only using two n_bit_values_container instances to execute all possible automatically generated simulation runs but since we now offer the user the ability to define simulation runs manually/load them from a file we might have to store a large number of n_bit_values_container instance tuples (one tuple per simulation run) if we want to reuse the data structures provided by the mqt-syrec python bindings instead of some other data structure (strings, etc.). Additionally, we need to keep in mind that the generated annotatable quantum computation could also take up quit some memory depending on the number of quantum gates it contains but this might only be an issue on less powerful machines.
• Depending on the expected number of simulation runs, some modifications of the current mockups might be needed to avoid rendering issues (lagging, etc.) but this would require some more research and prototyping on my end.

[burgholzer]

• What number of simulation runs should we assume that a user is going to check/define with the simulation view on average, if we can make such an assumption?

Fairly hard to tell in my opinion. I would guess that for up to 8-qubit functions a fully exhaustive simulation is more than feasible. Anything beyond 10 qubits is probably impractical and can be assumed to be only partial simulations.

• Should we assume that the simulation view will primarily be used to determine the "output" values of the data qubits of the synthesized circuit or will be used as a verification tool to check expected and actual data qubit values. The latter could also be performed via the mqt-syrec python or C++ library which should also result in faster simulation run executions.

I think both scenarios are equally likely. I could imagine one would generate a first set of outputs first, quickly look at them and check whether they are plausible, and then proceed with a more formal check.

• I am not sure whether a user would manually define a "larger" set of simulation runs (>=100 simulation runs) with the simulation view instead of loading them from a file and only make modifications from the loaded simulation runs.

I would guess no. I'd expect a user to manually provide a handful of inputs (+potential outputs), or to request exhaustive simulation, or to load from a file.

• Should we place some restrictions on the tab usable to define/execute all possible data qubit value combinations since the number of potential simulation runs increases exponentially with the number of data qubits in the quantum computation?

There should definitely be some practical limit. At some point, it really becomes impractical to visualize and, at that point, people might as well just use the Python package directly without the visualization.
We take a similar approach in our DD visualizer DDSIM, where the state vector is only displayed up until I think 8 qubits.

The expected number of simulation run instances managed by the simulation view will influence the following two points:

• Currently we are only using two n_bit_values_container instances to execute all possible automatically generated simulation runs but since we now offer the user the ability to define simulation runs manually/load them from a file we might have to store a large number of n_bit_values_container instance tuples (one tuple per simulation run) if we want to reuse the data structures provided by the mqt-syrec python bindings instead of some other data structure (strings, etc.). Additionally, we need to keep in mind that the generated annotatable quantum computation could also take up quit some memory depending on the number of quantum gates it contains but this might only be an issue on less powerful machines.

The circuit in question should only be stored once. So that shouldn't take too much memory.
I wouldn't worry too much about the memory of the bit containers. Yes, the memory grows exponentially, but each pair is only a linear number of bits in terms of the number of qubits.
If one is really concerned about in-process memory one could think about streaming the results to a file and adding some kind of pagination to the simulation view that only loads a subset of the results.

• Depending on the expected number of simulation runs, some modifications of the current mockups might be needed to avoid rendering issues (lagging, etc.) but this would require some more research and prototyping on my end.

This might also be solved by pagination of the view.