Remove c3_qasm_perfect_simulator and provide dry_run option

[lazyoracle]

Describe the missing feature

The c3_qasm_physics_simulator is now in pretty decent shape with increasing support for most of the native features of the c3 simulator and integrates seamlessly into workflows. The c3_qasm_perfect_simulator is no longer necessary, which was a stopgap solution while building the backend is no longer necessary and should be removed. Keeping it around leads to unmaintainable duplicated code. Instead, providing a dry_run option to the backend.run() call would be useful for the user to check that the code runs all fine, and everything has been correctly configured without having to perform the compute intensive full physics simulation. This dry_run path should have a complete API coverage with the standard interface and check as much of the code as possible without running the actual simulation.

Describe the solution you'd like

• A backend.run(qc, dry_run = True) interface
• Remove entire C3QasmPerfectSimulator code
• Remove entire get_sequence() and make_gate_str() from c3_backend_utils
• Restructure and streamline qiskit tests
• compute_propagators(), evaluate() and process() methods in Experiment should have dry run equivalents

Describe alternatives you've considered

How have you tried to resolve it in the current version of the code? Have you considered non c3-toolset alternative solutions? Please elaborate.

Additional context

Add any other context or screenshots about the feature request here. Please feel free to suggest details about how you believe this feature request might be best implemented. If you have used similar features in other libraries, consider providing links or resources to example implementations.

[shaimach]

It would be nice if there is a way of mapping / distilling the QPU structure defined in C3 to a QISKIT QPU structure, so that gate-only circuits (i.e. no pulse gates) can be quickly checked using the QISKIT Aer native simulators <https://qiskit.org/documentation/tutorials/simulators/1_aer_provider.html>. Optional extra bonus points if we can bootstrap a C3 QPU definition from a QISKIT QPU definition and a specification of the type of qubits and couplers.

…

On Tue, 4 Jan 2022 at 21:11, Anurag Saha Roy ***@***.***> wrote: Describe the missing feature The c3_qasm_physics_simulator is now in pretty decent shape with increasing support for most of the native features of the c3 simulator and integrates seamlessly into workflows. The c3_qasm_perfect_simulator is no longer necessary, which was a stopgap solution while building the backend is no longer necessary and should be removed. Keeping it around leads to unmaintainable duplicated code. Instead, providing a dry_run option to the backend.run() call would be useful for the user to check that the code runs all fine, and everything has been correctly configured without having to perform the compute intensive full physics simulation. This dry_run path should have a complete API coverage with the standard interface and check as much of the code as possible without running the actual simulation. Describe the solution you'd like - A backend.run(qc, dry_run = True) interface - Remove entire C3QasmPerfectSimulator code - Remove entire get_sequence() and make_gate_str() from c3_backend_utils - Restructure and streamline qiskit tests - compute_propagators(), evaluate() and process() methods in Experiment should have dry run equivalents Describe alternatives you've considered How have you tried to resolve it in the current version of the code? Have you considered non c3-toolset alternative solutions? Please elaborate. Additional context Add any other context or screenshots about the feature request here. Please feel free to suggest details about how you believe this feature request might be best implemented. If you have used similar features in other libraries, consider providing links or resources to example implementations. — Reply to this email directly, view it on GitHub <#172>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH3Q4MWIH376SEKSK4MFMTUUNA5XANCNFSM5LIFEFQA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>