Generating Random Error Generators about pygsti

[coreyostrove]

Just a heads-up to avoid working at cross purposes, I've started working on an implementation of this as part of a soon to be published branch. The currently envisioned features are (thanks to @kevincyoung for letting me pick his brain):

• Specification of error generator sectors
• Setting a target generator infidelity (if none is specified this wouldn't be fixed)
• Relative weights on the error generator sectors (with regards to some norm)
• Specification of maximum (pauli) weights for each of the error generator sectors.

This overlaps a good deal with your list of desiderata, with the possible exception of:

different noise strengths based on weight or qubit support (maybe weight-2 should be smaller than weight-1, maybe one qubit is particularly bad)

I hadn't considered this, but it should be doable. This option is definitely something I can envision someone wanting down the road, so implementing it now is definitely in the spirit of 'do it once so we don't need to do this again.'

Follow up on your parenthetical:

(CA may have to be tied together, and even SCA being tied together would be a start)

I hadn't considered this. My current target was for the output of this function to return a dictionary with ElementaryErrorgenLabel objects as keys and rates as values. I.e. the dictionary format used by the from_elementary_errorgens constructor for LindbladErrorgen, or as used in the various set_errorgen_coefficients methods. Such dictionaries are in general agnostic to the implementation details at the LindbladCoefficientBlock level though. What would currently happen if I passed the constructor a dictionary with just, say, S and C terms? Would it allocate parameters for the A terms and just set them to zero?

[sserita]

What would currently happen if I passed the constructor a dictionary with just, say, S and C terms? Would it allocate parameters for the A terms and just set them to zero?

In this case, the LindbladCoefficientBlock that is allocated would be the full SCA one, i.e. yes you would have A terms present in the parameterization and they would be set to 0. It is only possible to have the following sets of blocks:

• H (block_type = "ham")
• S (block_type = "other_diagonal")
• SCA (block_type = "other")

[coreyostrove]

I see. This definitely a scope creepy sort of question, but how much of a lift would it be to decouple the C and A terms? E.g. just having an SC or SA block? This is something we've mentioned wanting to be able to do before for finer tuned reduce model construction. It is also a parallel issue to this thread, however.

[sserita]

Medium lift IMO. It's luckily mostly localized to LindbladCoefficientBlock, but I wouldn't be surprised if there are inherent assumptions in other places in the code that if you have C, you have A, or vice versa. We'd probably want to build off of the param_mode = "elements", but that is significantly less used/tested compared to param_mode="cholesky", so wouldn't be surprised if we have to do some fixing there too. Plus I have this intuition that the Cholesky decomp is critical to enforcing the PSD constraint, so I'm missing a piece in understanding how we are enforcing CPTP with "elements" parameterization.

Edit: Thinking through it more, it's possible we aren't enforcing CPTP with "elements" and "elements" is just how we are doing the GLND parameterization. In which case, I'm still missing a conceptual piece about how to separate C and A while doing param_mode="cholesky".

To avoid scope creep, I'd be inclined to keep the SCA sectors tied together for this PR, and then when we decouple later, we update the random generation as well. Really, nothing needs to happen in the random generation code if you are describing via the dictionaries and we are automagically detecting block structure, just under the hood we would allow an SC block instead of an SCA block in your example.