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

Abstract representation support for new DMM features #568

Merged
merged 8 commits into from
Aug 8, 2023

Conversation

HGSilveri
Copy link
Collaborator

@HGSilveri HGSilveri commented Aug 2, 2023

  • 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

@HGSilveri HGSilveri requested a review from a-corni August 2, 2023 15:04
@a-corni a-corni marked this pull request as ready for review August 3, 2023 15:09
@a-corni a-corni merged commit 1fb7924 into add_dmm_sequence Aug 8, 2023
Copy link
Collaborator Author

@HGSilveri HGSilveri left a 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...

Comment on lines +460 to +464
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])
Copy link
Collaborator Author

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

Copy link
Collaborator

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...

Comment on lines +466 to +483
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)
Copy link
Collaborator Author

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

Copy link
Collaborator

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)

Copy link
Collaborator Author

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,
Copy link
Collaborator Author

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.

Comment on lines +617 to +618
_Call(
"config_detuning_map", (dmm_name, dmm_id, detuning_map), {}
Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

a-corni added a commit that referenced this pull request Sep 22, 2023
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants