Constructing model with affine/active errors raises ValueError

[zccoleman]

Describe the bug
According to the docs and tutorials, I should be able to create a model with an affine/active error generator in the lindblad_error_coeffs argument as follows:

import pygsti
pspec = pygsti.processors.QubitProcessorSpec(
  num_qubits=1,
  gate_names=['Gi']
)
model=pygsti.models.create_crosstalk_free_model(
  pspec,
  lindblad_error_coeffs={
    'Gi': {('A', 'X', 'Y'): 0.1}
  }
) ## results in ValueError

Attempting this results in a ValueError raised in LindbladErrorgen.__init__ apparently due to concatenation of arrays with different dimensions.

Expected behavior
The above code should construct a model with the included affine/active error processes.

Environment:

• pyGSTi version 0.9.13.3
• python version 3.12.3

[zccoleman]

It actually seems that this is a documentation issue rather than a bug.

Creating a LindbladErrorgen from the PTM of an error channel with affine elements, then inspecting the dictionary of errorgen_coefficients reveals a different dictionary format that DOES work in the lindblad_error_coeffs argument.

import pygsti
import numpy as np

T1 = np.array(
  [[1, 0, 0, 0],
   [0, np.sqrt(.9), 0, 0],
   [0, 0, np.sqrt(.9), 0],
   [.1, 0, 0, .9]]
) ## PTM for T1 decay with 10% probability

gens = pygsti.modelmembers.operations.LindbladErrorgen.from_operation_matrix(T1)
op = pygsti.modelmembers.operations.ExpErrorgenOp(gens)
coeff_dict = op.errorgen_coefficients() ## this dictionary works in `lindblad_error_coeffs`
print(coeff_dict)

model=pygsti.models.create_crosstalk_free_model(
  pspec,
  lindblad_error_coeffs={
    'Gi': op.errorgen_coefficients()
  }
) ## Does not raise error

Notably, the coeff_dict created above has only 3 non-zero elements, but the zero elements must be present in the dictionary for the model to construct.

[coreyostrove]

Thanks for reporting this issue. I can confirm that the behavior you're seeing is indeed present on 0.9.13.3. It looks like we actually have this patched on 0.9.14, though. As it happens I went to start debugging this earlier today and stumbled upon a folder I made back in May where I was debugging this exact issue. As part of the new error generator propagation code released on 0.9.14 a bunch of the LindbladErrorgen backend was rewritten, so I am not surprised despite the failure of my recollection.

Anyhow, you will run into a separate (intentionally raised) error when trying to run your example as written on 0.9.14, and that is an AssertionError which will yell at you because the default LindbladErrorgen is CP-constrained, but the coefficients you're setting are not CP (technically speaking the correct statement is that they don't generate a CP process). Active error generators on their own are non-CP, and need to be paired with appropriately sized stochastic error generators. This paper has more on those constraints: https://arxiv.org/abs/2103.01928. If you really did want a non-CP channel, though, you can achieve this by switching the default value of the lindblad_parameterization kwarg to 'GLND' or another non-CP constrained parameterization type. This will allow the construction to go through. One quirk I will point out about this non-CP construction is that if you query the resulting LindbladErrorgen, or one of the operations wrapping it, for its coefficients using a method like errorgen_coefficients it will report not only the particular A term you set, but also a corresponding C term and two S terms, though they should have rates set equal to zero. In the specific example you gave above you'd get:

{('S', ('X',), (0,)): 0.0, ('C', ('X', 'Y'), (0,)): 0.0, ('A', ('X', 'Y'), (0,)): 0.1, ('S', ('Y',), (0,)): 0.0}

This is related to a some details in how the error generator data is currently represented internally. We have long term plans/ideas on how to rearchitect this to get rid of this quirk, but no specific timeline on that. Just wanted to alert you in case you inspected the error generator coefficient dictionary and found the contents surprising.