qutip.control meetup
Participants: Michael Goerz (ARL, USA), Boxi Li (ETH Z, Switzerland; QuTech, The Netherlands; Jülich, Germany), Alex Pitchford (Aberystwyth U., UK), Eric Giguere (Quebec Calcul, Canada), Julian Teske & Hendrik Bluhm (RWTH Aachen, Germany), Shahnawaz Ahmed (Chalmers Tech. U., Sweden), Nathan Shammah (Unitary Fund, USA; visiting: RIKEN - Franco Nori’s group, Japan).
Summary: We held discussions over future developments of the control module and integration with existing libraries, such as Krotov, and qupulse. We agreed on the benefit of a qutip family of packages, spinning out existing functionalities (qip, control) and useful to add new ones. Agreed on continuing the discussion on GitHub issues and with other public tools. Discussed specific features in Krotov.
[MG]: Would like Krotov integration, more flexibility, suggest sci-kit like modularity. Can have some of the packages in qutip GH org.
[AP]: A bit of background: Qutip.control started from taking Dynamo in MATLAB into qutip. We should make choices that ease maintainability. Qutip 5 could spit out control and qip, but have a family of qutip-related stuff. qutip “affiliated” packages, some can be in org, some outside. Qutip.control uses qobj data types, does optimization and control somewhere else, we can find a common interface.
[SH]: The usefulness of setting things apart became evident during GSoC 2019, 2020, e.g. qulearn will likely provide other instances of “qutip family”. We should follow https://www.scipy.org/ structure, with all the packages
[MG, AP]: Define an interface of domain objectives as in krotov.optimize.optimize_pulses. Add QobjEvo integration, specifications and discuss this further mainly to GH issues. Single-time-step propagation is an essential building block of optimal control. Eric is working on this.
[JT, HB]: Interest from experimentalists to interface. Qupulse development has its own interface, it started compatible with qutip, now is probably more “rigid” to make it more performant. The Aachen group performs research on spin qubits and quantum control. Found that some solvers in qutip are not so performant for our purposes. Some noise models are not contained in QuTiP, such as quasi-static noise and filter functions and variational methods. Useful information to understand would be: How general the framework needs to be?
[NS]: Unitary Fund support open-source projects in quantum science, from small projects (micro-grants) to QuTiP. Let’s add these minutes to wiki, like for the devs workshop https://github.com/qutip/qutip/wiki/QuTiP-Developers-Workshop. We can set up a space for ideas, QuTiP active dev page and match-making of professors to students/engineers, which will be facilitated by formal governance. Not all interested parties may be able to / have the time to navigate a github issue thread (e.g., professors not coding), so it would be best to add information summaries also somewhere else, eg. on the wiki and qutip.org. Set up a qutip-control framework repository. Note that also Pasqal (Rydberg atoms) and other research groups may be interested, like for qupulse, into integrating qutip in the lab: we can think of a qutip (org)/ qutip-lab (repo) with common APIs.
[AP]: New Qobj internal representation is being worked on (Jake's GSoC project): this will make optimal control much more efficient. krotov.Objective.H (or its equivalent in a qutip optimal control interface) should be more generally a QobjEvo object.