Add extra arg for modifying parameters after each iteration about krotov HOT 8 CLOSED

good suggestion to replace the name info_hook! but maybe there is an even more speaking name than iter_hook? hook does not speak to me but that may be my personal perceiption and it's clear to others...

The current info_hook does more than just calculate values that end up in Result.info_vals: It is also the proper place to dynamically modify the objectives or the λₐ. While an advance use case, this is very much intended, and the only way to to implement things like the following:

* Adjusting λₐ dynamically

* A "moving grid" Hamiltonian

* Filters that act on more than one pulse at the same time (e.g., when there is one pulse for the real part and one pulse for the imaginary part of a complex control, but a filter needs to be applied at the level of the complex control)

Generally speaking, the info_hook is where a user can inject arbitrary code into the optimization, after each iteration. To emphasize that the info_hook is not just for "information", it should be renamed to iter_hook.

from krotov.

I'm actually very much leaning towards removing filter from PulseOptions (which is currently ignored/not implemented!), and doing filtering only in the iter_hook. It simplifies the implementation of optimize_pulses significantly, and is more flexible.

from krotov.

The name is certainly up for debate! Does anybody have any suggestions?

from krotov.

I agree! Flexibility is important, and we should not try to be too comprehensive in our first version. So let's rather focus on finishing a basic version to which can be added later, for example via the info/iter_hook... As for the name, what do we want it do convey? It's an interface for advanced users to adapt the code to one's own needs. So what about interface in the name? And something like advanced and specific features?

I'm actually very much leaning towards removing filter from PulseOptions (which is currently ignored/not implemented!), and doing filtering only in the iter_hook. It simplifies the implementation of optimize_pulses significantly, and is more flexible.

from krotov.

Could I offer the name post_oct_iteration, or variations thereof (post_oct_iter, post_iter)?

Just to clarify: the current info_hook has 3 uses:

• Print information about each iteration (hence the current name): without an info_hook, the optimize_pulses routine generates no output on screen.
• Return one or more values such as the value of the functional J_T, the fidelity, or ∫gₐdt. These are then used by the user-supplied check_convergence, and are available in the ultimate Result object.
• Apply arbitrary modifications, e.g. for dynamic λₐ, or pulse filtering

The first two cases are very standard (nearly every example of optimize_pulses will want to use info_hook/post_oct_iteration for those purposes), while the third one is for advanced use only.

While *_hook (or equivalently *_callback) is an appropriate name for this kind of function, as an established term, it is very technical, and of course our audience is the quantum control physicist, not the professional programmer. Therefore, I think post_oct_iteration might be a good less technical name - actually, the type callable of the argument already communicates that this is a hook/callback. In any case, the goal would be to find a name so that a user's natural guess for "What is the likely purpose for the callable argument <name> to optimize_pulses?" comes reasonably close to at least the first sentence in the documentation:

info_hook (None or callable): Function that is called after each
    iteration of the optimization. Any value returned by `info_hook`
    (e.g. an evaluated functional J_T) will be stored, for each
    iteration, in the `info_vals` attribute of the returned
    :class:`.Result`. The `info_hook` must have the same signature as
    :func:`krotov.info_hooks.print_debug_information`. The `info_hook`
    may modify its arguments for certain advanced use cases, such as
    dynamically adjusting `lambda_vals`, or applying spectral filters
    to the `optimized_pulses`.

I think I would want to avoid the term "interface" in an argument name, because that has the opposite problem of *_hook: It is fine as an everyday term, but it would clash with a very specific technical meaning for object-oriented languages. My technical expectation for such an argument name would be that it receives an abstract base class or other kind of interface-specification, in some meta-programming context.

@Basilewitsch and @danielreich, and especially @karl-horn, @FernandoGago, and @MatthiKrauss (as "users" whose view might be less influenced by existing conventions in QDYN), what name would you find most intuitive to match the existing documentation?

from krotov.

for 2 out of the 3 uses, the name info_hook is actually perfectly fine (the first two that do only output). what is confusing is the third use where an output-related function suddenly starts to modify things. can't we just split this part off and write a completely separate function?
as to post_iter and its variations, to me that name is confusing, too, because I ask myself post as in "to post" or post as in "after"... but maybe that's just me.

from krotov.

That sounds good to me. So info_hook stays. Maybe modify_params_after_iter for case 3?

from krotov.

That sounds good to me. So info_hook stays. Maybe modify_params_after_iter for case 3?

perfect!

from krotov.