Freq tunable coupling

[MaxNaeg]

What

1) Added the functionality of a driven coupling.

2) Added the functionality to drive the coupling between two coupled Transmons elements dependent on their frequency drive.

Why

to 1) This could be used to e.g. model the coupling mediated by tunable capacitances between superconducting qubits. It also enables feature 2).

to 2) The coupling between two Transmons is not independent of their frequency but scales proportionally to Sqrt(frequency_1 * frequency_2). For realistic simulations of superconducting circuits, this dependence needs to be modeled.

How

to 1) Added the subclass Coupling_Drive(Drive) that evaluates the init_Hs() function differently

to 2) This follows the idea of the flux tuning of a transmon qubit. Added the class CouplingTuning(Device) which works analogous to the FluxTuning(Device) class, but modulates the coupling instead of the frequency.

Remarks

For an example see the c3/examples/frequency_dependent_coupling.ipynb notebook. This implementation is not efficient, since the line driving the coupling has to calculate the frequency modulation of the coupled elements a second time. This could be handled more efficiently if devices in one line could get outputs of other lines as inputs.

Checklist

Please include and complete the following checklist. Your Pull Request is (in most cases) not ready for review until the following have been completed. You can create a draft PR while you are still completing the checklist. Check the Contribution Guidelines for more details. You can mark an item as complete with the - [x] prefix

• [x] Tests - Added unit tests for new code, regression tests for bugs and updated the integration tests if required
• [x] Formatting & Linting - black and flake8 have been used to ensure styling guidelines are met
• [x] Type Annotations - All new code has been type annotated in the function signatures using type hints
• [x] Docstrings - Docstrings have been provided for functions in the numpydoc style
• [ ] Documentation - The tutorial style documentation has been updated to explain changes & new features
• [x] Notebooks - Example notebooks have been updated to incorporate changes and new features
• [x] Changelog - A short note on this PR has been added to the Upcoming Release section

[CLAassistant]

All committers have signed the CLA.

[codecov[bot]]

Codecov Report

Merging #211 (e22def6) into dev (369f3d1) will increase coverage by 0.22%. The diff coverage is 97.05%.

@@            Coverage Diff             @@
##              dev     #211      +/-   ##
==========================================
+ Coverage   74.79%   75.02%   +0.22%     
==========================================
  Files          38       38              
  Lines        5559     5593      +34     
==========================================
+ Hits         4158     4196      +38     
+ Misses       1401     1397       -4     

Impacted Files	Coverage Δ
c3/generator/devices.py	72.76% <96.66%> (+1.51%)	:arrow_up:
c3/libraries/chip.py	62.08% <100.00%> (+0.28%)	:arrow_up:
c3/libraries/hamiltonians.py	100.00% <0.00%> (+13.51%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 369f3d1...e22def6. Read the comment docs.

[nwittler]

The code itself seems fine, we have to make more of a design decision here. The generator is meant to contain classical electronics, so this looks a bit like a hack to get the desired physics. We're having similar discussions in other applications. At this point, I think it would make more sense to move this kind of computation into the Model class or even a special TunableModel(Model) class. That can then take the input signal and adjust all affected model parameters like qubit frequencies and couplings.