Feature kraus api #255
Merged
Feature kraus api #255
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 14 commits
April 13, 2022 11:40
Adds kraussop.py that contains interface (base) class. Adds implementation of this interface in DenseOperator and DenseUnitaryOperator, which required adding a 'basis' argument to DenseOperator.__init__. This update cascaded to updating several of the DenseOperator subclasses, such as FullArbitraryOp. 'None' is allowed to be specified as the basis, but if so the Kraus op functionality is unavailable.
…ses. The big update in this commit is the addition of new OpRepKraus and OpRepRandomUnitary classes the the densitymx and densitymx_slow evotypes, and OpRepRandomUnitary to the chp evotype. The existing OpRepStochastic class (only in these 3 evotypes) is updated to inherit from OpRepRandomUnitary and has an updated signature, propagating to updates in StochasticNoiseOp.
… correct now. Fixes normalization bugs and adds explanatory comments in DenseOperator.kraus_operations so that correct Kraus operations are produced. Previously they were correct up to normalization.
…raus updates. Implements KrausOperatorInterface within StochasticNoiseOp by calling .to_dense() on the unitary_reps within a OpRepRandomUnitary representation. When this isn't implemented (e.g. CHP evotype) than an error will be raised. This commit includes other minor updates/fixes to op reps and operator classes.
Implements a default outcome-for-shot method in WeakForwardSimulator (though this is inefficient when the "shot" actually can compute a probability distribution rather than a single outcome) that can be used by the now-augmented 'statevec_slow' evotype. The statevec_slow evotype has been augmented with acton_random methods and new OpRepRandomUnitary and OpRepStochastic classes to allow it to work with WeakForwardSimulator even with models containing StochasticNoiseOp operations.
…n. Minor bug fixes.
This allows, in particular, the CHP evotype and forward simulator to be run
on an ExplicitOpModel created from create_explicit_model that has depolarizing
noise (set by the depolarization_strengths arg). The CHP evotype only supports
standard gates thus far (though it could be expanded to arbitrary Clifford gates)
and so needed the standard name of a gate to be computed correctly during model
construction even when the gate name didn't match a standard name (e.g. the '{idle}'
gate created by an explicit model).
This commit also fixes several other minor bugs introduced in recent commits
related to the new random unitary operator representation objects.
This update makes several related changes that in the end allow the CHP evotype to be used with WeakForwardSimulator, MapForwardSimulator, and SimpleMapForwardSimulator forward simulators (the latter two only work when the circuit is made up of noiseless Clifford ops). - addition of POVM representation objects. Evolution types can now be asked to generate computational and composed (and in the future more?) POVM representations. The only evotype that currently does this is 'chp', but the functionality may prove useful to future evotypes. - ComposedPOVM and CompuationalBasisPOVM attempt to construct POVM representations BUT allow the creation call to fail (as it does for all but the 'chp' evotype currently) and then set their ._rep attribute to None. Unlike other modelmember types, a POVM *is* allowed to have its ._rep == None provided it contains or can produce effect objects with valid representations. - WeakForwardSimulator, MapForwardSimulator, and SimpleMapForwardSimulator are updated to prefer to use a POVM's representation to compute outcome samples or probabilities, and in the case the ._rep == None fall back to computing with effect vectors as before. This allows the chp evotype to interface with these forward sims via its POVM reps rather than unnaturally through POVM effect objects & reps. - the chp evotype contains a new povmreps.py file that holds POVM representation classes. The POVM reps perform the actual running of the CHP executable (previously in CHPForwardSimulator) when outcome samples or probabilities are requested by a (generic) forward simulator. This update is also meant to provide (& test) a new, hopefully more natural and efficient paradigm for introducing new third party circuit simulators to pyGSTi: by adding just a new evotype rather than an evotype and a new forward simulator. We'll see how this holds up.
…otype. Basically translates the Kraus-map and weak-forwardsim supporting functionality in 'statevec_slow' into 'statevec'. This is pretty straightforward but does require calling a Python method from within C code, which is the first example of this in the codebase.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds Kraus operator interface to some operations
Creates the
KrausOperatorInterfaceclass which defines an interface for getting, setting, and counting the Kraus operators of a superoperator. A number of pyGSTi's operation classes, namelyStochasticNoiseOpand those derived fromDenseUnitaryOperatororDenseOperator(e.g.FullArbitraryOp,FullTPOp,StaticArbitraryOp, andDepolarizeOp) implement this interface, though some only partially. For example, only some operators can set their Kraus operators.To achieve this, an number of under-the-hood changes have been made as a part of this PR:
CHPForwardSimulatorclass is now removed).acton_randomandadjoint_acton_randommethods to operation representation classes, so that they can be used by the updatedWeakForwardSimulatorclass to simulate circuit probabilities via sampling.WeakForwardSimulatorclass to be more standalone, calling the newacton_randominterface of representations and utilizing a POVM representation when available.unitary_to_standard_gatenamefunction.basisargument to many of the operation classes. This argument is needed to convert to/from Kraus representation, but can be set toNoneif this functionality is not required.OpRepDenseUnitary,OpRepKraus,OpRepRandomUnitary, andOpRepStochasticclasses to"densitymx"and"statevec"evotypes (and their "_slow" versions) where needed.