copy.deepcopy doesn't work on instances of QuantumCircuit

[malee4]

Changes made:

1. Add pylatexenc and ipykernel to the list of installs in setup.py
2. Change copy.deepcopy() instances in LogicalQ/Experiments.py to QuantumCircuit.copy() to prevent the kernel crash encountered as described here: copy.deepcopy doesn't work on QuantumCircuit Qiskit/qiskit#11610.

TODO:

• Refactor to optimize list functions and for loops
• Running execute_circuit with H2-1 on Mac M1 chips causes kernel crashes. The issue lies somewhere in the noise model with the amplitude damping error.

[RasmitDevkota]

Hey, thanks for making the branch and opening the PR! A few quick questions:

1. Have we verified that the QuantumCircuit.copy method behaves well with LogicalCircuit? I ask because, off the top of my head, I'm not fully aware of what that method does, and so I don't know, for example, whether it preserves our special metadata and box labels which are necessary during execute_circuits.
2. What is ipykernel necessary for? Also, I've been reluctant to add pylatexenc to setup.py - since it isn't an explicit import and I'm not sure of any reason why code that doesn't use it wouldn't run without the import, I would classify it as an optional dependency, which it is generally best practice not to force the user to install. In the case of pytket imports, it seemed like you and others simply couldn't run anything without having those imports, which makes sense because it is an explicit import on our end, so we sort of put ourself into the rabbit hole of forcing the user to install those, but it's definitely not best practice because most users will likely never have to touch pytket. Open to any opinions on this though! Maybe we can argue that pylatexenc is such an important method for visualization that the user should just install it anyways?

[RasmitDevkota]

For your TODO's, I'd say let's merge them in a separate PR - this is a quick and easy PR to get in whereas the kernel debugging will be more involved, so let's work on that in a separate PR. I'd like to get these changes merged ASAP so we can pull them into the compat-qtm branch.

[malee4]

Hi Rasmit, All fair questions! 1. I had been under the impression that the circuits passed in are Qiskit QuantumCircuit objects. For some QuantumCircuit qc, qc.copy() creates a deep copy of the object: https://quantum.cloud.ibm.com/docs/en/api/qiskit/qiskit.circuit.QuantumCircuit#qiskit.circuit.QuantumCircuit.copy If you would prefer to keep the copy.deepcopy method, I have no strong objections! The potential memory issues seem to only happen with a subset of people, so I defer to your judgement. 2. ipykernel is used for the interactive Jupyter notebook environments used in the demos. I agree with what you’ve observed: it is not necessary for the LogicalQ package itself. For onboarding new students, I do think setup.py might be missing a few packages, but I recognize that is not the purpose of the install file! Feel free to disregard these changes. As for pylatexenc, as an end user of LogicalQ, I would find it helpful to be able to visualize the circuits I am running. It’s an added feature, but certainly not a necessary one. Again, I defer to your judgement on this.

…

On Mon, Sep 8, 2025 at 7:32 AM Rasmit Devkota ***@***.***> wrote: *RasmitDevkota* left a comment (GT-Quantum-Computing-Association/LogicalQ#4) <#4 (comment)> Hey, thanks for making the branch and opening the PR! A few quick questions: 1. Have we verified that the QuantumCircuit.copy method behaves well with LogicalCircuit? I ask because, off the top of my head, I'm not fully aware of what that method does, and so I don't know, for example, whether it preserves our special metadata and box labels which are necessary during execute_circuits. 2. What is ipykernel necessary for? Also, I've been reluctant to add pylatexenc to setup.py - since it isn't an explicit import and I'm not sure of any reason why code that *doesn't use it* wouldn't run without the import, I would classify it as an optional dependency, which it is generally best practice not to force the user to install. In the case of pytket imports, it seemed like you and others simply couldn't run anything without having those imports, which makes sense because it is an explicit import on our end, so we sort of put ourself into the rabbit hole of forcing the user to install those, but it's definitely not best practice because most users will likely never have to touch pytket. Open to any opinions on this though! Maybe we can argue that pylatexenc is such an important method for visualization that the user should just install it anyways? — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANINQWXAKIG6X3H5DCQAJFD3RVSMFAVCNFSM6AAAAACF3PX7WKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENRVHA3TCNBXHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[RasmitDevkota]

Thanks for the quick response!

1. All objects passed in are indeed instances of QuantumCircuit, but our primary use for this method is in fact LogicalCircuits. A quick scan through thr underlying Qiskit source confirms the Qiskit copy method will try to preserve metadata, so my new question is whether it preserves our metadata and, if not, whether or not that metadata is even needed in execute_circuits. I will have to spend more time looking at the Qiskit source to understand what all is happening there. Here's where that code starts if you'd like to take a look as well. https://github.com/Qiskit/qiskit/blob/d16e6c919c48737081ca9aef71fb5ce8a30c68b9/qiskit/circuit/quantumcircuit.py#L4102-L4113
2. I absolutely agree that I'd like the default user behavior to be seamless, maybe the minimal installation principle is just something I and a minority of other users would like to follow 😅. For motivation, the reason I bring it up is that maintaining package compatibility can become really annoying with Qiskit, but maybe we can just pull these changes and provide an alternative install option for minimal dependencies.

tl;dr Everything looks good once we check that the copy method won't break our LogicalCircuits!

[malee4]

Sounds good to me! I’ll start poking through the deep copy code this evening.

…

On Mon, Sep 8, 2025 at 8:04 AM Rasmit Devkota ***@***.***> wrote: *RasmitDevkota* left a comment (GT-Quantum-Computing-Association/LogicalQ#4) <#4 (comment)> Thanks for the quick response! 1. All objects passed in are indeed *instances of* QuantumCircuit, but our primary use for this method is in fact LogicalCircuits. A quick scan through thr underlying Qiskit source confirms the Qiskit copy method will try to preserve metadata, so my new question is whether it preserves *our* metadata and, if not, whether or not that metadata is even needed in execute_circuits. I will have to spend more time looking at the Qiskit source to understand what all is happening there. Here's where that code starts if you'd like to take a look as well. https://github.com/Qiskit/qiskit/blob/d16e6c919c48737081ca9aef71fb5ce8a30c68b9/qiskit/circuit/quantumcircuit.py#L4102-L4113 2. I absolutely agree that I'd like the default user behavior to be seamless, maybe the minimal installation principle is just something I and a minority of other users would like to follow 😅. For motivation, the reason I bring it up is that maintaining package compatibility can become really annoying with Qiskit, but maybe we can just pull these changes and provide an alternative install option for minimal dependencies. tl;dr Everything looks good once we check that the copy method won't break our LogicalCircuits! — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANINQWV7LI4ESL6GLHUVF433RVWFBAVCNFSM6AAAAACF3PX7WKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENRVHE3TMMJSHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[RasmitDevkota]

Sounds good, I would maybe actually recommend just starting with a test case in a notebook - make a LogicalCircuit with QEC cycles, copy it, and check that it looks correct. I'm actually 99% certain the copy will break the LogicalCircuit structure and turn it into a regular QuantumCircuit, but as long as the circuit data is fully preserved that's OK - it will happen anyways during transpilation steps. What I'm worried about personally is whether it will affect our instructions, like will it preserve box labels? Those are absolutely necessary.

[RasmitDevkota]

Also, it looks like ipykernel is installed with jupyter, so I don't think it's necessary that we specify it explicitly.

[RasmitDevkota]

Just checking in, were you able to test the copy method out? Let me know if you need any help with this!

[RasmitDevkota]

Just coming back to this during other testing to note that it looks like the LogicalCircuit.copy method (just from us inheriting QuantumCircuit.copy) maintains the LogicalCircuit type, but this doesn't mean it fully deepcopies the underlying data structures. Some preliminary testing suggests it should be, but I'd still like to see more rigorous testing just in case.

(Image courtesy @NolanHeffner)