Add an example of multi-level systems

[neversakura]

• A 3-level system example (closed-system version)
• A 3-level system example (AME version)

[shobhan126]

Hi @neversakura
Planning to start contributing to this repo.
tutorial explaining why DRAG Pulse works might be a good instructive example that deals with multi-level systems.
see: arXiv:0901.0534
Planning to code that up as I learn this repo! Please let me know what you think.
Going through arXiv:1206.4197 as a reference for AME. Haven't settled on an example yet.

[neversakura]

Hi @shobhan126
Thanks for being interesting in the repo. arXiv:0901.0534 is indeed a very good instructive example that deals with multi-level systems. In fact, @Vinay-Tripathi did some simulations using DRAG pulses with HOQST in this paper: arXiv:2108.04530 (he is the first author). He may also be willing to share some of his code. Nevertheless, a clean example without all the complications of transmon modeling would be a better tutorial.

Also, arXiv:1206.4197 is a good reference for AME. [arXiv:1503.08767(https://arxiv.org/abs/1503.08767) is another good reference if you are looking for simple examples.

[shobhan126]

@neversakura Started working on it here. It's basically an initial commit with not too much details. Do you have any suggestions as to what all I should add? Thinking of splitting into two notebooks: 01a for closed and 01b for with a dissipative version. Let me know if that makes sense to you.

I feel like definition of tf as total annealing time is a bit confusing in context of an Evolution object. Took me while to figure out that I will mainly be using that for scaling purposes - and had to set it to 1 - in the context of the example.

Currently there everything is just passed as an Annealing object. Is there a plan to have different dispatches for Annealing problems vs Evolution problems?

Also it seems like all operators of the DenseHamiltonian are passed in as time dependent operator. Might it be useful to support time independent operators separately?

[neversakura]

@shobhan126 Thanks for the very nice work. I will take a deeper look at your notebook this weekend. Currently, my only suggestion is to also report the Gate error along with the population leakage (which I think is in your TODO already). Also, I think splitting the tutorial into two parts is fine.

I feel like the definition of tf as total annealing time is a bit confusing in context of an Evolution object. Took me while to figure out that I will mainly be using that for scaling purposes - and had to set it to 1 - in the context of the example.

Currently there everything is just passed as an Annealing object. Is there a plan to have different dispatches for Annealing problems vs Evolution problems?

Indeed the package carries some burden from quantum annealing. Defining everything w.r.t. a dimensionless time is not very intuitive in other scenarios. The package used to support defining things w.r.t. physical time but I removed that part since it added an extra layer of complexity. However, I think your suggestion of using Evolution as a different dispatch for this is a good idea, and I will try this again.

Of course, to solve the tf issue, we will also need to change how people define a time-dependent Hamiltonian. Currently, the default behavior is that every function should have a dimensionless time as the argument: DenseHamiltonian([f1(s), f2(s)], [A, B]). Without changing this behavior, we will need to introduce a keyword argument like DenseHamiltonian([f1(s), f2(s)], [A, B], dimensionless_time = false) so we can attach a tag to the Hamiltonian. Let me play with it a little bit.

Also it seems like all operators of the DenseHamiltonian are passed in as time-dependent operators. Might it be useful to support time-independent operators separately?

Yes, having a Constant type Hamiltonian would allow us to dispatch more efficient routines for that type. I will open up an issue for it. I think I will first add an interface and leave optimization for the future.

[neversakura]

Constant type Hamiltonian: USCqserver/OpenQuantumBase.jl#85
Defining things using physical time: USCqserver/OpenQuantumBase.jl#86