Objective

Why a rewrite?

On the whole, the Matlab version works exceedingly well for many standard problems. So why on earth would anyone write another Wavepacket code? There were two reasons: One was that certain things were not implemented at the time the C++ version started, although most of the limitations are no longer really valid. However, a few problems remain:

• The Matlab version requires Matlab. Matlab is a great environment with lots of convenience also for the user. However, even though licenses are not completely out of reach and cracked versions seem to exist, Matlab is still a heavy dependency. And there have been instances where this was a problem.
• The Matlab version follows a framework approach. Roughly speaking, it works a little like a prefabricated building that is delivered as a black box with a construction team. You can customize some aspects (here: the grid size, laser fields etc.), but the general outline is fixed. If you want to implement a use-case that was not envisioned by the code creators, things become complex pretty quickly.

Many people will never encounter these barriers, and in these cases, the Matlab version is perfectly fine. However, sometimes you do want a slightly weird use-case, and then you need to learn a lot of details or need to carefully set up relatively complex schemes. Two examples:

• You want to generate a thermal state using random thermal wave functions, and then propagate this state in time. This is not impossible to set up, but requires some advanced knowledge, and probably some brittle scripting to hold everything together.
• You want to propagate an open quantum system with memory effects. Several approaches, for example HEOM or Tannor's approaches (e.g. https://doi.org/10.1063/1.479669) store the memory of the bath in auxiliary density matrices that are coupled to the "real" density matrix. Your task, then, is to propagate a set of N+1 density matrices together. Again, this is not impossible to do, but not natively supported by the Matlab version.

Such use cases. which usually appear in open and thermal quantum systems, benefit from a different approach, the toolbox approach. Coming back to the house analogy, you would not get a house, but lots of standard components, say, window frames in all sizes, and all required tools, from which you build your own house. The drawback is that building a standard house is slightly more involved, but you can do very custom designs without digging too deep into details. For the wavepacket propagation, you would get a lot of standard components, like grids, operators etc., which you "only" need to plug together to represent your final differential equations.

Requirements for the C++ Version

• The code should be easy to use. It should be easy to set up and run a calculation by writing a simple program (run script). If written properly, you should be able to read a run script like a book (as opposed to setting some global variables). Nasty (numerical) details should be encapsulated, so that a normal user never needs to deal with them, even when doing complex things.
• It should be easy to do complex things. If you want to do something that is not trivial, such as optimal control, or propagating a density operator in an open system and comparing to the wave function propagation in the closed system, this should be straight-forward to do. You should not need to know too much about internal data structures, and it should be possible to write your run script as a direct representation of the formulas that you want to implement.
• Extendable Code. Where possible and reasonable, Wavepacket should be written in such a way that it can be rather easily extended later if we find a use case that we have not considered initially (semiclassical methods?).
• Tested Code. All components (operators, grids, propagators etc.) should have automatic tests attached so that you can reasonably expect them to be bug-free. I have come to loathe the case where your complex program outputs garbage because of some trivial bug deep inside the code.
• Lean, readable Code The code should have a high quality; no difficult execution pathways or hacks, good documentation and comments etc.

To accomodate this wishlist, it seems natural to require a couple of features from the code:

• Object-orientation. Every thing that you need in a program is an object, be it a grid, or an operator, or a wave function, or a propagator. These objects (or rather, their classes) have simple and sane public interfaces, and unless you try hard, you cannot and should not know what is inside, only how to use them.
• Wavepacket is a library. In contrast to the Matlab version, the C++ version only provides the various tools needed for the solution of the Schroedinger equation. Your task as user is to create the appropriate objects, and put them together in such a way that they solve your problem. This is done by writing a program that is linked against the library.
• Agile techniques. The basic idea of an agile development is to start writing a simple program (or here: toolset), and then handle more and more complex use-cases in the simplest possible way. This forces you to always keep the code extendable, and discourages complicated code.
• Test-driven development. A special agile technique, TDD requires you to write tests together with the code. It might not be immediately obvious, but to keep the tests reasonably simple to write, you are automatically forced to separate your code into clean modules (classes) that are easy to put together.

Course corrections

Over the course of developing the C++ version, some patterns emerged that changed the focus a little.

• Compiling a C++ library is inconvenient. There are a number of dependencies, in particular the underlying tensor library, that are not trivial to compile. Some particular solutions are a VM build image that provides a well-defined environment that is guaranteed to work and tested regularily. Also, for compiling the user-written programs, a particular solution using a convenience build script had to be employed.
• Windows is an important target. I cannot say anything definite because feedback is always rare with OSS software, but there is a discrepancy between the number of users downloading WavePacket using a Windows operating system (about 50 this year up to now, around 50% in general) and the number of users downloading the build image (15). Compiling anything under Windows is generally tricky for non-technical users, since there are no ready-to-install development packages for required libraries. Hence, I conclude that the C++ version looses a lot of potential users.
• Using a scripting language is an important target. With the build image and a little bit of documentation reading, even a not-too-technical user can be expected to get WavePacket running. However, the workflow is still cumbersome. You have to write a program, compile it, fix errors, compile again and so on. A much more pleasant workflow is to use a scripting language, and get the errors while you type your program, experiment with it and so on. Hence, a current focus is to get a full python interface working. In the short run, this only requires an interface to all C++ classes. However, in the long run, the consequences are more severe, since the way to write a python class is different from a C++ class; for example, you would encapsulate less for quick inspection, or use different idioms. We will see where this leads...