GithubHelp home page GithubHelp logo

phionx / quantumnetworks Goto Github PK

View Code? Open in Web Editor NEW
10.0 2.0 4.0 95.58 MB

We present quantumnetworks as a numerical simulation tool with which to explore the time-dynamics of a driven, lossness, and nonlinear multi-mode quantum network using the Heisenberg-Langevin Equations. The applications of this tooling span quantum transduction, bosonic quantum error correction systems, quantum communication, and more.

Home Page: https://pypi.org/project/quantumnetworks/

License: MIT License

Python 100.00%
quantum quantum-computing quantum-communications mit physics

quantumnetworks's Introduction

quantumnetworks

License


Please checkout this presentation and paper for a quick overview of quantumnetworks!

Installation

Conda users, please make sure to conda install pip before running any pip installation if you want to install quantumnetworks into your conda environment.

quantumnetworks will soon be published on PyPI. So, to install, simply run:

pip install quantumnetworks

If you also want to download the dependencies needed to run optional tutorials, please use pip install quantumnetworks[dev] or pip install 'quantumnetworks[dev]' (for zsh users).

To check if the installation was successful, run:

python3
>>> import quantumnetworks as qn

Building from source

To build quantumnetworks from source, pip install using:

git clone [email protected]:Phionx/quantumnetworks.git
cd quantumnetworks
pip install --upgrade .

If you also want to download the dependencies needed to run optional tutorials, please use pip install --upgrade .[dev] or pip install --upgrade '.[dev]' (for zsh users).

Installation for Devs

If you intend to contribute to this project, please install quantumnetworks in develop mode as follows:

git clone [email protected]:Phionx/quantumnetworks.git
cd quantumnetworks
pip install -e .[dev]

Please use pip install -e '.[dev]' if you are a zsh user.

Motivation

We present quantumnetworks as a numerical simulation tool with which to explore the time-dynamics of a driven, lossness, and nonlinear multi-mode quantum network using the Heisenberg-Langevin Equations. The applications of this tooling span quantum transduction, bosonic quantum error correction systems, quantum communication, and more.

Codebase

The codebase is split across quantumnetworks/systems and quantumnetworks/analysis, which respectively provide solvers and analysis tools for several quantum network systems of interest.

Future Directions

Checkout issues to see what we are working on these days!

Acknowledgements

Core Devs: Shantanu Jha, Shoumik Chowdhury, Lamia Ateshian

Thanks to Professor Luca Daniel and our TA, Taqiyyah Safi, for invaluable feedback during the development of this package in the Fall 2021 iteration of Introduction to Numerical Simulation (6.336) at MIT.

quantumnetworks's People

Contributors

ateshian avatar phionx avatar shoumikdc avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

quantumnetworks's Issues

Fix kappa dt bug

For a SingleModeSystem with kappa = 0 and some gamma, we expect to see some exponential decay. However, if we make gamma very small (~0.0001), then we see some spurious exponential growth in the time dynamics. We saw this bug previously when the step size dt was too large.

It seems that the value of gamma or kappa influences the optimal dt by quite a bit. So maybe we need to do some validation to choose the optimal dt based on some bounds on the params?

Error Analysis based on parameter precision/uncertainty

General idea:
Let's say we measure parameter a ± δa, b ± δb, and c ± δc. Then, to find the error in f(a,b,c), we can sample the parameter values of a* in the gaussian distribution centered around a with standard deviation of δa (and similarly for b* and c*) and calculate f(a*,b*,c*) multiple times. Then, we can take the standard deviation of that set of f(a*,b*,c*)s to find δf.

Clean up and comment code

  • add docstrings
  • remove extraneous commented-out code
  • remove exp system
  • deprecate SingleMode and DoubleMode system (or at least add warnings to use MultiMode instead)

[demo] Newton solver convergence examples

  • Come to the PM meeting prepared to show your TA how you tested convergence for a few specific examples: some for which you know a good initial guess, and some for which you do not know a good initial guess and Newton does not converge well or does not converge at all. For this task you can use any linear solver you like in the Newton loop, including MATLAB’s backslash.

  • Test it out in the same examples to show improvement. [Note: keep in mind that comparing the internally precompiled LU or backslash operation in MATLAB against your interpreted GCR MATLAB code might be very unfair in terms of final execution time... what about memory?]

Fix GHz -> 2π x GHz unit discrepancy

We have been using 2π x GHz units for all of our system parameters (\omega, \kappa, etc).

This is the correct convention as the H-L eqs are written in units of 2π × GHz (e.g. Table II of the cavity optomechanics paper).

However, our comments, default values and demos are written assuming units of GHz, which is incorrect.

Let's clear up this discrepancy and use 2π x GHz units correctly.

[solver] couplings input should be a dict or matrix

The couplings input may be better represented by a dict with the following:

  • key (Tuple[int]): (i,j) coupling between node i and j
  • value (float): coupling strength
    We may also want to accept a full coupling matrix.

However, this would require a rewrite of both code and many demo notebooks...

[solver] model order reduction

PM 5 Tasks:

(25 or 50 points, show code) Select and implement ONE of the Model Order Reduction methods shown in PS5 (counts as one task - 25 points) or TWO (counts as two tasks - additional 25 points). Show several time domain simulations for different inputs, comparing the output of the original model with the output of the reduced model.
• If your case study is entirely linear, you are all set for the reduction.
• If your case study has a part of the system that is large and linear connected to a smaller nonlinear part only by few edges of the network (e.g. a few nonlinear heart/organs/devices connected by a large linear network of arteries, pipes, transmission lines or PDE diffusion domains such as heat, water or electromagnetic waves etc.), then reduce only the large linear part for this problem.
• If your case study system is entirely nonlinear, then before you reduce it, first “linearize” it around a representative operating point (aka bias point) xi : i.e. choose also the task ”Code up a Model Linearization function” if you have not done it already.

Hint: To make sure you can see some advantage from the reduction, scale up the linear part of your
original model to a large size before you attempt the reduction. E.g. increase any spatial discretization
resolution, or add more nodes and elements to your network by duplication.

Initial Thoughts:

We can propagate the diagonalized linearized system for an O(N^2) -> O(N) speed up, since diagonal matrix times vector multiplication is O(N):
Screen Shot 2021-11-01 at 1 49 18 PM

[solver] Compare Explicit vs. Implicit time domain ODE integrators

  • Run our Forward Euler keeping ∆t fixed at all time throughout each individual simulation. Repeat
    the entire simulation for different values of ∆t:
    • Compute a “reference solution” xr(t) by running different simulations, each with smaller ∆ti < ∆ti−1, until convergence i.e. until you see no appreciable difference: ||x(t) ∆ti − x(t) ∆ti−1 || < �r, or you run out of patience...
    • Now instead run different simulations, each with larger ∆t, and find out what is the largest ∆tu before your simulation goes unstable. What error level does that corresponds to? Hint: use your previously compute reference solution to estimate the error level: �u = ||x(t) ∆tu − xr(t)||. How does that compare to the maximum error level �a that you “actually” can accept and live with for that specific application of yours?
    • If �a < �u, then keep running simulations with different values of ∆t ∈ [∆tr, ∆tu] until you find a ∆ta that approximately produces the actual level of error you can accept ||x(t) ∆ta − xr(t)|| ≈ �a. Is that time-step sufficiently safe, i.e. sufficiently smaller than the one that may give instability ∆tr << ∆tu? If so, that is probably a good starting choice for simulating your application.
    • ElseIf �u < �a, it means you could very much benefit (in terms of faster simulations) from even larger ∆t, but unfortunately you are limited by the absolute-instability of Forward Euler at large time steps. In this case you may find it beneficial to use your Trapezoidal code, running different simulations, each with fixed and larger ∆t > ∆tu. Find out what ∆ta approximately produces the actual level of error you can accept ||x(t) ∆ta −xr(t)|| ≈ �a. Is the Trapezoidal simulation time with ∆ta better or worse than the fastest Forward Euler simulation time before it goes unstable ∆tu? And at what level of error would Trapezoidal be faster than the the fastest Forward Euler?
  • Now try to adjust dynamically ∆t within each trapezoidal simulation run (i.e decrease ∆t whenever
    you detect that the solution is changing quickly in time, while increase ∆t whenever you detected that
    the solution is becoming smoother and slowly varying). Try also to monitor the dynamic solution
    xd(t) you are producing with respect to the reference and adjust ∆t so that to keep the error level
    on the same order of magnitude of the one you can accept and live with ||xd(t) − xr(t)|| ≈ �a. For
    the same approximate error level �a, is the overall simulation time when using dynamic time stepping
    faster or slower that then one with fixed time stepping?
    • Right now, this dynamic ∆t is not introducing any speed up, and instead affecting the accuracy of the final solution. Moreover, the code is quite dirty.. We should clean up the code and find a point where we get accurate and faster solutions. Otherwise, this is not worth including in quantumnetworks and can be left as a branch indefinitely...

feature: add simple timer to performance.py

In sweep_dt_err in performance.py, for any given dt, we currently measure the % error between a reference solution and a solution using a given integrator. As part of the final project presentation, added a simple timing scheme to measure simulation runtime.

Specifically, we specify time_iters --- the number of times we wish to repeat the integration solver. We then run the solver via
X = getattr(self.system, solver_method)(self.x_0, ts, *args, **kwargs) a total of time_iters times, and measure the initial and final clock times. We can then divide this total time to get the averaged runtime.

[solver] find periodic steady state

  • Use your time domain integration code of choice to show that for sufficiently large t, your problem
    settles into a periodic steady-state solution.

  • How many periods does it take to reach periodic steady state? Is it worth using a periodic steady
    state solver? Produce concrete arguments estimating times.

  • Use your Shooting-Newton code to find the initial state x0 that results in that period steady-state
    behavior, i.e., x(0) = x(T) = x0. Implement the state transition function Φ(x0, T) = x(T) using the
    same ODE integrator of your choice from t = 0 to t = T, with x0 as the initial condition.

  • Plot one period of the waveform that corresponds to the initial condition you found. Note that since
    your state x is a vector, you may need to plot the components of such vector at different times along
    the period [0,T]. Choose which components and which times to plot carefully not to overcrowd your
    plot. You should show a sample of waveforms representing well and clearly the evolution of your
    state during a period. On the vertical axis always show x. Then you can either:

    • put time on the horizontal axis and show a family of waveforms each corresponding to a different
      state component;
  • #40

One method (trapezoidal -> newton):

252267174_313159013678538_3444348497071779887_n

Shooting Method:

Theory: Optomechanics example

  • Write up the nonlinear + linearized equations of motion for the cavity optomechanics application.
  • Identify operating points for linearization.
  • Find experimental parameter values from papers, including sig figs and uncertainties.
  • Identify output quantities of interest and put into matrix form.

Add finite difference sensitivities analysis tool

Write code to compute the finite difference sensitivities in the quantities of interest given perturbations in the system parameters.

Look into adjoint sensitivity analysis in the project report template. Decide and argue whether it would or wouldn’t improve computation time in our case.

Minus sign error in Heisenberg-Langevin equations

In the initial project ideas doc, the HL equations were written:
Screen Shot 2021-09-27 at 4 38 40 PM

However, after some reading, it seems that I made a sign error in that document. The correct equations should be (now also including the intristic loss gamma of each mode):

Screen Shot 2021-09-27 at 4 39 07 PM

As a sanity check, this makes sense, since we expect dissipative behavior due to the dissipation terms. So the minus sign makes sense.

Write multimode helper that relabels system optimally

We can begin by labelling a multimode system arbitrarily. Then, we can use this helper to relabel the system to make it as diagonal banded as possible. This can help speed up LU decomposition which is useful when A (for a linear system) doesn't change.

Add intrinsic loss parameter

Add intrinsic loss parameter \gamma for each mode. Do this for SingleModeSystem, DoubleModeSystem, and MultiModeSystem.

Demo: Matrix Conditioning

Test different relative values of parameters to search for operating points at which the A or A + Jf_nl matrices become singular or ill-conditioned. These operating points may pose problems for steady state analysis, if we need to solve a linear system.

Demo: Purcell decay physics

Consider 2 coupled modes a and b, with only a coupled to a transmission line. If we have a large decay rate κ on a, then some of this decay will get 'inherited' by mode b, and we can measure it by fitting a decaying exponential to the time-dynamics of b. In the case of a qubit coupled to a readout resonator, we would call this effect Purcell decay, and so it could be interesting to see what happens in our system.

Vary Delta t and check convergence of x

Determine our choice of ∆t by checking the convergence of x: vary ∆t and look at the resulting change in x -- justify the level of accuracy we choose (the TAs will check this), and finalize that choice of ∆t

This can be done by creating an analysis utility class.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.