Minutes of hardware workstream 2023-09-08

workstreams/hardware-adoption/minutes/2023-09-08.md

@@ -0,0 +1,57 @@
+# Hardware adoption committee 2023-09-08
+
+## Attendance
+
+- Jean Senellart (Quandela)
+- Sonia Pignorel (Microsoft)
+- Andrei Petrenko (QCI)
+- Tom Lubinski (QCI)
+- Stefan Wernli (Microsoft)
+- Amos Anderson (QCI)
+- Bettina Heim (Nvidia)
+- Bill Ticehurst (Microsoft)
+- Laurent Prost (Alice & Bob)
+- Julien Dumazert (Alice & Bob)
+
+## Meeting agenda
+
+- Presentations by companies
+- Discussion of companies needs and next steps
+
+## Notes
+
+- See presentations folder fo slide decks
+- Topics discussed:
+  - How to handle the different gate sets allowed by the providers?
+    - Possible solution #1: Shift responsiblity to transpile to hardware native
+      gate set from frontend compiler / high-level framework to hardware
+      provider
+    - Possible solution #2: Standardization of known gates so that frontend
+      compilers know most of the gates used by most hardwares
+  - QIR computational model based on sequences of discrete gates doesn't
+    support all styles of hardware control (ex: pulse-based control of
+    superconducting circuits). Should QIR be extended? Or should it stick to
+    gate-based control?
+  - Should QIR include high-level algorithms like QAOA? Ex: the frontend
+    compiler / high-level framework asks for QAOA and the responsibility to
+    implement QAOA is with the hardware provider. "Users care about
+    applications, nobody wants to run a CNOT."
+  - How to increase adoption of QIR by the quantum community and in particular
+    hardware providers?
+    - Possible solution #1: increase interoperability of QIR by improving
+      translations from/to Qiskit and QASM (major frameworks). In practice,
+      this means improving qiskit-qir and qcor.
+    - Possible solution #2: focus a sub-community like hybrid computing, which
+      QIR seems to be well-suited for
+  - Do end users want low-level control?
+    - Interest for low-level control is in academic groups, but it is risky
+      for hardware providers to cater to that crowd before they have secured
+      public grants to fund developments
+
+## Next steps
+
+- Organize another meeting of 1.5 hours in 3 months
+  - Topic: balance between standardization and specialization of QIR
+- Upload hardware providers presentation to GitHub folder
+- Find a way to create a discussion group to facilitate discussions (e.g.,
+- mailing list, Slack channel, etc)