juliaquantumcontrol / grape.jl

Gradient Ascent Pulse Engineering in Julia

JuliaQuantumControl Dev Environment

The packages within the JuliaQuantumControl organization are tightly coupled. Development on any package should happen in conjunction with all other packages.

When developing on a Unix system (WSL is recommended on Windows), you should use this repository to set up a development environment:

git clone [email protected]:JuliaQuantumControl/JuliaQuantumControl.git
cd JuliaQuantumControl
make clone

This will clone all the active project repos within the JuliaQuantumControl organization into a subfolder of JuliaQuantumControl. You may then navigate into any of the project folders for development, e.g.

cd QuantumControlBase.jl
make test
make devrepl

The Makefile for each project is set up such that testing happens automatically against the current state of all sibling folders (the entire organization). Run just make within each project for available make-targets.

Org-level Makefile

You may also perform some development tasks across the entire organization by using make within the parent JuliaQuantumControl folder. E.g.,

make pull

will pull the current state of all org projects from Github,

make status

will show the state of all checkouts, and

make distclean testall

will run a complete set of tests for the entire organization.

You can also run

make devrepl

for a Julia REPL with the dev-version of all projects available. Note that this is in addition to the development REPL available for each individual project (make devrepl in the project folder), which also has access to the sibling projects.

Making Releases

If releases need to be made for multiple packages across the organization, they must be made in the order listed in the package table

For each package, for a release X.Y.Z, e.g. 1.0.0, do the following from the master branch:

• git checkout -b release-1.0.0
• Modify Project.toml to bump to the new version number, set compat for all dependencies in the JuliaQuantumControl org to the latest release (removing any >= specification)
• Make a commit with message "Release 1.0.0"
• git push -u origin release-1.0.0
• Create a pull request
• Apply the "no changelog" label
• Wait for continuous integration to finish
• Go to the main Github profile for the package
• Select the release-1.0.0 branch in the top left
• Click on the commit ID of the release commit in the table title row
• Comment @JuliaRegistrator register on the commit
• Wait for JuliaRegistrator and Tagbot to make and tag a release, wait for all CI to finish
• In the terminal, switch to the master branch
• git merge --no-ff --no-commit release-1.0.0
• Edit Project.toml to append +dev to the version number (e.g., 1.0.0+dev), prepend >= to the compat specification of all dependencies in the JuliaQuantumControl organization.
• git commit to make a merge commit, use "Bump version to 1.0.0+dev" as the commit message
• git push to push the master

The QuantumControlRegistry

Working with unregistered packages in Julia is tricky.. Therefore, we have a QuantumControlRegistry to register any packages within the JuliaQuantumControl organization that should not be or are not ready yet for the Julia General Registry. Packages must be registered either in QuantumControlRegistry or in General: when a package gets added to General, it should be removed from QuantumControlRegistry.

To add the QuantumControlRegistry to your julia installation, run

pkg> registry add https://github.com/JuliaQuantumControl/QuantumControlRegistry.git

To add packages to QuantumControlRegistry, or create new releases for previously added packages, use the LocalRegistry.register command in the org-level REPL (make devrepl), e.g.,

using LocalRegistry
register("./GRAPELinesearchAnalysis.jl/", registry="QuantumControlRegistry")

See

help?> register

or the LocalRegistry documentation for details.

grape.jl's Issues

State-dependent running cost

Is it possible to use state-dependent running costs?

Releases

This is an ongoing issue to trigger package registration

Add example/test for pulse parametrization

With the changes in JuliaQuantumControl/QuantumControlBase.jl#46 and JuliaQuantumControl/Krotov.jl#21, pulse parametrization in GRAPE should work out of the box. The example from Krotov can be ported to GRAPE.

Add example for the direct optimization of a unitary gate

I have static and time dependent Hamiltonian and I want to implement X gate to my system. I want to find pulses to implement my unitary. Do you have an example for it? I checked the examples but I could not see an example for implementing a unitary.

Thanks,
Best regards

Explore construction of full Hessian

According to Goodwin and Kuprov, "Modified Newton-Raphson GRAPE methods for optimal control of spin systems", J. Chem. Phys. 144, 204107 (2016), the full Hessian can be calculated without too much effort

Implement control-dependent running costs

Assuming J({ϵₙₗ}) = J_T({|Ψₖ(T)⟩) + J_a({ϵₗ(t)}) + ∫g_b({|Ψ(t)⟩)dt, we want to add support for the term J_a in GRAPE. We do not assume that J_a = ∫g_a({ϵₗ(t)})dt.

See JuliaQuantumControl/QuantumControl.jl#15

The user should be able to pass a function J_a and potentially grad_J_a to the optimize routine (respectively to the initializer for a ControlProblem). If grad_J_a is not given, a make_grad_J_a routine will use Zygote to produce grad_J_a via automatic differentiation.

The interface for the routines is as follows:

• J_a(pulsevals, controls, index_map, tlist) where pulsevals is a vector containing the combined pulse amplitudes from all controls, controls is a vector of controls (functions, in most cases), index_map is an IdDict that maps each control to an iterable of indices in pulsevals, allowing to select the specific values in pulsevals that are associated with a particular control. Lastly, tlist is the time grid.

• grad_J_a!(∇J_a, pulsevals, controls, index_map, tlist) should put the vector ∂J_a/∂ϵₙfor all values ϵₙ in pulsevals into ∇J_a.

• make_grad_J_a(J_a, controls, index_map, tlist) should return a grad_J_a! function by internally mapping to Zygote.gradient(pulsevals -> J_a(...))

The requirement to be compatible with Zygote motivates the use of the index_map, instead of the parameters dict that is used for propagation, which maps each control to a view of values in pulsevals; I don't think Zygote will deal with aliases: everything must be traceable directly to pulsevals.

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Optim.jl backend does not use e.g. `LBFGSState.x` as `pulsevals`

Unlike the L-BFGS-B backend, Optim.jl does not alias the pulsevals as the internal x variable in the optimizer. Thus, the propagation does not pick up any updates in the controls, as reported in JuliaQuantumControl/QuantumControl.jl#25 (comment)

The x values have to be copied back to wrk.pulsevals before any propagation.