Input/Output of MPS states

The features for in- and output within OpenMPS can be distiguished into two parts. On the one hand we can save ground states which serve as initial state for real time evolutions. On the other we want to provide methods to continue interrupted time evolutions. A third aspect of minor importance is to exectue measurements on a existant state. The following chapters will cover these topics.

Statics - Saving ground states

In order to avoid unnecessary calculation of ground states, OpenMPS will automatically save every ground (and excited) state calculated with a specific identification. For the identification we use a hash of the relevant parameters of the static simulation containing parameters as:

  • Convergence parameters

  • Hamiltonian

  • Symmetry generators (for number conserving simulations)

  • System size, temporary and output folder (but not the unique_ID)

  • Observables

Simulations with the same hash (identification) can load the corresponding ground state for their dynamics simulation. Therefore it is checked if the corresponding file is already existant (Output_Directory). The ground (excited) state measurements are mapped via an additional file (Output_Directory + Job_ID + ‘_static_mapping.dat’) to all simulations (we do not measure twice). If you are reading the measurements of any simulation, python is redirecting to the equivalent measurement outputs.

An additional flag is given for MPI purposes. python determines if the ground state is calculated in any previous simulation and sets a flag if the simulation should wait for the corresponding ground state. This way the same file is not accessed from multiple cores.

We point out that only the states of the last convergence parameter are saved, because those will be loaded into time evolution.

Providing initial states for time evolution

There might be cases when you do not want to start in a ground or excited state of the Hamiltonian, but e.g. in a Fock state. A Fock state is a product state and can therefore be easily written as MPS. The following scheme can be followed to provide such a state to MPS.

  • In the python main file you can set the parameter dictionary flag MPS to False in order to do no static simulations.

  • The initial state is specified via the key timeevo_mps_initial and has to be written before the time evolution starts.

  • Do not provide any MPSConvergenceParameters or MPSObservables as both automatically set the MPS to True and are in conflict with the first point.

Those two steps take care of loading your specific MPS as initial state of the time evolution. But the state has still to be specified in a file. In order to write the file appropriate, please follow the documentation in the read/write subroutines within OpenMPS. In addition the module mps_state is provided for providing states. At present this can provide (non-number conserving) Fock states.

Interrupted Dynamics

Time evolution can take long time, especially when converging results. Therefore OpenMPS provides the tools to continue any simulation killed e.g. by a cluster. The following information might be useful to understand how this is done:

  • By default the time evolution stores after every measurement the MPS as binary file in the Write_Directory using the job_ID, the unique_ID and some additional string specifying the time of the simulation. The previous state is deleted after writing the new one. This default behavior cannot be configurated by the user right now.

  • After every measurement the file job_ID + unique_ID + ‘_time_last.dat’ in the folder Write_Directory is updated. As previously, this cannot be changed by the user right now.

Whenever your simulation will be killed, the following steps become important.

  • In your parameter dictionary (defined in the python-main file) you add the key dictionary['timeevo_restore'] = True. Time evolutions will then be restored when they were killed. The original simulation (which was killed) does not need to run with this flag.

  • Checking on the ‘*_time_last.dat’ file python figures out if the simulation had been started before. If so, it extracts the time of the last measurement. Corrupted measurement files (interrupted during the measurement) should be restored during this step (untested).

  • Time evolution to be restored will follow the read process in the internal fortran subroutines, but leave out measurements and the time evolution steps. (At the moment completely finished simulation will go as well through the reading of the parameters during the whole time evolution.)