 |
SyTen
|
|
|
SyTen
|
|
With the kind help of the helpdesk of the ASC center in Munich (and in particular Robert Redl and Fabian Jakub) we were able to change the container distribution system to a more stable solution, which is available here. Please note that we are still in the beta phase for the distribution system.
As the container distribution system is still very much in the beta testing phase but should go towards being professionalised end of next year, we are happy to announce that we are going to introduce a new documentation in spring 2023. The focus is going to be on the pyten toolkit and the goal is to standarise the different parts of the documentation present right now. Please also note that handling the toolkit should be done with care to avoid wrong results or damage otherwise, if one is not familiar with the toolkit. Furthermore note that no guarantee is given. In doubt please contact us beforehand, we are always happy to help.
We finally managed to set up the first version of a distribution system for syten singularity containers. They are available for many different compiler settings but we can also extend this upon request. The current distribution system is very much under construction and might change at later points. However, for the moment they are available now. Note that this is still a beta phase. Relevant information can be found upon executing
$ singularity run ./syten.sif
Apart from that you can use the well known syten syntax
$ singularity exec ./syten.sif syten-info -h $ singularity exec ./syten.sif python3
As I handed in my thesis and am leaving the chair we decided to merge the developements of the past four years into the master branch. A lot of useful new features are now available as e.g. tree tensors, the projected purification framework, parallel TDVP and many convenience features. Furthermore, we now try to standartise a lot of stuff.
All the tests worked and therefore the toolkit should be stable and running correctly. However, any major change might cause unexpected behaviour and therefore we kindly ask you guys to keep Sebastian & me up to date if you should encounter any bugs. Also, there is a commit called 'pre-Sam-branch-merge' which marks the version before the merge in case you run into any trouble.
I hope you guys have fun with the toolkit ;).
Sincerely,
Sam
(P.S.: As the installation of syten got quite tedious we are currently working on a container solution which will be highly portable to (almost) any system and available for chair members and collaborateurs. We already have a running version but are still in the process of creating an automated solution for all the users.)
Due to a series of attacks on european hpc clusters, unfortunately I had to mark all existing public keys of SyTen users as deprecated. If you want to reobtain access to the repository please contact me. I appologize for the inconvenience but to maintain security of the repository this was a necessary action.
Maintenance of the toolkit was handed over to Sebastian Paeckel. I am certain that he will provide interesting new impulses for the further development of the toolkit and provide you all with the support necessary to study interesting physics.
I would also like to thank you for your trust in the toolkit and the motivating applications and ideas throughout the past few years.
So long,
Claudius
By setting the environment variable SYTEN_DENSE_TTS, you can enable the new dense temporary transpose storage system. This system stores – for the duration of one tensor product – the required transposes and conjugations of dense tensors, hence avoiding the repeated calculation of those as was necessary before.
A new version of the CUDA support code using streams was merged into the master branch. As a side effect, multiple GPUs are now supported, though using more than one GPU is about 10x slower than just using a single one due to inter-device data transfers.
There will be a technical introduction to the SyTen toolkit at LMU from 13 to 17 January at LMU. Intended for existing users of the toolkit, the aim is to explain every part of the code in sufficient detail to enable future independent work.
Please get in touch with Claudius Hubig to participate.
Especially in large calculations it is sometimes not straightforward to know where memory is going. A new syten::STensor registry, enabled via the environment variable SYTEN_STENSOR_REGISTRY, registers every syten::STensor object created and, on request, compiles a list of all such objects currently existing together with their respective memory usage etc.
Clang 9.0 is currently (as of tag clang-ok-20190927) able to compile the toolkit given that one disables a few warnings. Clang support is still on a best-effort basis, patches to enable compilation with Clang are always very welcome.
Initial support for GPUs is now available. See the build instructions and the help page.
The setup.sh script was unfortunately a bit inflexible and did not actually provide much value. For this reason, we have reverted to the earlier system where the make.inc file is written by hand. To make up for it, the Makefile itself was made much smarter and now automatically compiles and installs Boost and liblz4 if it does not find a suitable version installed. It also automatically generates the defines necessary for syten::STensor to work.
To migrate, copy the provided make.inc.example to make.inc and adapt it accordingly. If you already have Boost installed somewhere, make sure to say so in the make.inc file, some examples are given at the bottom.
Not compiling the Python bindings is no longer supported.
syten::STensor now logs all implicit copies in the tensor timing database. For further details, see the FAQ.
The functions cachePair and uncachePair have been removed and all instances of caching based on std::pair<Tensor<>, std::string> replaced by the newer alternatives syten::Cached and syten::AsyncCached.
The extensions for matrix-product state and lattice files were switched from .state and .lat to .mps and .mpl. To revert to the old behaviour, simply define SYTEN_EXT_MPS and SYTEN_EXT_MP_LATTICE in your make.inc file.
The iPEPS code has been rewritten from the ground up using the smart tensor class. This iPEPSv2 code has now been merged into the master branch, providing a much easier extendable framework for iPEPS methods. As a direct consequence, handling of fermions is now more correct and autodifferentiation is possible by default for all iPEPS quantities.
Up until now, caching was controlled locally, e.g. in matrix-product states (syten::MPS::State). This had the disadvantage of this control having to be communicated down throughout all layers of the code. The new global variable syten::Caching::do_cache now controls this: If it is set to false, calls to syten::Cached::cache() and syten::AsyncCached::cache() behave as if the object in question was below the caching threshold (i.e., do not cache). If it is set to true, everything continues as before. This variable is set to true automatically if --cache is passed on the command line and defaults to false otherwise.
Dense-level BLAS threading can now also be enabled by linking in libopenblas (via -lopenblas) and defining the macro SYTEN_USE_OPENBLAS. In this process, the macro used to signal using the MKL was renamed from USE_MKL to SYTEN_USE_MKL. This will need to be adapted in the make.inc file to continue using the MKL.
Using the option nes or num_exc_states with a two-site DMRG calculation, it is now possible to calculate multiple local states (in separate Lanczos runs) during each DMRG iteration. This was shown to reproduce at least some spectra with extremely high accuracy.
Out with the old runtime tag-based special dense tensor types, in with new variant-based special dense tensor types! An immediate effect of this change is the introduction of an OffsetDenseTensor type which is particularly useful for tensor leg merging operations which previously incurred a large overhead. With the new change, such operations easily see a 50% speed-up.
In addition, it will be easier in the future to extend the specialisation to other types of dense tensors (e.g. sparsity, GPU-based dense tensors or copy-on-write mechanisms).
Most user code will not need changes. If dense tensors of a constructed block block are manipulated, it will be necessary to (optionally) transform the dense tensor into standard format by calling block.m.make_standard() and subsequently obtaining a reference to the stored dense tensor using auto& bms = block.m.standard(). The reference then behaves like a previous standard dense tensor including all subscripting operations. For details, see syten::GenericDenseTensor.
The command line option to select the MPO-MPS application method was changed in syten-tebd-swappable and syten-apply-op. It is now --apply-function and -f in both cases. Furthermore, a new application method which first uses the zip-up and then some sweeps with variational application was added.
A new mode DMRG3S-RND has been added to MPS-DMRG. In addition to the standard subspace expansion, it also expands the bond basis by the maximal obtainable basis on the expanded site and also adds a small random term to the initial Krylov vector before the local eigensolver search. The result is improved convergence even if the global ground state is not contained in the Krylov space of the supplied Hamiltonian and state.
The IPEPS branch is merged into the master branch. This branch includes basic IPEPS utilities to e.g. generate states, evaluate observables and run ground-state searches using simple and full updates. For details, see arXiv:1808.10804.
The new STensor class is merged into the master branch. The class hides the tensor rank, which allows for much faster compilation of end-user binaries. More importantly, it incorporates named bases (similar to ITensor), meaning that tensor-tensor products can be written simply as a * b with all matching bases contracted. Furthermore, it attempts to incorporate the graded \mathbb{Z}_2
algebra (cf. Bultinck et al, PRB 95, 075108 and Barthel et al, PRA 80, 042333) for transparent and straightforward handling of fermionic networks. The class is still very much work in progress. To use, you need to define the SYTEN_STENSOR macro.
The new 2svar mode of MPS-DMRG calculates the 2-site variance of the current state during a DMRG sweep. This way, the overhead of re-reading the state and also re-constructing the left and right contractions with the Hamiltonian is removed. To use, insert a stage (v 2svar ) into the DMRG stage list (and, if the calculation continues afterwards, reset the mode again to DMRG3S using v DMRG3S in the next stage). The result of the evaluation will be printed to the worker's trace log.
1.9.4