# The optimal way to implement a customized updater/solver?
**URL:** https://itensor.discourse.group/t/the-optimal-way-to-implement-a-customized-updater-solver/1935
**Category:** ITensor Julia Questions
**Created:** [August 19, 2024, 9:00pm UTC](https://itensor.discourse.group/t/the-optimal-way-to-implement-a-customized-updater-solver/1935 "2024-08-19T21:00:16Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Shengtao](https://itensor.discourse.group/u/Shengtao)
#### Post date: [August 19, 2024, 9:00pm UTC](https://itensor.discourse.group/t/the-optimal-way-to-implement-a-customized-updater-solver/1935/1 "2024-08-19T21:00:17Z")
Hello,
I am looking for a way to implement a custom updater/solver that replaces the `eigensolve` in `dmrg`.
I saw Miles suggested in [Correction vector](https://itensor.discourse.group/t/correction-vector/107) that there may now be a function where one can switch the solver. The closest I can find is `dmrg_x` in `ITensorTDVP`: [ITensorTDVP.jl/src/dmrg\_x.jl at main · ITensor/ITensorTDVP.jl · GitHub](https://github.com/ITensor/ITensorTDVP.jl/blob/main/src/dmrg_x.jl), where I think one can modify the ` eigen_updater`. Is this the best way to implement a customized updater?
A minor question: what is the difference between `dmrg_x` and `dmrg` in [ITensorTDVP.jl/src at main · ITensor/ITensorTDVP.jl · GitHub](https://github.com/ITensor/ITensorTDVP.jl/tree/main/src)? Do they just have different default updaters?
Best,
Shengtao
---
### Author:  [@miles](https://itensor.discourse.group/u/miles)
#### Post date: [August 31, 2024, 9:36pm UTC](https://itensor.discourse.group/t/the-optimal-way-to-implement-a-customized-updater-solver/1935/2 "2024-08-31T21:36:02Z")
Hi Shengtao,
To your last question, yes the `dmrg_x` and `dmrg` functions defined in the ITensorTDVP package differ just in terms of which `updater` they are using, and also a little bit in terms of their “setup” part of their code which you can see at the bottom of each of those files.
Please note that the `dmrg` code there is totally different from the `dmrg` function defined in the ITensorMPS package (which is the standard DMRG code that one gets when doing `using ITensors, ITensorMPS`). The codes in ITensorTDVP share a backend called `alternating_update` which was a prototype for a new design that turned into the more general codes being developed in the `ITensorNetworks` package right now. So other than for calling the `tdvp` function, you can think of the other code in ITensorTDVP such as `dmrg_x` as experimental in nature.
Finally about implementing an updater, I’m not totally sure what you mean by “what is the optimal way”. The job of the `updater` in those codes is to take the local tensor (in DMRG this is the contraction of two site tensors of the MPS) and then to use that tensor and the operator together to make a new two-site tensor that is “updated” in some way specific to the algorithm. For the `dmrg` algorithm the updater calls the `KrylovKit.eigsolve` function which peforms a few steps of iterative eigenvector finding using a Krylov algorithm like Lanczos. For `tdvp` the updater uses a different Krylov algorithm that time evolves the tensor by some amount. So for the case you are seeking, the updater should just do whatever change to the local wavefunction tensor your algorithm requires. The optimality comes down to making sure that the updating is done in an efficient way, but since the updater can be totally general otherwise that part is really up to you.
Hope that helps!
Miles
---
### Author:  [@Shengtao](https://itensor.discourse.group/u/Shengtao)
#### Post date: [August 31, 2024, 11:48pm UTC](https://itensor.discourse.group/t/the-optimal-way-to-implement-a-customized-updater-solver/1935/3 "2024-08-31T23:48:15Z")
Hi Miles,
Thanks a lot for the detailed explanation! Now I understand that `dmrg_x` should be the function to call for implementing a customized updater, since I was not totally sure if there exists a better function to use in the ITensor package family, considering that the ITensorTDVP.jl (where `dmrg_x` currently is) will be deprecated in favor of the ITensorMPS.jl.
The `alternating_update` sounds very interesting and I will take a look at how it works.
Best,
Shengtao
---
### Author:  [@miles](https://itensor.discourse.group/u/miles)
#### Post date: [September 2, 2024, 7:51pm UTC](https://itensor.discourse.group/t/the-optimal-way-to-implement-a-customized-updater-solver/1935/4 "2024-09-02T19:51:33Z")
Hi Shengtao,
A few things:
- it’s not really that `dmrg_x` should be called to implement a custom updater. It’s more that `dmrg_x` is an example of a function that is implemented through a custom updater. The way it is implemented is by passing this updater to the `alternating_update` function which is the real “generic engine” underlying `dmrg_x` and the experimental new version of `dmrg` (and `tdvp` and `linsolve` – all of those codes are just different ways of calling `alternating_update`).
- we aren’t necesssarily planning to deprecate ITensorTDVP in favor of ITensorMPS. If anything it may be the other way around though the exact plans are still to be determined. Mainly we will ask people to start migrating over to ITensorNetworks for those algorithms eventually.
- yes, please do take a look at `alternating_update` which should clarify my first point above. It is a generic algorithm that sweeps over an MPS and on each pair of sites merges two MPS tensors together, puts them into an updater, then factorizes them back to restore the MPS form. A lot of algorithms can be written in terms of that basic pattern.
Best,
Miles
---
### Author:  [@mtfishman](https://itensor.discourse.group/u/mtfishman)
#### Post date: [September 2, 2024, 7:57pm UTC](https://itensor.discourse.group/t/the-optimal-way-to-implement-a-customized-updater-solver/1935/5 "2024-09-02T19:57:13Z")
@miles my current plan (which I thought we had discussed) is to deprecate ITensorTDVP.jl in favor of ITensorMPS.jl, see the deprecation warning at the top of the README of [GitHub - ITensor/ITensorTDVP.jl: Time dependent variational principle (TDVP) of MPS based on ITensors.jl.](https://github.com/ITensor/ITensorTDVP.jl). The plan is to move all of the MPS code from ITensors.jl, as well as all of the code from ITensorTDVP.jl, into ITensorMPS.jl.
---
### Author:  [@miles](https://itensor.discourse.group/u/miles)
#### Post date: [September 2, 2024, 8:31pm UTC](https://itensor.discourse.group/t/the-optimal-way-to-implement-a-customized-updater-solver/1935/6 "2024-09-02T20:31:31Z")
Thanks for clarifying, Matt, and sorry for the confusion.
---
### Author:  [@system](https://itensor.discourse.group/u/system)
#### Post date: [September 12, 2024, 8:32pm UTC](https://itensor.discourse.group/t/the-optimal-way-to-implement-a-customized-updater-solver/1935/7 "2024-09-12T20:32:18Z")
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.