[Quantum Resource Estimation] Add support for executing Q# files/projects

[Manvi-Agrawal]

Is your feature request related to a problem? Please describe. It would be nice for the resource estimator tool to be able to support resource estimation for code in Q# file/Q# projects. I would like to know the opinion of QDK folks. @msoeken @tcNickolas @swernli @billti thoughts? If majority of people think that its not very useful, I am happy to close this issue :-)

Describe the solution you'd like An abstract layer in the resource estimator tool provided by Q#. See https://github.com/microsoft/qsharp/pull/1915#discussion_r1755308276 for more details.

Describe alternatives you've considered Write the code to compile the Q# code when the need arises. I feel that might be an extra burden for users who might not be familiar with interpreter and Package store API in Q# compiler.

Additional context In https://github.com/microsoft/qsharp/pull/1915, Mathias introduced a sample detailing how to do that. I appreciate the sample detailing ability to do resource estimation from Q# file. Given that interpreter and Package store objects might be unfamiliar to many users, I think it might be helpful to provide a more abstract layer in the resource estimator tool provided by Q#. See https://github.com/microsoft/qsharp/pull/1915#discussion_r1755308276 for more details.

[swernli]

If I understand correctly, you are looking for an easy way to compile Q# files from Rust, correct? We do have ways to accomplish this from Python/Jupyter, specifically either the qsharp.eval function used on the contents read from a single file or using qsharp.init with optional project path parameter to load a project with multiple files from disk. Given the input to the customized resource estimation in Rust is logical counts, I would expect someone to use these existing methods to compile and estimate their Q# from Python, grab the logical counts, and either programmatically or manually feed those as input to their customized resource estimation. If that flow is followed, exposing additional Rust APIs for processing Q# files directly wouldn't be needed. If the user is not engaging with a customized, Rust-based resource estimation and instead just wants to use the existing algorithms and parameters of the product Resource Estimator, they can follow samples like this one to perform the estimation via Python: https://github.com/microsoft/qsharp/blob/main/samples/estimation/estimation-hardcoded-circuit.ipynb.

Does that match your question, or have I misunderstood the desired functionality?

[Manvi-Agrawal]

Thanks @swernli for the explanation. I didn't look thoroughly into the Rust example added. Based on the above explanation and quick glance over the sample and the abstract of the research paper, it seems to me that one should use rust resource estimator for :

• experimental features
• Lesser used functionality: like PSSPC layout for physical count calculation from logical count.

Is my understanding correct? This time I am curious to know how does one decide between using Python+Q# or Rust based estimator.

[swernli]

@msoeken should chime in here, but essentially there are two main resource estimation scenarios that we document and recommend right now:

1. Within VS Code - ideal for quickly getting started and trying algorithms that are expressed as one or Q# files, where estimates can be calculated from a selection of preconfigured types with some settable values (like error budget).
2. Using Python/Jupyter - the majority case, where you either are using longer-runner or larger Q# algorithms (or bringing logical counts from some other tooling) and want to configure specific details about the estimation by setting values directly in the json inputs. I expect this is what most folks using RE to support papers where they want to use the PSSPC layout that the estimator uses by default.

Only these two are described in our documentation for now. The newer configurability that @msoeken is working on at the Rust layer is for folks who want to customize deeper elements of how the RE infrastructure calculates its estimates, including changing from PSSPC to other layout strategies. For now, that is only documented in the readme files and code comments within the repo and is targeted at advanced users who aren't afraid to dive into writing Rust code to access these newer, more detailed configuration features.

To give scenario 1 a try yourself to see how easy it is to get started, you can navigate to the VS Code Playground, open the "Shor (Resource Estimation).qs" file, and either use the command palette entry "Q#: Calculate Resource Estimates" or the handy "Estimate" code lens: Configure your options, and then generate a set of estimates across a frontier of trade-offs between time and number of qubits for each of the chosen qubit technologies:

You can read more about this in the docs at Different ways to run the Resource Estimator