Feature qibo #257
Merged
Feature qibo #257
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 17 commits
May 16, 2022 09:19
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.
…cilitate this addition. The 'qibo' evotype uses the qibo package to perform circuit simulation, and works, so far, with MapForwardSimulator. A qibo state (rep) can be either a state vector or std-basis density matrix, and module-level variables in pygsti/evotypes/qibo can control which mode is used, along with the number of shots used for internal-to-qibo weak forward simulation. Holding a 'std' basis density matrix required that dense states be given a 'basis' argument, and that several other op & effect rep types and operations also take 'basis' arguments: - dense superop reps (only needed for implementing to_dense though) - (new) kraus reps - dense state reps - dense op objects (because of rep) - dense state objects (because of rep) Other operations/states/effects that would sometimes construct dense ops (ComposedOp, EmbeddedOp, ExpErrorgenOp, LindbladErrorgen, ComplementPOVMEffect, ComposedPOVMEffect, ConjugatedStatePOVMEffect, more?) and aren't given a 'basis' argument currently punt or are hacked, often resulting in the basis being set to None. This is marked for future fixing with "UNSPECIFED BASIS" comments. It seems best to create a standardized .basis attribute of state and maybe op & effect reps so that these operations can access the basis (or lack thereof - it should be allowed to be None) of a contained operator. Overall, this commit includes a partial plumbing of 'basis' arguments - particularly for those representation and operation classes that take dense vectors or matrices - so that the evotype has access to basis information. With a standard .basis attribute this infomation will be spread and accessible in all the different representation classes, which seems ideal, given that other 3rd party simulators may also benefit from this information. Adding a .basis attribute shouldn't add much/any performance overhead since the basis is just passed around by reference. At this point, the qibo evotype seems to work for simple 1Q circuits with the 'map' simulator, but more testing is needed.
Adds FullCPTPOp class, which parameterizes a general CPTP map via the Cholesky decomposition of its Choi matrix, and associates this with the "full CPTP" parameterization option. This commit also updates (fixes bugs in) the old CPTPState class, which wasn't really used unless via the "TrueCPTP" param type, and associates this state prep object with "full CPTP". There isn't any "CPTP-contrained" POVM type yet -- this is difficult because we can constrain each effect to be positive but then also need to enforce TP -- so the "full CPTP" param type currently punts and just creates a ComputationalBasisPOVM (labeled as a HACK within modelmembers/povms/__init__.py). This addition allows us to test the qibo simulator running 1Q GST with the "full CPTP" type (using "full" for "full TP" resulting in Kraus decomp errors midway through whenever the optimizer chose a point were a gate wasn't CP), revealing that qibo is *very* slow in this context due to circuit execution setup/initialization times. It may be that the qibo evotype can only be used effectively for single/few circuit simulations. The Quest simulator may allow for tighter integration in the future, and has greater potential for running GST or other many- circuit-evaluation protocols more efficiently. On a positive note, the qibo evotype did yield the same initial value of chi2 (and similar |J| values), indicating it probably computed the correct probabilities.
…=None args. Updates in recent commits changed the __init__ signature for StateRepDense and we forgot to update calls within the entirety of the oprep files. This commit fixes that, and fixes a few other minor bugs (also recently introduced) to get the densitymx and densitymx_slow evotypes working again.
The new IdentityPlusErrorgenOp class implements the first-order approximation to exp(L), 1+L, as an alternate way of using an error generator within an operation. This has the advantage that no matrix exponentiation is required, potentially saving computational time (and number of paths), though 1+L is only CPTP for small L, and so may lead to Kraus-decomp errors within evotypes like qibo. Additionally, the first order approximation doesn't compose as nicely nor does a low-weight L capture all the expected "physical" errors from such a process - so there are plusses and minuses to it. In any case, it's now an option to experiment with, and can be accessed by specifying '1+(<LindbladType>)' parameterizations, e.g. '1+(CPTPLND)' or '1+(H+S)'. This commit also adds support for more explicit parameter/gate-type naming, updating 'CPTP' to 'CPTPLND' when used as a Lindbladian param type (this is more accurate) and adding the ability to specify exponentiated errorgenerator paramterizations explicitly with 'exp(.)' names, e.g. 'exp(CPTPLND)' or 'exp(H+S)' instead of just 'CPTPLND' or 'H+S' (though these default to the exp versions). Specific support for IdentityPlusErrorgenOp is provided by the new OpRepIdentityPlusErrorgen representation class. This commit only implements this for the densitymx_slow evotype, though it should be straightforward within other evotypes - and *easier* / *simpler* to implement than the OpRepExpErrorgen class (e.g. could do this for qibo). If this new rep type is unavailable, IdentityPlusErrorgenOp falls back to using a dense op. Testing has been minimal at this point - a 1Q GST example with densitymx_slow.
… works. - Checks that LindbladNoise's .parameterization is a LindbladParameterization before using its .meta (HACK?) - Fixes return value bug for Lindblad coefficient block's superoperators and 1-norms (changes [] -> [],[] where appropriate)
…indblad". This is more consistent with the allowed lindblad parameterization formats (see LindbladParameterization.cast) and seems clearer, at least to me. This commit also updates the parameterization-type validation for the various ModelNoise objects, which may have been faulty previously (it hasn't been tested well enough yet to know).
"Tweaks" here are mainly for getting 1+(CPTPLND) parameterization to work with qibo evotype. Note that OpRepIdentityPlusErrorgen exists in the densitymx_slow but *not* in the densitymx evotype. (This would be trivial to add, but it's unclear whether this oprep type will be of much use, so we haven't bothered mirroring it yet.)
This commit gets the unit tests working again, and adds fixes and enhancements picked up by the unit tests that we missed during the initial implementation. Most of these are related to state reps now needing a basis to be constructed.
…list of installed packages. This should cause the new qibo evotype to be available to pyGSTi installations and should cause qibo to be installed when testing pyGSTi, e.g., from a GitHub action.
…*30. Because 2**32-1 is too high for the signed int32 type used by default in Windows. So we just lowered this to 2**30 to be safe.
This is needed for automated unit tests running with Python 3.6, which only is able to get qibo version 0.1.6. Lower versions don't contain all the needed gates, e.g. qibo.gates.S . Additional exception handling of an AttributeError is done in qibo/opreps.py to catch this when importing pyGSTi.
Used for testing version number of qibo in recent update to unit tests.
… option. There's really no need to keep the deprectated "TrueCPTP" option around any more, so we're cleaning this up.
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 initial integration of 3rd-party Qibo circuit simulator
Adds a new
"qibo"evolution type (evotype) in pyGSTi that causes pyGSTi circuits to be simulated using theqiboPython package. This circuit simulator has been built with scalability in mind, and implements numerous performance enhancements (see https://arxiv.org/abs/2009.01845). The integration adds the ability for many but not all pyGSTi operations to work with the new evotype. In particular, there is support for:There's currently no (efficient) support for exponentiated error generators, as exponentiation is not a natural or native operation within Qibo. As a potential workaround in the future, this PR introduces an alternative to the
ExpErrorgenOpclass namedIdentityPlusErrorgenOp, which implements the simpler operation of simply adding an error generator to the identity, effectively expanding aExpErrorgenOpto first order in the error generator. We'll want to test the utility of this alternative way of parameterizing error maps before adding too much implementation, and currently just thedensitymx_slowevotype implements an efficient native version of this operation. If it's found to be useful, it would be significantly easier to implement this simpler operation for 3rd-party simulators like Qibo.This added ability, coupled with the desire to have a more accurate description of pyGSTi operation types, has motivated the deprecation of the
"CPTP"type specifier in favor of"CPTPLND"or, better yet,"exp(CPTPLND)"or"1+(CPTPLND)". Similarly, type specifiers for reduced error-generator operations like"H+S"can be specified as"exp(H+S)"or"1+(H+S)"to causeExpErrorgenOporIdentityPlusErrorgenOpobjects to be built, respectively. Note that the bare specifiers, e.g.,"CPTPLND"or"H+S"are still fine to use and synonymous with the"exp(.)"versions - the latter is just more descriptive. In a related update,ModelNoiseobjects can how be given"exp(lindblad)"and"1+lindblad"parameterization types.As another alternative to an exponentiated error generator, this PR adds support for genuine CPTP maps. It introduces the new
"full CPTP"specifier, which parameterizes a gate by its Choi matrix and therefore admits any (not just an infinitesimally-generated) CPTP map. The"full CPTP"specifier creates states that similarly correspond to any valid (positive) density matrix, but currently just creates just a static computational-basis POVM. This marks an area for future work (see "TEMPORARY HACK" in povms/init.py), and means the"full CPTP"parameterization is only partially implemented and should be used with caution. Note also the the old"TrueCPTP"type, which was previously deprecated, has now been removed.Module-level
densitymx_modeandnshotsvariables inpygsti.evotypes.qiboset the "mode" in which Qibo operates, i.e., whether it propagates full density matrices or state vectors and how many samples (shots) it uses when estimating an outcome probability.Finally, an under-the-hood update that is only partially complete deserves mention.
StateRepobjects are now given abasisargument when they're created. This is needed for Qibo because internally all states are held in what pyGSTi would call the standard ("std") basis, and in order to interface with pyGSTi the state needs to be able to compute itself in an arbitrary basis (e.g. the Pauli basis) when itsto_densemethod is called. This needed argument causes a cascade of needing to specify basis arguments where they weren't needed before, and this plumbing could use more work in the future. Numerous places where this basis is just set toNone(fine for all evotypes but"qibo"so far) -- because we either don't have a plumbed basis to provide or because the interface for extracting a basis from a state or operation representation is not standardized yet -- are marked with "UNSPECIFIED BASIS" tags to ease future updates.