-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GSoC 2015 Proposal Discussion #20
Comments
I think those directions are good enough for a 12-14 week long project. @acroy can definitely guide you to achieve this goal. He has a prototype package under development already. If you would like to be more ambitious--maybe @acroy has already told this to you, I think you can consider highlighting and integrating some advanced features of Julia language into the project--for example, parallel computing on multi-thread CPUs, clusters and GPUs. Considering the nature of GSoC, I think they would like to see more exciting features of programming techniques being integrated into a project. On the other hand, there have been a lot of tools for simulating quantum dynamics written in other programming languages. Parallel computing and a few other native features of Julia could make your work unique and appealing. In the proposal, you may want to include an over review section on existing packages (like QuTiP and Sagemath you were working on before) and their drawbacks, and explain what features that you are capable and going to implement could make your project superior than the others. Those features as optional buttons for future users may be relatively easily employed while you are designing the library from scratch rather than to be developed as separated plugin packages. Certainly, all of these should be decided with your mentor under serious discussions. Good luck with your endeavor! |
@i2000s thank you for the reply. For the starters I have looked into the implementation of solvers in QuTiP. Coming to the use of parallel computing on multi thread CPU's, clusters and GPU's, could you further provide me with references on what we could possibly implement, as my knowledge is bit limited in the applications of these fields to quantum ideas. But that said, I would like to target these in the second phase (post mid-term review) of the project as I would like to focus more on constructing the base machinery in the first half . For this I was looking through the dynamic solvers and time evolution in QuTiP here. I am trying to go through the limitations of the various implementations in QuTiP as well as others and will try to come up with what we can do better to tackle some of the issues these packages are facing, if any, in terms of efficiency and robustness. Hoping to hear from the community on the issue of what we can implement on a basic level which could possibly incorporate the parallel computing features of Julia. |
Maybe I should explain a bit what I had in mind: There are plenty of methods to propagate quantum states ("direct" matrix exponentiation, "classic" ODE solvers, Monte-Carlo based methods, ...). The goal of the project would be to come up with and implement a generic framework/interface, which makes those different methods useable for JuliaQuantum. It is not necessarily about implementing more methods. In fact, there are already quite a few solvers available (ODE.jl, Sundials.jl, ExpmV.jl, Expokit.jl, ...), which we could try to use (and maybe contribute to improve them). One idea would be to have a function The framework should in particular support parallel methods like MCWF (there is a mcwf branch and a PR for it in QuDOS.jl). So we will need options to set the number of processes etc ... |
All sounds good. Just to clarify on the PR I wrote for QuDOS.jl: it was targeting at including both CPU and GPU parallel-computing supports when a potential contributor expressed interest on this direction. However, this task on flexible parallel-computing was not implemented in the PR. It may also have bugs, for example, on the random number generator which could be a problem of Julia V0.3. At the time of coding, that collaborator who was studying parallel computing in Julia from the MIT Julia studio where I met him for the first time then may have become very busy on other stuffs and shifted his interest afterwards. I wrote the code mainly to help him understand the MCWF algorithm with very detailed commits. @amitjamadagni, you may find the PR helpful for you to understand the basic algorithm of physics as it re-implemented the same MCWF functions of QuTIP in Julia, but you need to think out more details on parallel computing and other useful techniques. |
@i2000s thanks for the insight.
We still need the idea of density matrix in QuBase which plays quite a crucial part in the scheme of things, but that said I would be making a draft of the proposal of the project with above references including the construction of density matrix which might be done before we start with the actual project, given the fact we are given a slot. I will try prototyping the ideas mentioned by @acroy, in one of the previous comments, in the process of the construction of the proposal. Any further references and also any further comments would be really helpful. Thanks. |
@amitjamadagni If you have time for this generalization work, also check this summary for related packages. |
@i2000s @acroy I am looking at essolve, mcsolve, mesolve, propagator, sesolve, stochastic implementations in QuTiP. These above would form |
@amitjamadagni To me, those are a good set to begin with. The PR to QuDOS.jl is a straightforward functionality clone to the QuTiP counterpart. You can see it becomes much cleaner and simpler, which is a result of the language itself. Due to the language differences, I would suggest you start from the algorithm documentations of those QuTiP functions rather than the Python codes (they are unnecessarily complicated). With a clean mind on the theory and algorithm, you can write a good Julia code and then you can dig into the Python functions for comparison later. For fast implementation, testing or benchmarking, you could also use their Fortran solvers like For parallel computing part, QuTiP uses I have contacted some core developers of QuTiP days ago, as most of them are shifting their attentions to other directions. I have also announced in the QuTiP discussion group regarding our projects in Julia. They may interact with us at some point. Feel free to ask questions on QuTiP through their discussion group and redirect this thread to them. |
@i2000s Thanks for this !!!! |
@i2000s : Do you know which license QuTiP uses? @amitjamadagni : This looks like a reasonable list. As Qi said you could start by trying to understand the implementation of mcsolve in QuDOS.jl (the mcwf branch might also be interesting, but is not well documented)... |
@acroy I think the QuTiP is licensed under the much open BSD-3-clause. So, we can definitely reuse their codes with a proper license attached in source code and binary product of our future package. |
@amitjamadagni : Note that we can make use of (multiple) dispatch in Julia to make Regarding parallelization I would say that there are different "levels" at work here. One level would be anything that concerns linear algebra operations (like matrix-vector multiplications, solving linear systems, ...). For those we basically have to support the respective kind of container type for our |
@i2000s so as I understand it we need to write 3 methods ( |
@i2000s please ignore the above comment. It does not make much sense. Sorry for the above comment. |
@i2000s @acroy I have been going through the documentation of QuTiP as well going through the implementation in QuDOS. Here are few ideas and doubts I have :
We can have internal helper functions for ODE, Monte Carlo to avoid duplication. So the idea is to have a These were few ideas I had after referring to the documentation of QuTiP. I will be going through the algos involved (mainly Quantum Monte Carlo), integrating ODE.jl and also parallelization packages with the current scenario. The proposal period starts this Monday and I would like to base the prototypes on the above ideas. It would be really helpful to know if this is going in the right direction. |
@amitjamadagni : I am sorry, that I can give only a brief reply, but I am traveling at the moment ... Re time-dependence: for this we can use separate types as I mentioned above. This type would store a user supplied function, which gives say the Hamiltonian at a given time. The time-independent case would really be just a special case of this, where we define a function which always returns the stored Hamiltonian. (note that this is just one possibility to resolve this issue). Re "dispatching" I am not entirely sure what you mean here, but I would like |
@acroy Were you referring to something like this (similar to propagate.jl in QuDOS) abstract QuantumPropagator
type mesolve <: QuantumPropagator
H::Hamiltonian #given we construct a time independent and time dependent.
collapse_ops
init_opts
tlist
method
options
function mesolve(H::Hamiltonian, .......)
# new master equation solver On similar lines we have sesolve And when we use we call (again from the idea in QuDOS) propagate(prop :: one of the above types, init_opts, tlist, method, options) and for methods we could have something on these lines : abstract qumethod
type rk45 <: qumethod
type krylov <: qumethod
type mcwf <: qumethod Hoping to hear from you. |
Almost :-) What I meant is, that we have types for the equations, say (just as an example)
Then you call
If we would go with an iterator interface we will need methods
Similarly, we would have What do you think? |
@acroy nice !!!! It looks great. Thanks a lot, it provides good clarity :-). I will go through the iterator interface, seems like we would be getting the evolution at different times, if I am not wrong. I will start writing the proposal with few specifics of the algorithms that need to be implemented also including the ideas we have discussed till now. So just to summarize the work to be done, which should reflect in the proposal : Few doubts : I was trying to get going with ODE.jl, though it might not be the topic of discussion I am not able to end up with an output for an example. Here is the error I get,
Any comments on this would be helpful. |
Try |
👍 it works !!! |
@amitjamadagni @acroy Sorry, I was busy on other things. I think you have made a good progress through this weekend. Just one complementary point on the _dispatching_ feature which should be an important feature to mention in the proposal (I think I have discussed with @acroy before, and I have a sample of its usage in the PR):
We should see if people would agree this point as a general principle to define functionality in JuliaQuantum projects... Hope this helps. |
What do you mean by "algorithms that are specific to the solvers"? |
@acroy for example the krylov subspace propagation in QuDOS depends on expmv! and in QuTiP it is from eseries and esolve. So the algorithmic implementation as I understand is different. |
Ah, ok. So for the matrix*exponental case there is for example also Al-Mohy and Higham's alrorithm (see ExpmV.jl). There are several "classic" ODE solvers depending on the structure of the right hand side (see ODE.jl, Sundials library and DASSL.jl to get some idea). |
I would be happy to mentor a GSoC project for [JuliaQuantum](http://juliaquantum.github.io) - an organization for developing Julia libraries related to quantum science. See also JuliaQuantum/JuliaQuantum.github.io#20 for discussions of the project proposal.
Should we close this issue to avoid confusions from this year's GSoC project discussion thread? |
Sure ! Let me slightly change the title to include 2015 and close this ! |
I would like to put forward a proposal for participating in Google Summer of Code 2015 as a student under the possible mentorship of @acroy. Though Julia has not been selected as an organization this year, we could submit the proposal to NumFocus which has Julia as one of the sub-orgs. One of the key requirements is a good structured proposal detailing the idea of the project along with the implementation design. @acory had suggested the following as potential projects :
Design and Implement a unified framework for propagating quantum states
It would be really helpful to hear from the community more about the above ideas and also other ideas which could potentially end up in a project spanning over 12 - 14 weeks. The combined efforts would result in the construction of a robust Julia based Quantum Library. Hoping to hear from the community. Thanks.
The text was updated successfully, but these errors were encountered: