Issue when changing phase of 2q operation and passing to `leaky_qubit_model_from_pspec`

[naezzell]

Describe the bug

I am building a leaky_qubit_from_pspec (see here) using the smq1Q_XYI model pack, but for technical reasons, I am adjusting the phase on the gate_unitaries inside the model pack. While this works for Gxpi2 or Gypi2, I get a cryptic error for {idle}.

Namely, I get the following error message,
KeyError: "All keys must be strings, beginning with the prefix 'G'"

To Reproduce
Running the following code

from pygsti.modelpacks import smq1Q_XYI as mp
from pygsti.tools.leakage import leaky_qubit_model_from_pspec

ps_2level = mp.processor_spec()
ps_2level.gate_unitaries["{idle}"] *= -1
tm3 = leaky_qubit_model_from_pspec(ps_2level, mx_basis='l2p1')

gives the above KeyError. In contrast, I can change the phase of Gxpi2 and Gypi2,

ps_2level = mp.processor_spec()
ps_2level.gate_unitaries["Gxpi2"] *= -1j
ps_2level.gate_unitaries["Gypi2"] *= -1
tm3 = leaky_qubit_model_from_pspec(ps_2level, mx_basis='l2p1')

and even do wild things I probably shouldn't even be able to do (making things non-unitary),

import numpy as np
ps_2level = mp.processor_spec()
ps_2level.gate_unitaries["Gxpi2"] *= -1/4j
ps_2level.gate_unitaries["Gypi2"] *= np.random.random((2,2))
tm3 = leaky_qubit_model_from_pspec(ps_2level, mx_basis='l2p1')

Expected behavior
I should be able to change the phase of the identity operation in a qubit model like I can change Gxpi2 or Gypi2.

Environment (please complete the following information):

• pyGSTi version (local develop branch install), 0.9.14.1.post1.dev14+gbae6d1be1.develop.d20251105
• python version 3.11.13
• OSX 15.5

Additional context

• Though it may seem strange to change a global phase on a qubit unitary, this goes into a qutrit model builder that turns it into a relative phase between the first two levels and the third level.
• I found a weird thing that may or may not help: Building the qutrit model changes the gate_unitary dictionary keys in place.

ps_2level = mp.processor_spec()
print(ps_2level.gate_unitaries.keys()) # gives dict_keys(['{idle}', 'Gxpi2', 'Gypi2'])
tm3 = leaky_qubit_model_from_pspec(ps_2level, mx_basis='l2p1')
print(ps_2level.gate_unitaries.keys()) # gives dict_keys([Label(()), 'Gxpi2', 'Gypi2'])

[naezzell]

@rileyjmurray Any idea what might be causing this issue?

[rileyjmurray]

I do! This is an interesting find.

Context: what's happening is that {idle} is a placeholder name for the idle gate. It's not a valid gate name on its own, but rather a signal that the name has yet to be chosen. like to.

The leaky_qubit_model_from_pspec function has a default_idle_gatename argument. The first thing that this function does is replace {idle} with that default_idle_gatename. Its way of doing this assumes that if {idle} is present among the gate names then it'd be included in ProcessorSpec.idle_gate_names.

Here's the funny thing. The implementation of ProcessorSpec.idle_gate_names identifies the idle programmatically by checking the gate unitary, rather than checking for the {idle} flag or the many possible names that an idle gate should have. He's some code you can see interactively:

ps_2level = mp.processor_spec()
print(ps_2level.idle_gate_names) 
# ^ should be equal to the length-1 list, ['{idle}']
ps_2level.gate_unitaries["{idle}"] *= -1
print(ps_2level.idle_gate_names)
# ^ Empty list !!

In your situation the simplest fix is to get rid of the problematic {idle} label yourself, rather than having leaky_qubit_model_from_pspec do it for you.

ps_2level = mp.processor_spec()
ps_2level.rename_gate_inplace('{idle}', pygsti.Label(()) )
for u in ps_2level.gate_unitaries.values():
    u *= 1j   # apply the phase change to all gates

tm3 = leaky_qubit_model_from_pspec(ps_2level)

What we can do longer-term is change how leaky_qubit_model_from_pspec guards against the '{idle}' label. Rather than looking in ProcessorSpec.idle_gate_names, it can just look in the entirety of ProcessorSpec.gate_names.

[naezzell]

Fixing the key before passing it to leaky_qubit_model... is a sufficient work-around for me. Thanks!