I would like to use the TDVP method to evolve the MPO for purification-based finite-temperature simulations. Unfortunately, I found that TDVP does not support MPO evolution. Therefore, I plan to convert the initial MPO to MPS and then merge the physical indices. Additionally, I need to take the Kronecker product of the Hamiltonian with the identity to get a super MPO. However, I am not familiar with the ITensors package and could not find functions that can perform the cross product of MPOs and then merging of physical indices.
Could you please provide guidance or suggest alternative methods to achieve this?
Your plan sounds like a good one. As an alternative to merging the indices, you could also make an MPS where every odd index is an original “ket” index and every even index is a “bra” index. This is like “folding” the legs of the MPO to the other side so that an MPO acting on N indices becomes an MPS with 2N indices (“purification”). To make it an MPS, you can split or SVD the tensors with two physical indices into two tensors with just one physical index each.
About the product of the Hamiltonian with the identity, this is not something you really need to do as a product operation on the level of the entire Hamiltonian. All it really means is that the Hamiltonian acts trivially (as the identity) on certain sites. So really it means you need to just make your Hamiltonian act on every other site and just “skip” the other type of sites. E.g. if you are using our OpSum system to make your Hamiltonian, in the above MPS picture you would make it just act only on even-numbered sites or odd-numbered sites only.
Ideally we would allow passing MPOs directly to all of the solvers (like dmrg and tdvp) directly, however to do it properly it would require a pretty big rewrite of the internals of the MPS/MPO code, such as a refactor of the ProjMPO type, and right now we are focusing more on the development of ITensorNetworks.jl. That package is being written more generally from the get-go, for example by design it is more agnostic about whether objects are tensor network states or operators, so it will be easier and more time efficient for us to focus on supporting it their. But rest assured it is on our radar to make this easier to do since we know it is an important use case and should be easier to do with ITensor.
For now you will have to do some pre- and post-processing of the networks “by hand” as Miles suggested, which I think isn’t too bad as a temporary solution.