Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for arbitrary QuInstruct buildings and analog IR #8

Open
Doomsk opened this issue Nov 4, 2024 · 7 comments
Open

Add support for arbitrary QuInstruct buildings and analog IR #8

Doomsk opened this issue Nov 4, 2024 · 7 comments

Comments

@Doomsk
Copy link
Member

Doomsk commented Nov 4, 2024

Current IR implementation does not allow to build some valid arbitrary expressions for PyQTorch, for instance the following code works with pyqtorch and qadence:

import torch
from qadence import X, N, Z, PI, HamEvo
from qadence import expectation, add, Register, FeatureParameter
from qadence.analog.constants import C6_DICT

n_qubits = 2

# We will work with Pulser units, so we have to define the C6 value, here for rydberg level = 60
C6 = C6_DICT[60] # 865723.02

# Defining a constant amplitude pulse where the duration encodes the angle of rotation
omega = torch.tensor(PI)
delta = torch.tensor(0.0)
phase = torch.tensor(0.0)
duration = (FeatureParameter("theta") / omega) * 1000.

# With these values, we only get a term in X
h_x = (omega / 2) * torch.cos(phase) * add(X(i) for i in range(n_qubits))

# We will vary the angle of rotation between 0 and 2pi
theta_vals = torch.arange(0, 2 * torch.pi, 0.01)

# Now we can show the effect of the interaction term by changing the distance between the qubits
distance = 8.0
h_int = (C6 / distance**6) * (N(0) @ N(1))
evolution = HamEvo(h_x + h_int, duration / 1000.)
rotation_close = expectation(evolution, observable = Z(0), values = {"theta": theta_vals}).squeeze().detach()

Proposal

Enable arbitrary expressions in a high-level IR, and restricting them only when going down the pipeline for analog expressions in an analog IR.

ping @pimvenderbosch @RolandMacDoland @jpmoutinho @kaosmicadei

@kaosmicadei
Copy link
Contributor

I agree. As discussed with Roland last Friday (01.11), the arbitrary Hamiltonian needs an abstraction level for itself above the current structure.

This was the original purpose of the Symbolic Analysis tools. It turned out to be more complex than that.

@RolandMacDoland
Copy link
Contributor

This feels about right to me. However, we can't really afford to do that now (unless we're faster on what we do now). We need to add it for when we're OK with the current solidification of the code. @Doomsk @kaosmicadei Could you please add it in some Notion page for later reference ?

@kaosmicadei
Copy link
Contributor

kaosmicadei commented Nov 5, 2024

I don't think this could be done fast. I think this could be the next step with the IR and the multi-level discussion—that will also include some rethinking on the IR as the one mentioned by @pimvenderbosch in #9

@RolandMacDoland
Copy link
Contributor

I don't think this could be done fast. I think this could be the next step with the IR and the multi-level discussion.

Fully agree. When I meant "fast" it was supported to mean our current work but I wouldn't rush anything by any means.

@kaosmicadei
Copy link
Contributor

For now, it will not possible to give support to arbitrary Hamiltonians.

However, the particular example presented here could be written in Qadence 2 using the NativeDrive operator.

theta = variable("theta")
duration = theta / pi
omega = 0.5
detuning = 0.0
phase = 0.0

expr = NativeDrive(duration, omega, detuning, phase)

set_qubits_positions([(0,0), (0,1)])

The main with give support to arbitrary Hamiltonians is to ensure they can break into NativeDrives

@RolandMacDoland
Copy link
Contributor

RolandMacDoland commented Nov 5, 2024

Alright, I think we definitely need to clarify what is possible and what isn't. Because it's still unclear where to draw the line. Then, we need to document it.

@jpmoutinho
Copy link

Like I discussed with @Doomsk this morning I don't think adding support for this is necessarily a priority. I would just replicate the example with the NativeDrive like @kaosmicadei suggested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants