acroy / qudos.jl Goto Github PK

In the current expmv function setting, the scalar _t_ input is limited to real numbers. In reality, to speed up the computing time, one can combine im/hbar_t as the scalar input _t* to avoid the costly scalar times matrix operation in the matrix _A. So, one solution is to allow complex type of _t inputs as well.

I have noticed that you have implicitly set _hbar = 1_. Could it be more realistic to explicitly use the usual hbar in all computing?

This issue is supposed to give a rough idea about the features/functionality I am planning to implement and would like to have (not necessarily in this package). Any help and comments are greatly appreciated. Apart from the points below there is of course still a lot of work to do regarding testing, optimization and documentation.

• Short term roadmap (i.e. stuff I have in some form in Julia, but which needs some sharpening up):
  • Probability distributions (Husimi, Wigner)
  • Runge-Kutta based propagator (using ODE.jl)
  • MCWF (aka quantum jump method)
• Mid-term roadmap
  • Redfield dynamics
  • Lindblad-like QMEs with time-dependent coefficients
  • Non-Markovian dynamics (mainly following U. Kleinekathöfer, J. Chem. Phys. 121, 2505 (2004))
• Long-term roadmap (or rather wishlist)
  • Quantum state diffusion (e.g. L. Diosi and W. T. Strunz, Phys. Lett. A 235, 569 (1997))
  • Hierarchical equations of motion method (e.g. Tanimura and Kubo, J. Phys. Soc. Jpn. 58, 1199 (1989))
  • Time-evolving block decimation (TEBD) algorithm (G. Vidal, PRL 93, 040502 (2004))

(The references given above are supposed to give examples for the respective method, they are by no means complete)

I understand that you have mastered all your own definitions of types. It might be helpful for open source developing to avoid defining unnecessary types, and at least to provide dismatching methods for the most fundamental type inputs.

Here is my suggestion:

1. Use the most common Array types (both sparse and full) as the first-class definition for functions/methods. In this way, combining your package with other packages or their conventions will work seamlessly. For developing this package, if you have any changes on the definitions of self-defined types, there will be little pain to adapt to those changes in all related methods since they are defined using the first-class types. One can focus on implementing general algorithms without worry about changes of the other parts of definitions, as a result.
2. Reduce your self-defined types through some level of generalization:
   1. For operators, just defining some commonly used ones is good enough. What I think is helpful is the Pauli operators in SU(N) rotational symmetric groups, creation and anniallation operators in Fock space, X(Q) and P operators in the real space. Users should be able to define their own operators based on this set of operators. However, I would not suggest you to work on this at this stage. We can wait for the completeness of the QuRep.jl or QuDirac.jl project to have a shape so that we can render their definitions here.
   2. Use the conventions of Quantum objects and function formats that have been widely used in other well-known packages like QuTIP in Python or QOToolbox in Matlab. For example, one might have experiences of using QuTIP and now want to try your package. If your package uses the conventions that has been used in the QuTIP(inherit almost all conventions from the QOToolbox), they will be happy to adapt to the new language. In practice, you might want to consider to define a similar Qobj type to combine all your QuState and QuStateVec business in one unified interface. The master equation type and such could be avoided, in the sense that all the related development of new functions have to consider to implement vast matching rules for all these kinds of definitions. You can check the mcsolve.jl function in my mcwf branch for what I have been suffering and what I have been working on to simplify the definitions without breaking your conventions (WIP). However, you can change your definitions at any time, since I have define the first-class methods does not rely on any extra packages.
   3. For the computational setting part, you might want to define a configure type just for a unified interface to the equation solvers. These setting parameters are strongly determined by the expm and expmv functions and related ODE solving methods. So, it should include tolerance, number of processors to be used for parallel computing, max iteration times, alternative algorithms and so on. This part should be carefully designed.
3. Beyond all of the above, better to have some more comments on your code to explain definition of variables, algorithms and references while you are writing the code at the first time. Better formate your coding style and division of files will encourage people to participate your project.

Hope this helps.