Custom function to mix controls

[will-atom]

Hi,
This is somewhat related to my earlier question here.

I would like to expose a certain set of controls to the optimizer, say Ω1(t) and Ω2(t). I then have functions F1(Ω1,Ω2) and F2(Ω1,Ω2) that are nonlinear functions of these controls, say perhaps something like

F1(Ω1,Ω2) = Ω1 * Ω2 / (A - Ω1^2)
F2(Ω1,Ω2) = Ω1 * Ω2 / (B - Ω2^2)

for some constants A,B. My Hamiltonian is then most conveniently parameterized as hamiltonian(H0,(H1,F1),(H2,F2)).

Is it possible to define a control problem in this way in QuantumControl.jl? In particular, can this be done for general functions F1, F2? In reality I have a large set of functions F that depend nonlinearly on a smaller number of controls, so that it is quite inconvenient to actually need to know the form of every F.

Edit: I see from this section of the documentation that I will probably need to implement a custom generator. My question then with respect to this section is whether I need to know analytically the derivative of each control amplitude $a_l(\epsilon_{l'}(t))$ with respect to each control function $\epsilon_{l'}$? It's possible but not very convenient to work these out.

[goerz]

Yes, as you found, "amplitudes" are intended for exactly this use case. You don't need a custom generator, specifically, only custom amplitudes. That is, you can still initialize your generator with e.g. hamiltonian(H0, (H1, F1), (H2, F2)), but you will need custom data structure for the F1, F2, etc. These have to fulfill the following interface:

• get_controls(ampl) must be defined and return a tuple
• all controls in ampl must pass check_control
• substitute(ampl, controls_replacements) must be defined
• evaluate(ampl, tlist, n) must be defined and return a Number
• evaluate(ampl, tlist, n; vals_dict) must be defined and return a Number
• The function get_control_deriv(ampl, control) must be defined
• If ampl does not depend on control, the function get_control_deriv(ampl, control) must return 0.0
• Otherwise, get_control_deriv(ampl, control) must return an object u so that evaluate(u, tlist, n) returns a Number. In most cases, u itself will be a Number.

You can check your implementation by calling QuantumControl.Interfaces.check_generator on the instantiated Hamiltonian. There's a QuantumControl.Interfaces.check_amplitude, too, but that only checks some of the above conditions, the remaining checks will be added in the next version.

As you can see, the required interface includes the derivative of each control amplitude with respect to each control function. There's no way around this: how else would you calculate gradients?

Maybe take a step back, though, and think about whether you really need all of this: Could you use the F1, F2, etc. directly as the controls, and then calculate the Ω1, Ω2, etc. from them after the optimization is done?

[will-atom]

Thanks, this worked!

I wrote a pair of structs:

mutable struct AnonymousAmplitudeControl
    func::OpCoeffFunc
    amplitudes::IdDict{Symbol,ControlAmplitude}
    params::HamiltonianParams
end

mutable struct AnonymousAmplitudeControlDeriv
    aac::AnonymousAmplitudeControl
    control::ControlAmplitude
end

function get_control_deriv(aac::AnonymousAmplitudeControl, control)
    if control in get_controls(aac)
        return AnonymousAmplitudeControlDeriv(aac, control)
    else
        return 0.0
    end
end

get_controls(aac::AnonymousAmplitudeControl) =
    Tuple(Base.Iterators.flatten([get_controls(amp) for amp in values(aac.amplitudes)]))

get_controls(aacd::AnonymousAmplitudeControlDeriv) = get_controls(aacd.aac)

where HamiltonianParams is a struct that I defined containing Ω1, Ω2 along with evaluate methods. To evaluate the AnonymousAmplitudeControlDeriv I used ForwardDiff.gradient(aac.func, aac.params) to find the gradient ∂f_∂a⃗ with respect to the amplitudes a. Then I did

∂a⃗_∂ϵ = [get_control_deriv(amp, aacd.control) for amp in values(aacd.aac.amplitudes)]

to find the derivative of each amplitude with respect to the control. Finally I summed ∂f_∂aᵢ ∂aᵢ_∂ϵ to find the total derivative of f w.r.t. ϵ.

Evidently I've actually wrapped ControlAmplitudes in more amplitudes here, which is not really necessary, but I wanted to use other features of ControlAmplitudes that already exist such as parametrizations and shapes.