search

pasqal-io / qadence-libs

A collection of libraries to enhance Qadence functionalities.
https://pasqal-io.github.io/qadence-libs/latest/
Apache License 2.0
6 stars 2 forks source link

[Fix] Add the omega term to Rydberg Feature Map Hamiltonian #15

Open smitchaudhary opened 6 months ago

smitchaudhary commented 6 months ago

Currently, the rydberg_feature_map here does not pass any value for omega to AnalogRot which then defaults to 0.

Thus, the Hamiltonian for the Feature map turns out to be something like:

H/h = ∑ᵢ( - δnᵢ) + Hᵢₙₜ.

And with the interaction term being an NN term, this means the Hamiltonian has no driving term at all. Which would mean, if the state that this block gets is the zero state, then nothing drives the state to other states, and we would be left in the zero state.

Considering this is the feature map, we are pretty likely to start with zero state. Thus, it would fail to encode the feature at all.

Need to provide an appropriate driving term to the feature map.

jpmoutinho commented 5 months ago

Hey @smitchaudhary, thanks, I now properly processed the information here.

Like I mentioned yesterday I do think this rydberg_feature_map and analog rotations need a proper review. But as as quick fix I think it's ok to add the drive term.

Do you have a suggestion on the best way to do it? E.g. I don't know if it should use the same weights values or a separate set, or if it should just replace the usage of the detuning term or use both.

smitchaudhary commented 5 months ago

if it should just replace the usage of the detuning term

@jpmoutinho I think this might be the simplest way to handle this. Can continue to have the different weights for different qubits, just like it currently happens for detuning.

In addition, how do you feel about the function taking the value of the phase as an optional argument? This in the rare case that the state just preceding the feature map becomes an eigenstate of this newly defined Hamiltonian? It can default to 0 as it currently does but maybe user can specify if the need be.

smitchaudhary commented 5 months ago

In addition, how do you feel about the function taking the value of the phase as an optional argument? This in the rare case that the state just preceding the feature map becomes an eigenstate of this newly defined Hamiltonian? It can default to 0 as it currently does but maybe user can specify if the need be.

Actually this might be unnecessary. I forgot about the interaction part of the Hamiltonian. For now, there is no need to bloat this function. When we do a proper redesign of this workflow, we can look into it again.