Skip to content

Commit

Permalink
Auto-merged develop -> beta (No conflicts, CI passed)
Browse files Browse the repository at this point in the history
  • Loading branch information
TravisCI committed May 16, 2018
2 parents ae68958 + c253829 commit 34f44b1
Show file tree
Hide file tree
Showing 20 changed files with 787 additions and 2,304 deletions.
8 changes: 8 additions & 0 deletions .gitignore
View file
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,9 @@ test/test_packages/cmp_chk_files/Fake_Dataset_none.txt.cache
*.aux
*.dvi
*.toc
build/*
dist/*
packages/pygsti.egg-info

# Packages #
############
Expand Down Expand Up @@ -88,6 +91,11 @@ scripts/profiling/report/tp_report.py
scripts/profiling/report/rigetti_nocache.py

# Profiling data #
#################
scripts/profiling/output
scripts/profiling/data

# Other Local-only Files #
############################
local

120 changes: 25 additions & 95 deletions jupyter_notebooks/FAQ.ipynb
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,7 @@
{
"cell_type": "markdown",
"metadata": {
"collapsed": true,
"deletable": true,
"editable": true
"collapsed": true
},
"source": [
"# Frequently Asked Questions\n",
Expand All @@ -26,93 +24,66 @@
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"---"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"<a id=\"what_is_gst\"></a>"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"## What is GST?\n",
"\"Gate Set Tomography\" (GST) is a protocol that attempts to infer the quantum operations a device is performing by analyzing data generated by it. The device is viewed as a black box, so that physics-level details of its construction and operation are not needed. GST characterizes quantum gate operations, state preparations, and measurement operations simultaneously, avoiding the chicken-and-egg problem of state and process tomography, which has been shown to be problematic. For more information about the algorithms and theory of GST, please see [*Demonstration of qubit operations below a rigorous fault tolerance threshold with gate set tomography*, Nature Communications **8** (2017)](http://dx.doi.org/10.1038/ncomms14485)"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"<a id=\"what_is_pygsti\"></a>"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"## What is pyGSTi?\n",
"PyGSTi is the name of (this) software, which implements the various parts of the GST protocol(s). It is written (almost) entirely in Python, and is released as an open-source software under the GPL license. \"pyGSTi\" stands for \"python GST implementation\"."
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"<a id=\"how_do_I_run_GST\"></a>"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"## How do I run GST (1 or 2 qubits)?\n",
"Using pyGSTi, running GST is fairly simple. Single-qubit GST is demonstrated in full in the [first tutorial](Tutorials/00 Getting Started.ipynb), and 2-qubit GST (though very similar to 1-qubit GST) is separately demonstrated in [this 2Q-GST example](Examples/2Q-GST: running it.ipynb). The core GST algorithm is run by calling `pygsti.do_long_sequence_gst` or `pygsti.do_stdpractice_gst`."
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"<a id=\"how_constrain_TP\"></a>"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"## How do I constrain my gates to be Trace-Preserving (TP)?\n",
"Constraint on the gates (and SPAM operations) in pyGSTi are imposed via the \"parameterization\" of `GateSet` objects. Each `GateSet` essentially knows how to map some vector of (real-valued) \"parameters\" to a full set of gate matrices and SPAM vectors - and whether a given set of matrices & vectors can be reached depends on whether there exists a set of parameters that maps onto it. The parameterization used by a `GateSet` object can be changed among commonly used parameterizations via the `set_all_parameterizations` member function. To constrain gates and SPAM operations to be trace preserving, simply call\n",
Expand All @@ -124,42 +95,29 @@
{
"cell_type": "code",
"execution_count": null,
"metadata": {
"collapsed": false,
"deletable": true,
"editable": true
},
"metadata": {},
"outputs": [],
"source": [
"my_target_gateset.set_all_parameterizations(\"TP\")"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"before calling `do_long_sequence_gst` or `do_stdpractice_gst` with `my_target_gateset`."
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"<a id=\"how_constrain_CPTP\"></a>"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"## How do I constrain my gates to be CPTP?\n",
"Similar to the above question, you simply set the parameterization of your target `GateSet` to \"CPTP\" before calling `do_long_sequence_gst` or `do_stdpractice_gst`. Note that currenlty this *only ensures that the gates are CPTP* - not the SPAM operations. (Attempts to parameterize the SPAM operations as such have resulted in poor performance and are considered an experimental feature.)"
Expand All @@ -169,9 +127,7 @@
"cell_type": "code",
"execution_count": null,
"metadata": {
"collapsed": true,
"deletable": true,
"editable": true
"collapsed": true
},
"outputs": [],
"source": [
Expand All @@ -180,62 +136,44 @@
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"<a id=\"what_is_gaugeopt\"></a>"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"## What is gauge optimization?\n",
"A \"gauge transformation\" is a special type of mapping from one gate set to another which preserves all predicted physical outcomes (hence the name \"gauge\"). Thus, gauge transformations map between physically equivalent gate sets, and the set of all gauge transformations partitions the space of gate sets into physically-distinct equivalence classes. **Gauge optimization** refers to the process by which one finds the gate set within an equivalence class which optimizes some metric - typically the frobenius distance between the gate set and some \"target gate set\". In pyGSTi, gauge optimization is invoked using the `pygsti.gaugeopt_to_target` method (which minimizes the distance between a `GateSet` and a target `GateSet`) or the `pygsti.gaugeopt_custom` method (which accepts a user-defined objective function)."
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"<a id=\"how_specify_gaugeopt\"></a>"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"## How do I specify the details of gauge optimization?\n",
"Specifying the \"details\" of gauge optimization is essentially specifying the objective function. The arguments of `gaugeopt_to_target` (detailed in its docstring and [pyGSTi's online docs](http://pygsti.readthedocs.io)) describe how to change which distance metric is used (the frobenius distance, process fidelity, or the Jamiolkowski trace distance) when comparing gates, and how to put different weighting factors on individual gates (via the `itemWeights` argument). In higher-level functions, gauge-optimization details are specified by simply creating a dictionary of `gauge_opt_to_target`'s arguments. Adding a new gauge-optimization to an existing `pygsti.objects.Results` object is demonstrated in the [\"adding new gauge optimizations\" example](Examples/GOpt: adding new gauge optimizations.ipynb). One particularly powerful way to control gauge optimization is by specifying an imperfect target `GateSet` which includes the errors you expect to see in the gates. This is simple to do, and outlined in the [\"non-ideal gauge optimization targets\" example](Examples/GOpt: non-ideal gauge optimization targets.ipynb)."
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"<a id=\"twoQ_GST_is_slow\"></a>"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"## 2-qubit GST is running very slowly - how do I speed it up?\n",
"There are two primary ways of speeding up the GST analysis within pyGSTi: 1) using more/multiple processors and 2) reducing the number of gate sequences being analyzed. The first option is achieved by passing the core pyGSTi routines (e.g. `do_long_sequence_gst`) a `mpi4py.MPI.Comm` object (and often a per-core memory limit too), and is demonstrated in an [example](Examples/MPI: running GST in parallel.ipynb). The second option involves more of a tradeoff, as decreasing the number of sequences with reduce the accuracy of GST and/or its robustness. Restricting GST to shorter sequences (reducing the \"max-lengths\" used) will result in less accurate estimates, i.e. larger error bars. The use of \"fiducial pair reduction\" techniques, outlined in [this tutorial](Tutorials/10 Fiducial Pair Reduction.ipynb), retains the accuracy of GST while eliminating sequences. This, however, results is less robustness and sensitivity to out-of-model errors."
Expand Down Expand Up @@ -268,20 +206,14 @@
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"<a id=\"reportGen_is_slow\"></a>"
]
},
{
"cell_type": "markdown",
"metadata": {
"deletable": true,
"editable": true
},
"metadata": {},
"source": [
"## Generating reports takes a long time - can it go any faster?\n",
"Currently there aren't many options for speeding up the core computation required to generate a report (using, e.g. `pygsti.report.create_standard_report`. One can, however, take advantage of the caching built into the pyGSTi `Results` and `Workspace` objects that can effectively speedup report-generation times. \n",
Expand All @@ -293,9 +225,7 @@
"cell_type": "code",
"execution_count": null,
"metadata": {
"collapsed": true,
"deletable": true,
"editable": true
"collapsed": true
},
"outputs": [],
"source": [
Expand Down Expand Up @@ -333,7 +263,7 @@
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython2",
"version": "2.7.10"
"version": "2.7.15"
}
},
"nbformat": 4,
Expand Down

0 comments on commit 34f44b1

Please sign in to comment.