Skip to content

Releases: LLNL/quandary

Python integration

18 Mar 18:42
Compare
Choose a tag to compare

Quandary can now be executed from within a python environment.

The python interpreter launches processes to execute the C++ code in the background. Compare the user guide and examples. The python integration adds some additional functionality over the C++ code, such as automatic computation of the required number of time steps, automatic choice of the carrier frequencies, and it allows for custom Hamiltonian models to be used (system and control Hamiltonian operators).

Other improvements:

  • The main C++ executable is now called 'quandary' (rather than good old 'main').
  • Two additional optimization regularization techniques are now available: One to penalize the overall energy of the control pulses, and one to penalize state variations. Compare the user guide.
  • More examples for both the C++ code and the python integration have been added.
  • Constructor of the optimproblem has been remodeled and cleaned up.
  • Unit changed for output of control pulses in control.dat, being in the frequency domain now (same unit as the user input for the transition frequencies, GHz, MHz, ...)

v3.0 Quandary with a python interface

05 Jan 04:53
Compare
Choose a tag to compare
  • A python interface is now available that allows to use (arbitrary) user-defined system and control Hamiltonian operators during the simulation and optimization process. The user constructs the Hamiltonian operators within a python script, which Quandary parses to receive the operators and stores in place of it's default operators. Further, transfer functions can be defined through the python interface which modify the native control pulses before applying them to the control Hamiltonians. An example can be found in the 'results' folder.

  • The control parameterization has been remodelled, including new ordering of the parameters and various configuration option changes:
    * For the B-spline parameterization, the storage of the control parameters has been re-ordered: Now the parameters iterate over oscillators first, then over carrier waves, then over the spline index, then list all real parts then list all imaginary parts. This new ordering is now compatible to the ordering of parameters in the Juqbox.jl code.
    * Each subsystem control can be parameterized separately from each other, using different number of parameters (spline basis functions).
    * In addition to the B-spline basis function parameterization, controls can be parameterized as a Step function with a fixed amplitude, where the control parameter determines the length of the pulse. Further, oscillators can be defined to be non-controllable alltogether, meaning no control basis functions.
    * Control parameterizations can be defined either over the entire time domain (default), or alternatively various time segments can be specified and different paramterizations can be applied in each of those time segment. For example one can choose to parameterize a control pulse in [0,t1] using splines with a certain number of basis functions, and constant in [t1,T]

  • Configuration option changes related to the new control parameterization:
    * Replace 'nspline' by 'control_segment' for each oscillator id
    * Replace 'optim_init' and 'optim_init_ampl' by 'control_initialization' for each oscillator id
    * Replace optim_bounds' by 'control_bounds' for each oscillator id

  • A higher-order time-stepping scheme is now available using Compositional Integration based on the Implicite Midpoint Rule. A 4th or 8th order accurate scheme can be chosen through the new configuration option 'timestepper' (default is the 2nd order Implicit Midpoint Rule)

  • Parallel distribution specification: The configuration options to specify the number of cores for initial conditions and Petsc distribution have been removed. Instead, those numbers are computed within the main code, where the number of cores for distributing initial conditions is always maxed out to the number of initial conditions that are considered, and the number of cores for petsc is computed by dividing the total number of cores by the number of initial conditions cores

  • Changes to the output:

    • Transfer functions that are applied to the controls are written to files.
    • The expected energy and population of the composite system are written to files.
  • The Parallel-in-Time XBraid interface has been removed entirely. It was depricated and did not work properly for many test cases.

Gate fidelity and state recomputation for Schroedinger solver

29 Apr 18:43
Compare
Choose a tag to compare

Changelog:

  • In the Schroedinger solver, recompute the primal state during adjoint back propagation rather than taking it from storage.
  • In the Schroedinger solver, the reported fidelity is the gate fidelity, rather than the sum of trace overlaps of individual states. The gate fidelity takes relative phases into account, since the absolute value is only computed after the sum over initial states.

v2 Quandary for open and closed quantum control

26 Jan 06:24
Compare
Choose a tag to compare

Quandary can now solve either Lindblad's master equation for the density matrix (open quantum systems), or Schroedinger's equation for the state vector if no collapse operators are present (closed quantum systems). The latter drastically reduces the computational complexity, however system interaction with the environment are not taken into account in this model.

Changelog:

  • Solving Schroedinger's equation, if collapse_type == none. In that case, the system state is described by a vector of dimension N, rather than N^2.
  • Configuration option for the objective function changed: Previously 'Jhilbertschmidt' now 'Jtrace'
  • Adding a leakage term to the objective function that penalizes occupation of the highest modeled energy level per oscillator (guard level).

v1.1 Quandary for pure-state preparation and gate optimization

09 Sep 18:51
Compare
Choose a tag to compare
  • Generalizes the ground-state optimization to include a general pure target state. Optimization target can now either be a logical gate transformation, or a pure state for state preparation.
  • Implements pure-state preparation as published in https://arxiv.org/abs/2106.09148
  • Some configuration options changed! New options now include 'optim_target', 'optimal_objective'. Compare the 'config_template.cfg'.
  • Adding new options for initial states, including 3state initialization for gate optimization.
  • Generalization of the integral penalty term
  • Improved user guide