Due to its roots as a simple expo demo for booth duty at CES, and then having feature updates to accommodate multiple environments and hardware formats, Quantum Raspberry Tie has a lot of accreted inefficiencies.
How can we modularize it to clean up the code?
As it exists now, it is designed to run:
- on a Raspberry Pi with attached SenseHat
- on a Raspberry Pi without an attached SenseHat
- using an instance of SenseHat emulator for display
- using sensefaux/bypassing SenseHat emulator if the emulator is unavailable (no gui/wrong flavor of Linux)
- on any Raspberry Pi using a NeoPixel-style LED matrix
- on any Python-equipped system with Qiskit properly installed
- writing display to SVG/HTML file
- displaying on SenseHat emu if it is available in the installed environment
- writing progress messages and display to terminal
- connected to a network with access to quantum backends
- disconnected, running local simulators
- ALL versions support numerous computing options
- Five, Twelve, or 16 qubits demo programs available "built-in"
- Noisy 5 qubit local simulator, local Aer simulator, or Aer simulator based on real backend (requires API token)
- send to real backend (requires API token)
- can load customized QASM file if desired
- interactive walk-through mode including saving API token for new users
- Display handler with "thinking" animation is run in a separate thread from computation.
However it is modularized, maintaining that flexibility is important.
It seems to me that the first step is cleaning up its startup and option parsing code:
- Load basic libraries needed to check system OS and hardware and determine
- Determine presence/absence of SenseHat
- Determine availability of SenseHat emulator
- (Determine whether a GUI/desktop is available)
- Determine if hardware for LED array control is present (SPI)
- parse and process command line options filtered through what is determined in step 1:
- import and instantiate SenseHat
- import and instantiate emulator
- initialize LED array hardware
- load QASM file and confirm # of qubits, altering display options if necessary
- initialize display working arrays and mapping
- set flags to avoid calling non-existent objects
- start the display thread
- Run the actual quantum demo
How do we better organize the source to do this? What steps have I missed?
Due to its roots as a simple expo demo for booth duty at CES, and then having feature updates to accommodate multiple environments and hardware formats, Quantum Raspberry Tie has a lot of accreted inefficiencies.
How can we modularize it to clean up the code?
As it exists now, it is designed to run:
However it is modularized, maintaining that flexibility is important.
It seems to me that the first step is cleaning up its startup and option parsing code:
How do we better organize the source to do this? What steps have I missed?