You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
from numpy import gradient
import pennylane as qml
from pennylane import qchem
from pennylane import numpy as np
from functools import partial
from time import perf_counter
# Build the electronic Hamiltonian
symbols, coordinates = (['H', 'H'], np.array([0., 0., -0.66140414, 0., 0., 0.66140414]))
h, qubits = qml.qchem.molecular_hamiltonian(symbols, coordinates)
# Number of electrons
electrons = 2
# Define the HF state
ref_state = qchem.hf_state(electrons, qubits)
# Generate single and double excitations
singles, doubles = qchem.excitations(electrons, qubits)
# Map excitations to the wires the UCCSD circuit will act on
s_wires, d_wires = qchem.excitations_to_wires(singles, doubles)
# Define the device
dev = qml.device('lightning.qubit', wires=qubits)
# Define the UCCSD ansatz
ansatz = partial(qml.UCCSD, init_state=ref_state, s_wires=s_wires, d_wires=d_wires)
# Define the cost function
cost_fn = qml.ExpvalCost(ansatz, h, dev)
# Compute the expectation value of 'h' for given set of parameters 'params'
params = np.array(np.zeros(len(singles) + len(doubles)), requires_grad=True)
print(cost_fn(params))
opt = qml.GradientDescentOptimizer(stepsize=0.4)
max_iterations = 100
conv_tol = 1e-06
energy = [cost_fn(params)]
for n in range(max_iterations):
start_time = perf_counter()
theta, prev_energy = opt.step_and_cost(cost_fn, params)
energy.append(cost_fn(theta))
conv = np.abs(energy[-1] - prev_energy)
#if n % 2 == 0:
print(f"Step = {n}, Energy = {energy[-1]:.8f} Ha")
if conv <= conv_tol:
break
print("\n" f"Final value of the ground-state energy = {energy[-1]:.8f} Ha")
Results in the following error traceback:
Traceback (most recent call last):
File "/Users/joelbierman/Desktop/pennylane/tutorial_vqe.py", line 26, in <module>
dev = qml.device('lightning.qubit', wires=qubits)
File "/Users/joelbierman/miniforge3/envs/pennylane-test/lib/python3.9/site-packages/pennylane/__init__.py", line 297, in device
plugin_device_class = plugin_devices[name].load()
File "/Users/joelbierman/miniforge3/envs/pennylane-test/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2472, in load
return self.resolve()
File "/Users/joelbierman/miniforge3/envs/pennylane-test/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2478, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/Users/joelbierman/miniforge3/envs/pennylane-test/lib/python3.9/site-packages/pennylane_lightning/__init__.py", line 17, in <module>
from .lightning_qubit import LightningQubit
File "/Users/joelbierman/miniforge3/envs/pennylane-test/lib/python3.9/site-packages/pennylane_lightning/lightning_qubit.py", line 48, in <module>
from .lightning_qubit_ops import (
ImportError: dlopen(/Users/joelbierman/miniforge3/envs/pennylane-test/lib/python3.9/site-packages/pennylane_lightning/lightning_qubit_ops.cpython-39-darwin.so, 2): no suitable image found. Did find:
/Users/joelbierman/miniforge3/envs/pennylane-test/lib/python3.9/site-packages/pennylane_lightning/lightning_qubit_ops.cpython-39-darwin.so: mach-o, but wrong architecture
/Users/joelbierman/miniforge3/envs/pennylane-test/lib/python3.9/site-packages/pennylane_lightning/lightning_qubit_ops.cpython-39-darwin.so: mach-o, but wrong architecture*
Setting "default.qubit" instead of "lightning.qubit" for the device works fine. There seems to be an issue with the lightning builds.
In the past when I have encountered this sort of error for other packages, it was because while the wheel names indicated that they were built for arm64, the actual wheel contents contained code compiled to x86. My guess is that there's something buggy with the build process for these published wheels.
The text was updated successfully, but these errors were encountered:
Hi again @JoelHBierman
We can reproduce the error locally. The issue seems to arise from the builder we are using for the wheels being unable to correctly output ARM64 targeted binaries, as we build using GH Actions. We are looking into a strategy to fix this, but as an interim we can suggest the following:
Install the XCode command line tools and C++ compiler
The next release of PennyLane (v0.24) will arrive on Tuesday 21st June. The above mentioned fix will be available as of that release. I will close this issue now, but feel free to reopen if there are any updates you would like to share.
Issue description
Running the following code:
Results in the following error traceback:
Setting
"default.qubit"
instead of"lightning.qubit"
for the device works fine. There seems to be an issue with the lightning builds.Expected behavior:
No ImportError
ImportError.
100%
Source code and tracebacks
See above.
Additional information
In the past when I have encountered this sort of error for other packages, it was because while the wheel names indicated that they were built for arm64, the actual wheel contents contained code compiled to x86. My guess is that there's something buggy with the build process for these published wheels.
The text was updated successfully, but these errors were encountered: