Use Mollist2 as internal system information data structure

[liwt31]

This is an extension to the discussion in #82 , in which I proposed to use MolList2 as the internal data structure to keep track of system information and remove the original MPO construction function. At that time, major concerns arise on the performance in large systems. During my usage of the module for about 3 months, I found no performance problem, because MPO construction is always so small a portion of the total time cost. After all, the original code is designed for Holstein Hamiltonian which is almost the simplest Hamiltonian we can think of. When constructing these simple Hamiltonian, the general MPO construction routine is generally efficient. One thing that worries me is that I feel (no benchmark, just feeling) the algorithm is a little bit slow when constructing a lot of simple MPOs such as in the case of calc_reduced_density_matrix, this can certainly be improved but has a lower priority.
Of course, any discussions on this issue are still welcome.

This would a very big update. Contents include:

• Use MolList2 as internal system information data structure
• Remove chain representation of MPO Remove the chain representation? #90
• Remove explicit TD-DMRG/TDH algorithm The explicit TD-DMRG/TDH hybrid method will be removed in the future. #61 . In the original issue, the discussion is postponed. And in General Symbolic MPO Construction Routine #82 it is already proposed that people should move unimportant modes to the end of the MPS chain as an alternative. To fully incorporate the algorithm with the new Mollist2 backend, a moderate endeavor of coding is required, which may not be justified if the feature is going to be removed.
• Remove the quasi-boson feature which is seldomly used and costs lots of time in the test suite Compress the test suite #25 .
• Also, a possible update in the interface of MolList2 as discussed in Enhance green-kubo transport and refactor transport module #97 . The details will be updated in a comment to this issue.

[liwt31]

Update the interface of MolList2

Unification of the interfaces

The class MolList2 should be renamed to Model, as the default and most general way to define the model in the calculation. The construction method of the class __init__(self, ...) will take the role of MolList2 with ModelTranslator.general_model. Other interfaces will be retained as class methods of the Model class. The class should have the following class methods:

• holstein, acting as MolList.
• spin-boson, acting as MolList2 with ModelTranslator.sbm
• vibronic, acting as MolList2 with ModelTranslator.vibronic model

All of the class methods will transform the input information into the arguments that Model accept and pass them to the __init__ function.
This unification is performed in the current implementation but at a later stage (when constructing MPO). Advancing the unification will make handling the model easier, which will be more obvious considering the feature proposed later in this comment.

In my opinion, all of the three class methods should be deprecated since it is almost always more efficient and precise to construct the model with general_model, especially considering the improvement mentioned right below.

The new interface for the Model class.

As discussed in #97 , the interface for MolList2 with ModelTranslator.general_model is not well defined when BasisMultiElectron is used. For example:

model[("e_0", )] = [["a^\dagger_0 a_1", factor]]
model[("e_0", "e_1")] =[["a^\dagger_0", "a_1", factor]]
model[("e_0", "e_1")] =[["a^\dagger", "a", factor]]

will give the same model, although the representations are somewhat different the first one is a little obscure. Another drawback of the interface is the nested structure within the dict values, which in my experience is easily forgotten and leads to errors during development.

My proposal to unify and simplify the interface is to make setting the index inside the operator ("a^\dagger_0") compulsory and use a list instead of a dict to represent the model, and the order can be constructed from basis in which each every BasisSet knows the external dofs it represents. This is a simplification of the second example mentioned above. In this way, only two arguments are necessary to construct the Model class, the first one is a model list (SoP), and the second one is a basis list.

Dropping representations like e_0 and ph_1 also makes the approach more general, such as to spin problems. Currently, spins are taken to be e while strictly speaking it is not true. If the information on the nature of the DOF is necessary, it can be obtained from BasisSet.

Note that this approach will not work for vibronic_model and sbm, which is another reason for their deprecation.

With the input unified, it is much easier to perform checks on the user input model. The list items should be sorted; A warning should be issued if duplicate terms or non-hermitian are detected, The inner format can also convert strings like "a_0" to ("a", 0) tuples, etc.

Use a† instead of a^\dagger

Since its invention, Renormalizer uses "a^\dagger" to represent the conjugate of "a". While this certainly is a good choice, I recently come up with the idea that we could use "a†" internally instead of "a^\dagger" and an "r" prefix. The advantage is obvious, while it seems the disadvantage is that the character † may not be easy to type. However, † is actually not much more difficult to type than ^\dagger:

• For vim, in the insert mode, press Ctrl + v and then type u2020.
• For windows and mac there are multiple ways to achieve this such as by Alt + 0134 (numeric pad necessary) and lots of information is available online.
• In the worst case, the character can be copied from other parts of the code.

I'm using Alt + 0134 when typing this comment and I have to say it feels quite good.

For user input, the original interface using ^\dagger should be retained, and again it is converted to † internally.

[jjren]

1. I think a simple benchmark to compare the performance of MolList2 and MolList on calc_reduced_density_matrix is necessary. It definitely depends on M_s and physical bond dimension d.

2. In my experience, TD-DMRG/TDH has no advantage over pure TD-DMRG with M=2-5 for several modes in the end of the chain. (In J. Chem. Phys. 87, 5781 (1987), it is clearly demonstrated two configurations will give a much better result than one configuration(TDH) for a double-well PES (generally speaking, in cases when the electronic state could be very different in the problem).)
   With the current TD-DMRG implementation, I think that we only need to set self.max_dims: np.ndarray in CompressConfig and compress the initial Psi_0 before the tdvp evolution.
   As I said before, if hybrid classical dynamics is incorporated, it is easy to be implemented in the TD-DMRG/TDH framework. I don't know if you will go further in this direction or not @liwt31, since you have several lectures on this topic.

3. My concern to replace dagger with † is that is the symbol easy to type in some other environments like jupyter-notebook?
   Actually, I don't know how to type it in GitHub comment.
   How about memory usage with dagger and †? Maybe we can replace dagger to dag to save memory.

[jjren]

I agree with the other improvements.

[liwt31]

a simple benchmark to compare the performance of MolList2 and MolList on calc_reduced_density_matrix is necessary.

I don't quite understand. The calculation (pattern for tensor contraction) is essentially the same for either scheme < 4 or scheme = 4.

I don't know if you will go further in this direction or not @liwt31, since you have several lectures on this topic.

This update will not affect me much. I'm using time dependent Hamiltonian.

is the symbol easy to type in some other environments like jupyter-notebook?

Good point. Never mind. Using † is a crazy geek idea. I'll make it possible for external users to use † though, and internally it is converted to ^\dagger

[jjren]

a simple benchmark to compare the performance of MolList2 and MolList on calc_reduced_density_matrix is necessary.

I don't quite understand. The calculation (pattern for tensor contraction) is essentially the same for either scheme < 4 or scheme = 4.

I mean the time cost when constructing a lot of simple MPOs mentioned in your first post.