QuTech-Delft / OpenQL

OpenQL: A Portable Quantum Programming Framework for Quantum Accelerators. https://dl.acm.org/doi/10.1145/3474222
https://openql.readthedocs.io
Other
97 stars 44 forks source link

Automatic state preparation #454

Closed anneriet closed 1 year ago

anneriet commented 2 years ago

This adds a state_prep([statevector], [qubits]) function to the Kernel, which generates and adds gates to the circuit that take the qubits from a |0> state to the state specified in the statevector. It uses some of the functions from unitary decomposition to do this.

I still need to write documentation, and I have some example/test scripts I would love to add to the project but not sure about the best approach there, since most of the python scripts in the /example folder don't currently work?

Lmk what you think, figured a pull request was as good a place to open the conversation as any :P

jvansomeren commented 2 years ago

You wrote:

I still need to write documentation, and I have some example/test scripts I would love to add to the project but not sure about the best approach there, since most of the python scripts in the /example folder don't currently work?

As far as I know, Jeroen did the OpenQL makeover after your last contribution. So please check out the (also new) documentation and especially how to set up the system since that also has changed. Compiling in unitary decomposition is an option defined in CMakelists.txt but I checked that its default is ON. To make your tests work, please checkout the most simple test scripts in the /tests directory and update yours accordingly; perhaps your idea of which options are on/off also has changed, as well as the configuration taken.

wvlothuizen commented 2 years ago

Compiling in unitary decomposition is an option defined in CMakelists.txt but I checked that its default is ON.

But it looks like compilation will fail if that option is turned off, since Kernel now calls Unitary.

Is Kernel the proper place for this functionality anyway, it seems a bit high-level with respect to other Kernel functions. And we now have two input methods: the API and cQasm, adding functionality to Kernel is not really future proof. Maybe a decomposition pass would be an option?

pablolh commented 1 year ago

adding functionality to Kernel is not really future proof

Indeed, I think both ways to give input to OpenQL should have similar functionality. And I don't think "automatic state preparation" will ever be part of cQasm, as it's too high level.

Although this is a really cool feature. I'm thinking, can't this automatic state preparation be a SEPARATE binary that produces the gates needed to achieve the input state? As far as I understand, the automatic state prep doesn't do anything that is architecture specific, just adds a bunch of universal gates. So that instead of running every time you compile, you could once generate some cqasm for state preparation, then paste it into your circuit?

That is just ideas, we can refactor/change later. I have no problem with the code as it is now. Changing where the state prep is defined/called wouldn't be too much work, I can do it later.

But it looks like compilation will fail if that option is turned off, since Kernel now calls Unitary

@anneriet did you check that? by adding the -DWITH_UNITARY_DECOMPOSITION=OFF option when you call CMake, then check that the code builds? I actually need to figure out if this is done in CI or not.

@anneriet would also love to see the tests, but we can do a separate merge, as I understand you would rather see this research work in the software now.