-
Notifications
You must be signed in to change notification settings - Fork 66
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
Abstract representation support for new DMM features #568
Conversation
HGSilveri
commented
Aug 2, 2023
•
edited by a-corni
Loading
edited by a-corni
- Update serializer and deserializer for devices with DMM channels
- Write UTs for DMM channel serialization
- Update to the preliminary device JSON schema (should be updated before merging)
- Update serializer and deserializer for the sequence using detuning map modulation (not tested so there could be bugs)
- Write UTs for sequence serialization and deserialization with detuning map modulation
- Update to the final sequence JSON schema
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 can see how the order at which the DMM channels are configured can be a thorny issue...
for dmm_name, ser_det_map in obj["dmm_channels"]: | ||
splitted_dmm_name = dmm_name.split("_") # dmm_id_num | ||
dmm_id = "_".join(splitted_dmm_name[0:2]) | ||
call_num = ( | ||
0 if len(splitted_dmm_name) <= 2 else int(splitted_dmm_name[2]) |
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 think this is overly reliant on the conventions in the code. If we have to, we should rather include the information on both the dmm_name
and the dmm_id
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.
Okay I also felt that we should include the information on both the dmm_name and the dmm_id. It's just that since we decided to label the dmm_name as dmm_id_{number of time dmm has been declared} I figured I had all the information dmm_name...
if dmm_id not in to_config_det_map: | ||
to_config_det_map[dmm_id] = {} | ||
to_config_det_map[dmm_id][call_num] = ser_det_map | ||
|
||
for dmm_id, ser_det_maps in to_config_det_map.items(): | ||
slm_mask_dmm = None | ||
call_nums = list(ser_det_maps.keys()) | ||
# If an SLM Mask has been defined, an iteration will be taken | ||
for i, call_num in enumerate(call_nums): | ||
if call_nums != i: | ||
slm_mask_dmm = i | ||
# Have to wait for the SLM Mask to be configured to finish | ||
# configuring the last Detuning Maps | ||
for call_num, ser_det_map in ser_det_maps.items(): | ||
if slm_mask_dmm is not None and call_num >= slm_mask_dmm: | ||
break | ||
det_map = _deserialize_det_map(ser_det_map) | ||
seq.config_detuning_map(detuning_map=det_map, dmm_id=dmm_id) |
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 think I understand the need for all this complexity, but I'm hoping we can find a better solution
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.
Well now I am thinking that everything would be solved by taking "config_detuning_map" as an operation instead of putting in "detuning_map". What do you think of this ? Eventually if we are attached to having the information regarding the configured detuning map in the schema I can have both.
Other idea: I pass the slm_mask_dmm, this provides the number of times the dmm used for the SLM can be configured here, and the last configurations are performed after the SLM is configured (all I am doing here is very much to identify what is the dmm_id used for the SLM and when should the configuration of the SLM happen compared to the configuration of this dmm_id)
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 think you're right, we should probably deal with it like a regular operation
self, detuning_weights: Mapping[QubitId, float] | ||
self, | ||
detuning_weights: Mapping[QubitId, float], | ||
slug: str | None = None, |
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.
The slug is missing a description in the docstring (here and in other define_detuning_map
methods.
_Call( | ||
"config_detuning_map", (dmm_name, dmm_id, detuning_map), {} |
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.
This is quite problematic because _Call is not used only for serialization to the abstract representation. dmm_name
is not an argument to config_detuning_map
, so I think this will cause problems (for example, when building a sequence from scratch from the stored calls).
Also, the fact that nothing goes wrong suggests that we should be more comprehensive in the unit tests.
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 true that I don't think we have ever tested building a parametrized sequence having a config_detuning_map... And I guess this will fail indeed. I will start by solving this issue.
* Adding dmm config and modulation to sequence * Reverting changes for _SLMMask * Setting max_amp of dmm to zero * Fixing detection of virtual channels in Device * Reverting changes in serialization * Reverting SLM, modifying available_channels * deleting dmm of schedule if slm of xy, Fixing type * Add insert_slm_mask * fixing available_channels with slm * Special handling of samples from a DMM channel (#565) * Add `DetuningMap.get_qubit_weight_map()` * Define `_DMMSchedule.get_samples()` * Extract DMMSamples from a Sequence * Creating the `Traps` class * Eliminating the effects of the SLM mask * Use COORD_PRECISION in comparison * `Traps.coords` -> `Traps.sorted_coords` * Subclass `Traps` in `WeightMap` * Preserve effects of SLM mask in XY mode * Explicitly ask for labels in DetuningMap.draw() * Including slug in WeightMap * UTs for DetuningMap * Isort * Specialize pulse validation in DMM * Revamp test_dmm UTs * Formatting * Add support for legacy serializer * add in_ising * Add SLM pulse, ising, modif validate_channel * Add waiting_for_first_pulse, fixing mask time * Covering all code, modif after review * Add descr sequence, _config_detuning_map * Finishing UTs, fixing typos * Abstract representation support for new DMM features (#568) * Support for DMM channel serialization * WIP: Prepare for incoming updates to JSON schema * Add descr sequence, _config_detuning_map * Finishing UTs, fixing typos * de-/serializing det maps, adding schema, slug * Dev tests * Fixing doc --------- Co-authored-by: a_corni <antoine.cornillot@pasqal.com> * Testing detuning of unmasked qubits, del print * Enabling use of add with slm * Replacing Modulate_det_map by add_dmm_detuning * Updating schema * finalizing replacing of modulate_detp_map * finalizing replacing of modulate_det_map * Rephrasing doc, add OpAddDmmDet * Handle parametrized sequence, switching device and DMM, and serialize config_det_map as an operation (#576) * Add slug description * Handle DMM & parametrized/switch_device/MapReg * Modifying schema, fixing type * Moving to a store decoration * Storing config_det_map * Taking into account review comments * Delete seq_tools * Testing MappableRegister, strict conversion * Replace modulate_det_map by add_dmm_detuning * Adding DMM notebook and Modifying SLM Mask (#569) * adding dmm, draw to DetuningMap * Testing avoiding circular import * Refactoring to avoid circular imports * Fix broken UTs * Import sorting * Fixing plot DetuningMap * Serialization/Deserialization of DMM in device * Fixing typos * Testing DMM and DetuningMap * Fixing typo * adding xfails, fixing type * Remove DMM from devices and finish UTs * Take into account review comments * Add annotations * Error in Global and Local * Defining _DMMSchedule * Fixing nits * Fixing typo * Creating DMM notebook, modif SLM notebook * Taking into account review comments * Fixing type * Fix labels in reg_drawer, draw det_maps in seq * Fixing doc build, add draw_detuning_maps to docs * Separating register/det_maps drawing from channels * introducing get_qubit_data * Add drawing of quantities per qubit * Fixing for local pulses * Adding bounds to label * Drawing legend for local targetting * FIX sampling rate, QutipEmulator * Updating figures * Updating SLM Mask & local addressability notebook * Adding explanation text * Fixing type * Replace modulate_det_map by add_dmm_detuning * Replace modulate_det_map for add_dmm_detuning * Fixing tests * Revert changes to Bayesian optimization notebook * Fixing docs * clearing outputs * Deleting scaling in favor extending to draw reg * Placing legend in lower part of drawing * Updating figures * Relaunching bayesian optimisation * Taking into account review comments * Printing sequence with DMM * Adding subscript and indent * Defining __str__ for DMM --------- Co-authored-by: HGSilveri <henrique.silverio@tecnico.ulisboa.pt> --------- Co-authored-by: Henrique Silvério <henrique.silverio@tecnico.ulisboa.pt>