TensorNetwork's dead! What next?

[gefux]

It is now a year since the last commit on TensorNetwork, which is unfortunate because it has been (in my opinion) a great project!
Because OQuPy is currently built on TensorNetwork, this constitutes a bit of an issue.
In short and mid-term we could publish our own version of TensorNetwork, such as tensornetwork_for_oqupy to accommodate the most pressing bugfixes (such as: #65 -> this PR ).
In the long run, it means however that we need to switch to some other package. Any suggestions?

[rajeev2010]

Itensor Julia is perhaps the most widely used tensor network library in a high level language. Is there any particular reason to choose python over julia for this project?

[gefux]

Given this, would you (@rajeev2010) think that it could make sense to use Julia+Itensor as a backend in this Python project employing something like https://www.juliabloggers.com/how-to-call-julia-code-from-python/?

[rajeev2010]

Thank you for your comment @rajeev2010! I've heard a lot of good things about both Julia and Itensor, and I had considered this too before. There are, however, multiple answers to why we currently choose Python over Julia for this project:

1. This project grew in the last 4 years out of some Python code that was part of a Nature Communications paper New J. Phys. 19(9), p.093009. (So there is an "historic" aspect).
2. Most of my colleagues that have developed this project and I don't know or are inexperienced on how to code Julia.
3. One of the immediate use of this package for the research groups that participated in the development of this project so far is that summer students and master students can use it for interesting projects, without having to digging too deep into the method itself. The students are usually familiar with Python because it is often taught as an introductory programming language.
4. A good argument for Julia vs. Python is of course performance. However, optimising the computational performance of the available algorithm is not a priority of this project. The priority of this project is to give an easy access to a variety of methods for small and medium sized computations. The strength lies in the methods themselves, which may give a speed-up of possibly several orders of magnitudes compared to alternative methods [see the publications].

Thanks Gerald for acquainting me with the history of this library.

[rajeev2010]

Given this, would you (@rajeev2010) think that it could make sense to use Julia+Itensor as a backend in this Python project employing something like https://www.juliabloggers.com/how-to-call-julia-code-from-python/?

I actually had a pure julia approach in mind as long term maintainability would be easier from developer's side. A mixed language approach may require more expertise from the developers. This of course is contrary to the wide familiarity of python and may be some burden on more experienced researchers. Younger people should be able to pick up julia fairly easily.

[rajeev2010]

My recommendation of julia is not because of performance but due to the itensor library. As you may already be aware, the C++ version of this library has been actively developed and maintained for over a decade now. The julia version should also be about 5 years old now and is fairly active.

[rajeev2010]

Perhaps you are also familiar with
https://github.com/qiskit-community/lindbladmpo
where the developers are going with the C++ version of itensor.

[rajeev2010]

We may request the senior colleagues to compare quantumoptics.jl and qutip codes to see the similarity and differences between python and Julia in this context.

If finally most people decide against Julia, we may consider the library quimb.

[gefux]

Thank you for that suggestion! I guess quimb would be an option.