Programming‎ > ‎MPS Bundle‎ > ‎

MPS Bundle disclaimer

The libraries f2c, tensor, cblapack, mps and mps-bundle, as well as any other components that this library may download and build in your system are distributed under the following conditions:
  1. The software is free for use and reuse under the appropriate licenses described in each of the components.
  2. The library is distributed without any implicit or explicit support from the developer, who may discontinue its maintenance at any time.
  3. The use of the library does not imply any warranty, including suitability for a particular purpose or simulation.
  4. The library provides its own tests and checks, to provide a modest kind of assurance on the suitability of a given platform, but imply no infallibility of any kind and the user should build her/his own tests of assurance to make sure that the final code using the library performs as expected.
This disclaimer sounds rather disappointing, with the intention to scare you, potential user, away. That should not be the main conclusion. Instead you should understand that any sophisticated piece of software is prone to subtle bugs, that may arise from faulty third party components (1), subtle dependencies on the platforms (2), or even misunderstanding of the underlying algorithms or their implications (3). Let me show you this with some examples:
  1. Last month before writing these notes I noticed that 30% of our simulations would crash. This happened on one cluster, but the "bug" propagated to other clusters as well. A rather painful debugging of the code showed that the reason for the crash was due to a bug in the Intel MKL library, which in versions 11.1.* has a faulty singular value decomposition routine, that crashes or produces infinities when running in multithreaded mode. This bug was only revealed when *all* clusters upgraded to a recent, but no recent enough, version of the Intel C++ compiler.
  2. IBM's PowerPC architecture has a different endiannes than Intel's own processors. Endiannes is the order in which bytes of a large word (for instance a double precission floating point number) are stored in memory. After running several weeks of simulations in one big IBM supercomputer, I realized that I was not able to recover the data from the simulations. For weeks I assumed that the library was broken, but then realized that data was written to files in different order than in an Intel computer and thus our Matlab scripts were not able to read the data. This has been corrected.
  3. Matrix product states have a gauge flexibility. This means that many collections of tensors stored in a given MPS can represent the same cluster state. A subset of those collections are called to be in "canonical" form. Ideally, computations with an MPS do not depend on the form of the state, because after all the contraction of the tensors gives the same number. In practice, however, I have seen that long MPS's, with hundreds of subsystems, behave better when in canonical form, because the contractions are more stable: they are less prone to produce huge floating point numbers somewhere in the middle of the contraction. However, ensuring that a state is in canonical form also implies a costly operation, with its own rounding errors. The conclusion is that while we know formally the algorithm that we want to use, in practice there may be very subtle variants, depending on we massage the states and their operations, and they may be more or less accurate in different contexts.
It is for all these reasons that numerical software has to be used "with a grain of salt", understanding what goes on and what you do, and verifying results by having alternate methods or some consistency checks that run in parallel with your simulations. Nothing in this life is perfect, and when built by the hand of a single man it is even less so, but even other software such as Matlab or Mathematica have and had serious bugs that hit us, scientists at one point or another and when you are in control of the code, things should at least be safer.