-
Notifications
You must be signed in to change notification settings - Fork 65
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
Delete summing constraint in DetuningMap #610
Conversation
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
@a-corni thank you for this PR. Can I ask why exactly this constraint has been lifted? Is it not valid anymore? |
It has in fact never been valid, @Lassabliere just realized that there had been a misunderstanding while discussing with a user who was telling him about this constraint. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@a-corni I am not in favor of fully removing the constraint on the weights. The alternative solution discussed offline might be more appropriate. For what concerns the actual changes in this PR, they look correct to me.
@madagra everything should be now tackled. @Lassabliere, bottom_detuning in notebook and devices is updated to -20 * 2 * pi rad/µs and global bottom detuning is -2000 * 2 * pi rad/µs. In the end we don't have to delete the condition of the sum of the weights being equal to 1, we only need a constraint on the local detuning and a constraint on the global detuning. However, I think this implementation will help the user since it will be closer to how Local channels used to work (with weights equal to 1 or 0, you can define directly the detuning you want to apply on each qubit), even though this is making us drive away from the initial concept of a Global channel (where the detuning defined by the user should be between |
It won't be very user-friendly to work with weights. For example, if you're working with 30 atoms and you have a DMM with a total available light shift of -2pi x 2000 MHz. In general, we want to work with detunings of the order of - 2pi x 1 MHz on the atoms, so you need to set very small weights [0.0005, ....]. Why don't you want to work with an additional term |
Hey @Lassabliere, There might have been a misunderstanding with my previous message. I definitely agree with your point, and your example highlights it very well 😄 Indeed the former implementation (defining the total lightshift applied on the qubits, applying on it weights whose sum is equal to 1 to obtain the detuning applied on each qubit) has the issue that the weights will be small if the number of atoms that have to receive light is large (to apply a detuning of -2pi rad/µs on each atom, you need to define a waveform with detuning -2pi30 rad/µs and a DetuningMap with weights Now the implementation under scrutiny here defines weights indeed, but that will generally be close to 1. To perform the operation you describe, we now send a waveform of detuning -2pi rad/µs on a DetuningMap with weights 1 on each atom, and we now internally check that |
My bad, I didn't read everything carefully. It looks fine for me! |
pulser-core/pulser/json/abstract_repr/schemas/device-schema.json
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still need to review part of the changes but I wanted to get these comments out of the way first so we can discuss them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@a-corni it looks good to me now, I will leave @HGSilveri to give the final approval.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell we still need to be more thorough with the abstract representation tests (especially if we are to try and maintain backwards compatibility)
call.name == "config_detuning_map" | ||
or call.name == "config_slm_mask" | ||
): | ||
# Check whether dmm_name matches with channel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that nothing happens if there is no match though, is that intended?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really okay that we are failing silently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's would say it's not supposed to fail: the channel has been tested by validate_channel
before being as being in declared_channels
, and declared_channels
is exactly built by looping over the calls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, good enough for me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, let's add an assert in that case to ensure the detuning map is always found
@HGSilveri my modifications are ready for review :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Final remarks :)
call.name == "config_detuning_map" | ||
or call.name == "config_slm_mask" | ||
): | ||
# Check whether dmm_name matches with channel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really okay that we are failing silently?
I forgot to comment on this: I think it's too noisy, I'd be more in favor of adding a note in a docstring signaling this change. |
Yes in the end I think it's irrelevant, let's just keep it this way isn't it ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, LGTM!
Main changes: a0c59a6 Deprecate legacy devices (#620) b18e434 FIX: Detuning modulation for custom EOM buffer time (#619) 8c5d966 Delete summing constraint in DetuningMap (#610) b41d62a JSON serialization support for numpy integer types (#617) 9f9a17a Fix temperature initialization in SimConfig (#606) 2bad427 Fix spacing in register.max_connectivity (#605) 581886f [FIX] Allow parametrized phase in EOM mode (#599) 394fe6a Add `wait` option to remote backends (#598)
Deleting the condition "sum of weights = 1" in DetuningMap.
Condition is replaced by "weights are between 0 and 1".
Impacts the creation of the DetuningMap associated with an SLM (used to be with weights = 1/(#number of masked qubits), is now created with weights = 1 for masked qubits, 0 otherwise).
Notebooks are updated.
Is proposed to be a hotfix to advertise about this change among the developers.
Possible Improvement to this PR: To really make people aware that the summing constraint has been lifted, we could show a DeprecationWarning if the sum of the weights is equal to 1 ?
Fixes #609