Add QuBase.jl and QuDynamics.jl as Dependencies

[Roger-luo]

I rewrite Adiabatic QC simulator by define a simple time-domain solver from QuDynamics.jl. It looks cleaner than previous implementation...

I tested the performance, much better than previous implementation. But a little bit slower than GPU accelerated computing. I'll add this part later.

Will there be any time-domain solver for QuDynamcis.jl in the future? Or maybe considering add some APIs for modified operator function in QuDynamics.jl? @amitjamadagni

[amitjamadagni]

@Roger-luo the time dependence is already being supported in QuDynamics. Though it is not in the latest master you could pull this PR and also this wiki article and play around. Do let me know if it looks good ! :) I will start going through this PR soon ... sorry for the delay

[Roger-luo]

@amitjamadagni I looked up the time dependence PR, and I think I may not need the universal time dependence solver, as I need to offer tweakable routine in the implementation. I modified my own type of propagator and other types under QuDynamics.jl.

Since it would make the code neater, I tried to separate this part into a single package here and use it as a dependency in QuCmp.jl. The separated package about AQC is here: AdiaComput.jl. I use |> to offer a interface for tweaking the AQC's routines, which may need my own type of the QuEvolution

And I wonder if it will be better to split the current code to some small packages as dependency like JuMP.jl do. And QuCmp.jl could provide a interface introduce in my GSOC propsal as 2nd floor of this project. @i2000s

[i2000s]

@Roger-luo Questions regarding the structure of packages could require some insights on the theory part. I don't feel @amitjamadagni has the necessary knowledge to really sort it out clearly. If you can ask @Yongjianhan to write a review or have a chat on your PRs in terms of his theoretical insights, that would be helpful. You may have made things too complicated without a thorough discussion. In fact, I guess everyone is waiting for @Yongjianhan's theory review for your PRs as he has promised originally for the GSoC project. Otherwise, it's hard for people not working in your field to take responsibilities on your codes.

I guess you may have access to @Yongjianhan's github account, but please don't comment using his account. It's not good for his reputation in this way. Sorry, I haven't finished my notes for the discussions with JuliaQuantum people due to other duties. I'll turn back hopefully soon.

[acroy]

@Roger-luo : In general I think it is a good idea to first implement and try out a new propagator in a separate package. If it turns out to be of general interest one can include it in the main repo (QuDynamics in this case). You should be careful though not to use fields of types too much as those internals might change. I think we should provide accessor methods for those fields and if the methods are missing please open an issue. Also if you think additional functionality might be useful (like |>) let us know - otherwise such things might get lost.

I only had a brief look into your repo, but I found that you had to duplicate a lot of code from QuDynamics (in AQCShrodingerEq.jl). This is certainly something we should discuss, because it might indicate a design problem on our side.

[i2000s]

@acroy Great you are watching in! Thanks!

[Roger-luo]

@acroy I thought QuDynamcis.jl aims to

provide a unified framework for solvers for solving Dynamical Equations in Quantum Mechanics.

But simulating AQC need to modify the time line, since different operations may need to be inserted during the evolution.

I guess |> will be convenient to modify that. I'm not sure whether providing a way to tweak the propagator during the evolution is useful for general use? I'm not sure if this is useful for general use of a solver, but it seems to be convenient for simulating AQC. I'll leave an issue under QuDynamics.jl if other people also find this convenient (But it needs QuDynamics.jl changes its definition of QuStateEvolution from immutable to type )

I use the same design as QuDynamics.jl do, but the further use of this design will be used for inserting other routines like cooling. There is an example: cooling-assist

This needs to insert a cooling procedure during the evolution, which is neither dynamical equation nor propagator in solving a Shrodinger equation.

I duplicate code from QuDynamics.jl to realize storing a state and evolution percentage s in the AQCShrodingerEq.jl, which would be necessary for modifying them during the timeline. (therefore I use type rather than immutable)

[Roger-luo]

@i2000s I do not have access of Prof. Han's account, he actually receives our github discussion through email. :-) I'll ask him for review report recently, but he is not in the campus at present. I'll meet Prof. Han on 27th. The algorithm implemented here stays the same, I guess people could still give me suggestions on the structure design. And thanks for watching this.

And will there still be an annual meeting? Let me know if you need to ask for Prof. Han's availability. :-)

[acroy]

But simulating AQC need to modify the time line, since different operations may need to be inserted during the evolution.

This might be something one could possibly achieve by introducing callbacks?

I duplicate code from QuDynamics.jl to realize storing a state and evolution percentage s in the AQCShrodingerEq.jl, which would be necessary for modifying them during the timeline.

Subtyping QuEquation is perfectly fine (BTW it should IMO be <:QuEquation{0}), but it shouldn't be necessary to duplicate propagate. As far as I can see you only add eq.t=t and changed operator(eq, t) to operator(eq, current_t). The latter could be easily changed (although operator(eq, (t+current_t)/2) might be better in general but not for you?) To accomplish the former (eq.t=t) we could introduce a function set_parameter! or so, which the user can override. We could call it within propagate, say like set_parameter!(eq,time=t) and you can use that to store the time. If you think this might be workable, we should move the discussion to a separate issue ...