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

Adding qq update command #905

Merged
merged 16 commits into from
Jul 8, 2024
Merged

Adding qq update command #905

merged 16 commits into from
Jul 8, 2024

Conversation

andrea-pasquale
Copy link
Contributor

@andrea-pasquale andrea-pasquale commented Jun 27, 2024

Addition of a qq update program to generate the updated platform from CLI after the qibocal execution. Closes #833.

Checklist:

  • Reviewers confirm new code works as expected.
  • Tests are passing.
  • Coverage does not decrease.
  • Documentation is updated.
  • Compatibility with Qibo modules (Please edit this section if the current pull request is not compatible with the following branches).
    • Qibo: master
    • Qibolab: main
    • Qibolab_platforms_qrc: main

@andrea-pasquale andrea-pasquale added the enhancement New feature or request label Jun 27, 2024
@andrea-pasquale andrea-pasquale self-assigned this Jun 27, 2024
Comment on lines 47 to 54
runcard = Runcard.load(yaml.safe_load((path / RUNCARD).read_text()))
set_backend(backend=runcard.backend, platform=runcard.platform)
# run
history = run(
output=path,
runcard=runcard,
mode=ExecutionMode.UPDATE,
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should already have the most updated runcard in the output folder, when you invoke qq update.

Maybe it is in a subfolder, corresponding to the latest routine (which is perfectly fine), but I'd just maintain a link to the latest one in the top-level folder, and copy that one to the original platform.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this way, you won't even need to track the timing. It's just a copy, it will take almost nothing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should already have the most updated runcard in the output folder, when you invoke qq update.

Maybe it is in a subfolder, corresponding to the latest routine (which is perfectly fine), but I'd just maintain a link to the latest one in the top-level folder, and copy that one to the original platform.

Actually this might not be the case. This is true only when running with AUTOCALIBRATION, but in this execution mode all updates will be performed in any case (local one after each protocol and the global one at the end).
I know that we still need to decide how to handle local updates. If by default we decide to keep local updates what you are suggesting makes sense. What do you think @alecandido?

"""Update drive frequency value in platform for specific qubit."""
if isinstance(freq, tuple):
if isinstance(freq, (tuple, list)):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about just using one of the two?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just an ugly patch. I will try to improve it. The error was triggered when I tested with qq update, I think that there are some attributes in Results which are tuple since they contain also the error and when they are deserialized they are converted into lists.

Copy link
Member

@alecandido alecandido Jun 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, JSON only supports one type of sequences, and that type is deserialized to list in Python.

However, if we want to serialize it, and we don't have advanced support to deserialize to our own types (e.g. Pydantic), I'd propose to not oppose to JSON, and just use lists. It's a practical solution to avoid an increased amount of code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implemented in cf006ca

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been through cf006ca, and I marked a few tuples I've found, but there are many more.

Maybe I missed where the tuples had to be dropped from. Sorry...

@alecandido alecandido mentioned this pull request Jun 28, 2024
@alecandido
Copy link
Member

@andrea-pasquale I'm sorry for the tuple business. As soon as I will finish #909 I have other few simpler improvements in mind, including a consistent migration to Pydantic. Whenever that will be completed, tuples will be available again, since the serialization will come out of the box.

Unfortunately, I will have to balance those with #869 (but if I will be good enough with #909, a first version of that should be pretty simple to achieve).

@andrea-pasquale
Copy link
Contributor Author

@andrea-pasquale I'm sorry for the tuple business. As soon as I will finish #909 I have other few simpler improvements in mind, including a consistent migration to Pydantic. Whenever that will be completed, tuples will be available again, since the serialization will come out of the box.

Unfortunately, I will have to balance those with #869 (but if I will be good enough with #909, a first version of that should be pretty simple to achieve).

No problem @alecandido.
Now I believe that it should be fixed. I will try to take care of tests now.
In which order do you recommend that we merge this alongside #909 and #869?

@alecandido
Copy link
Member

In which order do you recommend that we merge this alongside #909 and #869?

Do not bother about #909 and #869: whenever you're ready, we review and merge. If it comes before the others, I will rebase myself ( ╥ ᴗ ╥)

Copy link

codecov bot commented Jul 2, 2024

Codecov Report

Attention: Patch coverage is 98.94737% with 1 line in your changes missing coverage. Please review.

Project coverage is 97.46%. Comparing base (4b8d407) to head (f0988b9).
Report is 8 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #905      +/-   ##
==========================================
- Coverage   97.47%   97.46%   -0.02%     
==========================================
  Files         116      117       +1     
  Lines        8882     8906      +24     
==========================================
+ Hits         8658     8680      +22     
- Misses        224      226       +2     
Flag Coverage Δ
unittests 97.46% <98.94%> (-0.02%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
src/qibocal/auto/execute.py 100.00% <100.00%> (ø)
src/qibocal/auto/task.py 99.15% <ø> (-0.04%) ⬇️
src/qibocal/cli/_base.py 91.93% <100.00%> (+0.70%) ⬆️
src/qibocal/cli/autocalibration.py 100.00% <100.00%> (ø)
src/qibocal/cli/fit.py 100.00% <100.00%> (ø)
...rc/qibocal/protocols/coherence/spin_echo_signal.py 100.00% <100.00%> (ø)
src/qibocal/protocols/coherence/t1.py 100.00% <100.00%> (ø)
src/qibocal/protocols/coherence/t1_signal.py 100.00% <100.00%> (ø)
src/qibocal/protocols/coherence/t2_signal.py 100.00% <100.00%> (ø)
src/qibocal/protocols/coherence/utils.py 95.38% <100.00%> (ø)
... and 16 more

... and 1 file with indirect coverage changes

@andrea-pasquale
Copy link
Contributor Author

Now it should be ready to review. There are a lot of file changes just for the tuple issue

@andrea-pasquale andrea-pasquale marked this pull request as ready for review July 2, 2024 18:43
@andrea-pasquale andrea-pasquale changed the title [poc] Adding qq update command Adding qq update command Jul 2, 2024
Copy link
Member

@alecandido alecandido left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have just a comment about local_update, but other than that it should be fine.

I'm also glad that the superposition with #909 is very small, it should be pretty simple to rebase :D

src/qibocal/cli/autocalibration.py Outdated Show resolved Hide resolved
src/qibocal/cli/fit.py Outdated Show resolved Hide resolved
completed.update_platform(platform=self.platform, update=self.update)

if self.platform is not None:
Copy link
Contributor

@Edoardo-Pedicillo Edoardo-Pedicillo Jul 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe you can move this line before if ExecutionMode.FIT in mode and self.platform is not None and update:

There is a small inconsistency with the typing, according to the Executor definition a platform is always defined even in the create method, for the moment could you change it ? (we can even wait #909)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, the check now is needed only because we support still execution with simulation (where platform is None). Since #909 will drop it here we can keep it I think. I'll open an issue just to remember to do it.

@andrea-pasquale andrea-pasquale added this pull request to the merge queue Jul 8, 2024
Merged via the queue into main with commit c3f355f Jul 8, 2024
21 checks passed
@andrea-pasquale andrea-pasquale deleted the qq-update branch July 8, 2024 17:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add command to perform platform update
3 participants