-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Report generation fails during diamond norm computation #6
Comments
I should add there is nothing pathological about the data. A can compute the diamond norm through other means without a problem. |
Hi Marcus, On May 18, 2016, at 8:36 AM, Marcus P S <notifications@github.commailto:notifications@github.com> wrote: I should add there is nothing pathological about the data. A can compute the diamond norm through other means without a problem. You are receiving this because you are subscribed to this thread. |
Using the most up-to-date version of |
(This following are an email I sent to Marcus and his response. Apologies for the repetition; wanted to merge both emails into the github thread. My mistake for not writing here first!) My email: Hi Marcus, Thanks for bringing this to our attention. We’ll try to get to the bottom of this asap. A few quick questions for you:
pygsti.gatetools.diamonddist(pygsti.construction.std1Q_XY.gs_target['Gx'],pygsti.construction.std1Q_XY.gs_target['Gy’]) (If it works, you should get about 1.732; however, I wouldn’t be surprised if it fails with the same error message.)
import cvxpy (I’m running 0.3.0, apparently.)
I just switched to the master branch and successfully run the diamonddist function, but I’m having some proxy issues so I haven’t pulled the latest version of the repo; will fix the proxy problem shortly and see if I can reproduce the error your seeing. Sincerely, The response from Marcus: Hi Kenny, "1. Can you try directly computing the diamond norm using pygsti.gatetools.diamonddist(pygsti.construction.std1Q_XY.gs_target['Gx'],pygsti.construction.std1Q_XY.gs_target['Gy’])
This fails in the same way as before. "2. What version of cvxpy do you have installed? Just run in an ipython import cvxpy (I’m running 0.3.0, apparently.)" I am running 0.4.0, and tested with 0.3.6 and had the same behavior. I had cvxopt 1.1.8 installed, and tried 1.1.7, but nothing changed. "3. Which branch of the pygsti repo are you using? I imagine it’s I am on the master branch. "I just switched to the master branch and successfully run the Sincerely, |
It turns out the issue was When I tried testing Figuring out what is the problem in To summarize, the version of |
Answering Erik's question, yeah, this was with pyGSTi @ master. |
@marcusps Could you indicate a recent commit in your git log? Independently of the I would like to try and figure out where that change was introduced, because it means that, as far as the development history is concerned, it should not have been possible for this code
to execute in the first place... 😒 |
I did not run that line as Kenny sent it. I changed But, for completeness:
|
That feeling when you realize you weren't paying as close attention as you could have... 😳 I just noticed that you had the line from pygsti.construction import std1Q_XYI in your notebook. Then, I assume that your test of Kenny's pygsti.gatetools.diamonddist(pygsti.construction.std1Q_XY.gs_target['Gx'],\
pygsti.construction.std1Q_XY.gs_target['Gy']) looked more like pygsti.gatetools.diamonddist(std1Q_XYI.gs_target['Gx'],std1Q_XYI.gs_target['Gy']) which would, in fact, at least execute without throwing any kinds of errors as to whether the import pygsti
pygsti.construction.std1Q_XYI.gs_target['Gx']
AttributeError Traceback (most recent call last)
<ipython-input-2-9c0557982708> in <module>()
-->1 pygsti.construction.std1Q_XYI.gs_target['Gx']
AttributeError: 'module' object has no attribute 'std1Q_XYI' which is why I was confused as to why things ran on your machine, Marcus. But now I see that, via the import statement, you probably ran a slightly different snippet (after all, as you pointed out, we wanted to test the So, Kenny, I am at a loss as to how you were able to get your code to run earlier, but no longer...😕 |
I just tried running @marcusps' minimal example on Mac OS X 10.11.5 with Anaconda as my python distribution, and it didn't successfully execute for For all of this I'm running For SolverError: Solver 'CVXOPT' failed. Try another solver. For ~/anaconda/lib/python3.5/site-packages/cvxopt/__init__.py in <module>()
240 return +reduce(base.ediv, args)
241
--> 242 base.normal, base.uniform = normal, uniform
243 base.setseed, base.getseed = setseed, getseed
244 base.mul, base.div = mul, div
NameError: name 'base' is not defined This appears to be a problem with cvxopt, but it strikes me as strange that others aren't having any difficulty using 1.1.7. I also tried running with SolverError: Solver 'CVXOPT' failed. Try another solver. However, when I ran with |
I may have identified the issue. In issue #11 I've documented that installing Can you verify this works on your system as well? I'm guessing it will, since it appears you are also using anaconda. |
So I (think I) installed This probably confirms @jarthurgross' suspicion that the issue has to deal with the installer for |
Can you run |
|
Hm, this problem does not seem to have gone away. I am running into it again on the If I uninstall cvxopt 1.1.8, install cvxopt 1.1.7, and restart the kernel, everything works fine.
|
BTW, I tried uninstalling cvxopt, then installing cvxopt 1.1.8 with pip and nothing changed.
|
Hmm, well this is disappointing. Before we start down the road of further debugging, could you confirm for me that the uninstall of conda's cvxopt and the reinstall with pip worked correctly by running Also, I am curious what your system details are. I thought you might have been using OSX since I had similar difficulties with OSX, but looking at your outputs now I'm wondering if you're running Linux instead. I just ran the notebook I made with your minimal example using the latest commit on the beta branch (9f3919a) and it executed without errors and gave meaningful diamond-norm values, so I suspect it is not the case that a new bug got introduced since I last looked at this. |
I'm using a docker image that runs on top of Debian Linux. I am simply I'll send you the output of pip list etc tomorrow, but there is not much to I don't think it is a new bug in the beta branch. It is exactly the same On Mon, Aug 8, 2016, 6:34 PM Jonathan Gross notifications@github.com
|
I'm running Ubuntu 16.04 (4.4.0-31-generic), which should be very similar to Marcus' setup. I installed cvxopt/cvxpy though the instructions here Pip list outputs the following:
Python versions:
Running the minimal example (without mxBasis='pp'), does not throw SolverErrors, and yields these pdfs (on python-2-7-12.pdf I'm still working on using the exact same docker image, but I'm putting this here in case it is helpful to anyone |
To reiterate:
|
First, here is what I did to replicate your setup:Here is your Dockerfile as I ran it (two mkdir commands have been commented out) FROM jupyter/scipy-notebook
USER root
RUN apt-get update && \
apt-get install -y --no-install-recommends libblas-dev liblapack-dev libatlas-dev && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
USER jovyan
RUN mkdir ~/work/data
#RUN mkdir /home/jovyan/.local/share # LSaldyt
#RUN mkdir /home/jovyan/.local/share/jupyter # LSaldyt
RUN /bin/bash -c "pip install git+git://github.com/ipython-contrib/IPython-notebook-extensions.git@master"
# RUN /bin/bash -c "source activate python2; \
# conda install lxml cvxopt=1.1.7; \
# pip install python-pptx; \
# pip install cvxpy==0.4.0; \
# pip install git+https://github.com/tonysyu/mpltools.git@master"
RUN /bin/bash -c "conda install lxml pip nose numpy scipy cvxopt; \
pip install python-pptx; \
pip install cvxpy==0.4.2; \
pip install git+https://github.com/tonysyu/mpltools.git@master"
RUN git clone https://github.com/pyGSTio/pyGSTi.git
RUN cd pyGSTi; git checkout beta; python install_locally.py # latest
VOLUME ~/work/data (The two commands were commented out because, for me they produced: I copied this to its own directory, and then issued lucas:~/test$ docker tag 8d6b03e2b106 marcus
lucas:~/test$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
marcus latest 8d6b03e2b106 3 minutes ago 5.261 GB
jupyter/scipy-notebook latest 746a019f1c2a 24 hours ago 4.669 GB
hello-world latest c54a2cc56cbb 5 weeks ago 1.848 kB
lucas:~/test$ Once the build finished, I used: lucas:~/test$ docker run -t -i marcus /bin/bash
jovyan:~/work$ The output of versions/package lists: jovyan:~/work$ conda list | grep cvx
cvxopt 1.1.8 py35_blas_openblas_203 [blas_openblas] conda-forge
cvxpy 0.4.2 <pip>
jovyan:~/work$ pip list | grep cvx
cvxopt (1.1.8)
cvxpy (0.4.2)
jovyan:~/work$ pip3 list | grep cvx
cvxopt (1.1.8)
cvxpy (0.4.2)
jovyan:~/work$ python --version
Python 3.5.2 :: Continuum Analytics, Inc. # Anaconda python! The kernel was the same as my ubuntu 16.04 install: jovyan:~/work$ uname -r
4.4.0-31-generic To verify that the minimal example fails:Here is your minimal example exactly as I ran it: (I ran this as a script, not as a notebook - if you'd like me to run it as a notebook, send me the correct docker command to start the image with (the same command that you use, preferably)) import matplotlib
matplotlib.use('Agg')
import time, pickle, os
import scipy as sp
import numpy as np
import pygsti
from pygsti.construction import std1Q_XYI
gs1Q = std1Q_XYI.gs_target
gs1Q_test = std1Q_XYI.gs_target
fiducials1Q = std1Q_XYI.fiducials
germs1Q = std1Q_XYI.germs
maxLengths1Q = [0,1,2,4,8,16,32,64,128,256]
listOfExperiments = pygsti.construction.make_lsgst_experiment_list(
gs1Q_test.gates.keys(),
fiducials1Q,
fiducials1Q,
germs1Q,
maxLengths1Q)
gs_datagen = gs1Q_test.depolarize(gate_noise=0.003, spam_noise=0.05)
ds = pygsti.construction.generate_fake_data(gs_datagen, listOfExperiments, nSamples=2000,
sampleError="binomial", seed=2015)
pygsti.io.write_dataset("test.gst", ds)
results_test = pygsti.do_long_sequence_gst("test.gst",
gs1Q_test,
fiducials1Q,
fiducials1Q,
germs1Q,
maxLengths1Q,
# mxBasis="pp", Argument no longer exists
gaugeOptRatio=1e-7,
advancedOptions ={ 'memoryLimitInBytes' : 10*(1024)**3,
'depolarizeLGST' : 0.2,
'verbosity' : 3} )
results_test.create_full_report_pdf(verbosity=3) ResultsWith the above configuration, the script successfully outputs this:
I then found the ID of the container and copied the report: lucas:~/test$ docker ps -l
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3a508ce34064 marcus "tini -- /bin/bash" 8 minutes ago Up 8 minutes 8888/tcp jovial_roentgen
Resulting in a pdf report with proper diamond norm values: I'm willing to try this with different settings if needed Again, here were my settings: jovyan:~/work$ conda list | grep cvx
cvxopt 1.1.8 py35_blas_openblas_203 [blas_openblas] conda-forge
cvxpy 0.4.2 <pip>
jovyan:~/work$ pip list | grep cvx
cvxopt (1.1.8)
cvxpy (0.4.2)
jovyan:~/work$ pip3 list | grep cvx
cvxopt (1.1.8)
cvxpy (0.4.2)
jovyan:~/work$ pip --version
pip 8.1.2 from /opt/conda/lib/python3.5/site-packages (python 3.5)
jovyan:~/work$ conda --version
conda 4.1.11 Cheers, Lucas |
Notice that your versions of Yours:Before reinstalling cvxopt
After:
Mine:
And also notice that running something like Specifically:(From the link) To update CVXPY, first update NumPy and SciPy separately. Then run pip uninstall cvxpy; pip install cvxpy.Simply running pip install --upgrade cvxpy can cause errors, especially if you’re using Anaconda.Perhaps the same happens with |
I tried uninstalling both the pip versions and conda versions of
And, of course, running the example puts dashes in table 8: Reinstalling with pip only:
Notice that the version output directly matches yours after you reinstalled And after
Note that my version is |
It is rather strange that you get different behavior during the docker build of the Dockerfile. My understanding was that the Dockerfile would ensure identical reproduction, but you end up with a different kernel, get different behavior for the
docker build --no-cache -t gst-jupyter . |
I agree that the differing version of So, after trying the latest docker image, I would also try:
|
Hm. Now report creating fails for a different reason, so it is unclear if this problem is gone with the new base docker image from
|
Try running the minimal example as a script (or running it in ipython, removing |
I am not using magic functions, and I have tried without and without |
As a script (outside jupyter), I need to add In summary, if I update the base docker image, I get
To find out why |
I ran it as a script and it works fine. The problems seems to be the fact that when matplotlib is imported within Jupyter, there is a hook that enables inline plotting by default (it does not happen in a config file, but rather in scipy-notebook/mplimporthook.py). This hook is baggage from the base docker image My suggestion is that, invariably, Jupyter users will want inline plots anyway (they will want to look at data in other ways, not just within pyGSTi reports). Instead of forcing users to disable inlining, it may be better to find a way within pyGSTi to not require inlining to be turned off — by explicitly choosing a backend such as Agg within pyGSTi, or checking if inlining is enabled during report generating and then disabling temporarily, etc. But this is a separate issue from the diamond norm issue. The diamond norm issue seems to be due to |
I too had to use Since it looks like the latest version of (You can always re-open this if the problem persists) As for the pickling issues with matplotlib, you're welcome to open a different issue. (Problems with pickling seem to be documented in |
Yeah, I think we can chalk it up to an issue with the base docker image and close this up. |
This bug seems to be alive and kicking in the latest beta branch, and running outside docker. Dependencies were install with either
|
I'd say that it seems like Checking lapack_opt_info:
libraries = ['mkl_intel_lp64', 'mkl_intel_thread', 'mkl_core', 'iomp5', 'pthread']
library_dirs = ['/home/msilva/anaconda3/envs/pygsti2/lib']
define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
include_dirs = ['/home/msilva/anaconda3/envs/pygsti2/include']
blas_opt_info:
libraries = ['mkl_intel_lp64', 'mkl_intel_thread', 'mkl_core', 'iomp5', 'pthread']
library_dirs = ['/home/msilva/anaconda3/envs/pygsti2/lib']
define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
include_dirs = ['/home/msilva/anaconda3/envs/pygsti2/include']
openblas_lapack_info:
NOT AVAILABLE
lapack_mkl_info:
libraries = ['mkl_intel_lp64', 'mkl_intel_thread', 'mkl_core', 'iomp5', 'pthread']
library_dirs = ['/home/msilva/anaconda3/envs/pygsti2/lib']
define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
include_dirs = ['/home/msilva/anaconda3/envs/pygsti2/include']
blas_mkl_info:
libraries = ['mkl_intel_lp64', 'mkl_intel_thread', 'mkl_core', 'iomp5', 'pthread']
library_dirs = ['/home/msilva/anaconda3/envs/pygsti2/lib']
define_macros = [('SCIPY_MKL_H', None), ('HAVE_CBLAS', None)]
include_dirs = ['/home/msilva/anaconda3/envs/pygsti2/include'] |
After more digging, it is clear that:
Running
does not give that version (at least on several systems I have use, ranging from different Linux distributions, all the way to Windows). Instead, to get this to work I had to run
and similarly, to get
That seems to have fixed the issue. In order to avoid this problem it would be helpful to have a much more explicitly stated set of dependencies for the installation of |
Thanks for all the debugging work. It's still not clear to me that this isn't a case of the conda installation of cvxopt being messed up. Here's what (I think) is an accurate summary of this issue:
The overall takeaway seem to be that, for someone installing pyGSTi from scratch, its best to just use pip to install all the required packages and avoid conda, and if you still get the above error try using @marcusps's conda fix (previous post). The comments about needing a special version of OpenBLAS are interesting to me - and perhaps in some cases that's the issue. But I've installed pyGSTi on many machines (just using pip) and never had to worry about which version of BLAS was used. |
I'm closing this issue as I haven't seen or heard anyone having an issue with weird CVXOPT failures for over a year. I think this supports the explanation that it is/was a CVXOPT versioning or install issue, where some installs of CVXOPT would fail to solve problems where most others had no issue. Anyone should feel free to reopen this or start a new issue if this problem resurfaces. |
pyGSTi has started failing during report generation. It does not seem to be related to any specific data set (it has started failing on any data I throw at it, inscluding data generated by pyGSTi itself).
Failure seems to happen because CVXOPT cannot solve a convex optimization problem needed for the report (the convex problem related to the diamond norm). In essence, the result CVXOPT generates is not optimal, nor is the problem infeasible or unbounded, which indicates serious problems.
Here is a minimal example that leads to such failure
The result error message is
Here are the packages I have installed (and their versions).
conda_packages.txt
pip_packages.txt
The text was updated successfully, but these errors were encountered: