RFC: structure of bloqade frontends

[jon-wurtz]

I would like to think about bloqade "front ends" as a way of better directing requirements on the backend/kernel part of bloqade. The key point is that while we do have a front-end, it is mostly focused on building and representing programs through building kernels. We need to ensure that these pieces are easy to integrate with external workflows. I would distinguish the front end as existing primarily in python, with the representations as python scripts and executions within the python kernel.

I've broken down what I see as the major blocks/modules of bloqade, which loosely fits qiskit [1]. A block diagram is here, where boxes represent functions/programs etc. while arrows denote data and representations.

My next step is to start writing out some RFCs for various blocks, which begin to dictate the high level functional requirements of the bloqade SDK. But first this RFC is just to make sure I'm not missing anything big in the general structure of building/executing/analysis.

Builders (representation)

Representing programs, hardware, models, as well as methods to transpile/transform/lower from one representation to another. The initial parts of this are beginning to be covered by Bloqade as it stands now (e.g. kernels generated from decorated Python functions) but there may be more to add, such as transpilation to other SDKs like Qiskit.

Interpreters (execution)

Actually executing or implementing the representation of programs built by the user, either through emulation or submission to hardware. This includes things like state-vector emulation, noise sampling, or error correction simulation.

Program Analysis (analysis)

Instead of literally executing the program as written (as would be done by an interpreter), inspect the program to get metadata and other information to improve the execution. This could include suites of debugging tools, performance analysis, [interactive] program visualization, error thresholds for fault tolerance (though this might be more of data analysis?)

Data Analysis

Tools for manipulating and understanding data generated from simulation and hardware. This is mostly stdlibs of computing expectation values on wavefunctions and bitstrings; computing fidelity, entanglement entropy, and other metrics; postselection and error mitigation; parameter inference and QML tasks.

Everything else (Utilities)

Most things should be (de)serializable as to make it easy to save and load workflows. I'm not sure what else goes here but I'll put out an RFC for it soon anyways.

RFC: Is there anything missing in this structure that I might be missing? Is this 4-block separation a good classification to start building code around?

[1] https://docs.quantum.ibm.com/guides/intro-to-patterns

[kaihsin]

What is the role of I/O block here?

[jon-wurtz]

What is the role of I/O block here?

I/O would be things like bloqade.save(program) or bloqade.load(bitstring_measurements_file). Saving and loading will be an important part of many workflows, especially hardware-centric. It might also include things like event-based triggering on hybrid programs if we are getting fancy with webhooks.

[Roger-luo]

Most things should be (de)serializable as to make it easy to save and load workflows. I'm not sure what else goes here but I'll put out an RFC for it soon anyways.

Isn't this the I/O block? I think it is better to just make it more concrete as (de)serialization.

[Roger-luo]

While I appreciate the RFC here, it's not very concrete on what change this RFC is proposing to the repo.

• Is this a documentation proposal?
• Is this a package structure re-org proposal?

I don't think we should structure the package this way - the namespace should be simple and feature related. It could be something in the documentation like the IBM documentation you link.

Regarding the name in documentation, I think the following terminology should be corrected in documentation (if we are gonna write any) thus it's better to align with that

• kernel <- builders (representation)
• compilation should include transformations
• standard lib <- algorithm primitives
• standard lib <- postprocessing

the above blocks is missing compilation to me. I think a lot of good-to-have UX for compilation is not being included here. I need to emphasis that everything in bloqade should serve for hardware compilation as first-class citizen.

And there are more things in the stdlibs, in principle anything that could be routinely running on QuEra's device should be included in stdlibs.

My next step is to start writing out some RFCs for various blocks, which begin to dictate the high level functional requirements of the bloqade SDK. But first this RFC is just to make sure I'm not missing anything big in the general structure of building/executing/analysis.

would be nice to have more concrete RFCs like how we proposed #221 instead of abstract ones like this RFC - there is no clear boundary of when to close this issue and what to do with it. I'm transferring this to a discussion.

[jon-wurtz]

I'll write more concrete RFCs on each of the blocks soon. I think this is a nice way to dictate requirements.

I don't envision necessarily enforcing these blocks within the bloqade structure, just more towards thinking about each of the major "areas" that we need. We should try to lock it down soon-ish so that documentation can be written as well. It might be reasonable to have analysis like this, e.g. bloqade.analysis.fidelity(program)