realigning #1
Merged
realigning #1
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
The list of pulses were not correctly passed to the method.
The internal processing of noise is simplified. instead of adding Pulse object to the pulse list, Noisy dynamics are added to a dummy pulse object called systematic noise.
Add control_noise as an equivalent description to coherent_noise. This one is more common among experimentalists and causes less confusion.
Add a empty get_noisy_dynamics method as a place place holder and docs. Add _apply_noise for internal post processing.
Improve the noise module The internal processing of noise is simplified. instead of adding Pulse object to the pulse list, Noisy dynamics are added to a dummy pulse object called systematic noise. Update the test. The test was not correctly collected by pytest, because the name was Test with capital T.
Use Scipy interpolation for plotting
A wrapper for spline_kind, using discrete and continuous instead of steup_func and cubic.
In QuTiP capital letter are used for operators, like H. Due to historical reason, N is used in qip for number of qubits. We would like to replace it with num_qubits in qutip_qip. Start from this wrapper.
Now that wheels we be built from CI, and we will want to release direct
to PyPI/conda from there, it's more useful to have a single file that
can be simply read and parsed by the CI shell. This also means that
release versioning changes need only affect a single file, and this file
can be populated from git tag or similar.
The "ISRELEASED" flag is now moved to either a commandline argument to
setup.py (--release), or by setting the environment variable
CI_QUTIP_RELEASE
to be non-empty. The environment variable strategy is better for CI
(hence the name), where tools like cibuildwheel can't pass on
command-line options to our setup.py.
We still create a git hash if not in release mode and git is available
(or add '+nogit' if not), in order to distinguish between release builds
and local versions in bugfixing.
Wheels are automatically built on all pushes to the default branch (including PR merges), and can be manually triggered from the GitHub Actions web interface. Use Python package cibuildwheel to build wheels for Linux (manylinux*), macOS and Windows.
Separate out most packaging data into the relevant new configuration
files, rather than mixing our data and code together in setup.py. We
still rely on setuptools, and some parts of our Cython infrastructure
and versioning system still rely on us executing the setup.py file, but
with the additional data in pyproject.toml and setup.cfg, this can now
be handled in a more abstract manner by a range of build tools.
Cython is required at install time here, but we also make sure to
distribute the .cpp files with the source; in theory it should be
possible to build QuTiP without Cython as long as we do that, though
right now we're not set up for it.
We swap to package- and module-discovery techniques rather than
enumeration; it simplifies development of new packages a little, and
should be less error-prone.
You can now do
pip install -e .
_or_
python setup.py develop
in the git root to install QuTiP in editable mode. The former will work
as long as a suitable Python and pip are available; all build
dependencies will be fulfilled during the run.
However,
pip install -e .
will install build dependencies in a temporary venv, which typically
causes Cython to re-cythonise all .pyx and .pxd files, regardless of
whether they are out-of-date. See, e.g.:
https://discuss.python.org/t/pep-518-and-editable-mode-dont-install-already-satisfied-dependencies/3124/9
This may be improved in a future version of Cython.
Nowadays, we expect Visual C++ tools as the compiler on Windows, no matter what version of Python is being used.
This is the old name of the new NPY_ARRAY_OWNDATA flag.
We only want to build in extra sources to the modules that need them, in order to keep compiled code size down as low as possible.
There doesn't appear to be a reason to prefer an old version of Ubuntu here, particularly as most of the build is done within a Docker image anyway.
We don't build Python 2.7 wheels, so we don't need the Python 2.7 build tools. Normally you need some special headers and considerations on Windows because the Python 2.7 headers use C++ features that the VC++ never implemented properly.
Previously the build would continue, just with a sentinel to show that the deployment would not occur. This was to allow the case when you just wanted to build the wheels. Now, you get the same behaviour if you don't enter anything. If you enter something, but it _doesn't_ match, then the build will fail immediately. This should just be a little easier, since you won't have to manually cancel it if you get it wrong. We have to have a slightly unusual dependency graph for our jobs (everything depends on deploy_test) in order to fail as quickly as possible. As of 2021-03, GitHub Actions doesn't have a simpler method of cancelling jobs that are executing on other runners, so this is the cleanest solution without making external API calls.
Tarballs are the only official sdist in PEP 517, but for ease of use for Windows users we still want to build and distribute zipfiles, like we have done in the past.
Build wheels and distribute to PyPI (pip) from GitHub Actions
Newer versions of cvxpy (1.1+) had introduced some problems for us with sparse matrices: see cvxgrp/cvxpy#1159, which at the time of writing was still unresolved. This introduces a new method of sparse-matrix packing to workaround the issue based on a method in the linked issue, and adds a dense-matrix option to dnorm in cases where the sparse algebra does not work. The sparse form should typically be used, because the superoperator representation of a quantum channel will usually cause the dimension to be rather large, except when dealing with states of only one or two qubits. Also in cvxpy 1.1+, the '*' operator for matrix multiplication now issues a DeprecationWarning in favour or using '@'. cvxpy 1.0 also supports '@', so the change is safe. The memoisation was previously made over dnorm_problem, however really the only slow operation was the call to tensor_swap. The new method of sparse-matrix packing makes the construction of the optimisation problem strongly dependent on the sparsity structure of the supplied channel, so memoisation over the full problem creation is not useful. Instead, the memoisation is moved to be only over the tensor_swap operation, which also minimises the risk of modification of mutable values. Co-authored-by: MrRobot2211 <felipebihaiek@gmail.com> Co-authored-by: Jake Lishman <jake@binhbar.com>
MrRobot2211
pushed a commit
that referenced
this pull request
Dec 22, 2021
MrRobot2211
pushed a commit
that referenced
this pull request
Dec 22, 2021
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.
Checklist
Thank you for contributing to QuTiP! Please make sure you have finished the following tasks before opening the PR.
You can use pycodestyle to check your code automatically
Delete this checklist after you have completed all the tasks. If you have not finished them all, you can also open a Draft Pull Request to let the others know this on-going work and keep this checklist in the PR description.
Description
Describe here the proposed change.
Related issues or PRs
Please mention the related issues or PRs here. If the PR fixes an issue, use the keyword fix/fixes/fixed followed by the issue id, e.g. fix qutip#1184
Changelog
Give a short description of the PR in a few words. This will be shown in the QuTiP change log after the PR gets merged.
For example:
Fixed error checking for null matrix in essolve.
Added option for specifying resolution in Bloch.save function.