ITensor Support Q&A - Recent questions and answers
http://itensor.org/support/qa
Powered by Question2AnswerAutoMPO with products of three/four terms operators
http://itensor.org/support/1944/autompo-with-products-of-three-four-terms-operators
<p>Hi all,</p>
<p>I am trying to implement the AKLT Hamiltonian for the Spin-2 case. <br>
Having computed with Mathematica the power (S<em>i * S</em>j)^3 and (S<em>i * S</em>j)^4 (that are contained in the Hamiltonian) as a function of the operators S+ and S-, I have terms of the form </p>
<pre><code>ampo += 1.0, "Sz*S+*S+",indices_prime[i],"Sz*S-*S-",indices_prime[i+1];
</code></pre>
<p>and </p>
<pre><code>ampo += 1.0, "S+*S-*Sz*Sz",indices_prime[i],"S-*S+*Sz*Sz",indices_prime[i+1];
</code></pre>
<p>with products of three or four operators on each site. I compile the code, but when I try to run it, I obtain the following error:</p>
<p>"Operator S- name not recognized". </p>
<p>Actually, the code seems to recognise the operator "S-", because, if I put only two operators for each site (for instance, "S+S-" and "S-S+"), it works. I think the error it is due to the fact that I am using more than two operators in the product on each site. </p>
<p>Any advice? </p>
<p>Thank you very much. </p>
http://itensor.org/support/1944/autompo-with-products-of-three-four-terms-operatorsWed, 12 Feb 2020 17:47:50 +0000Answered: Singular values are not sorted with conserved parity?
http://itensor.org/support/1932/singular-values-are-not-sorted-with-conserved-parity?show=1938#a1938
<p>Hi Jin,<br>
Ok now I've figured it out. This will be the official answer (I had missed a detail about the code in my other answer).</p>
<p>The answer is that, no, the diagonal entries in the S tensor are in general not sorted. They are sorted within each block, but not across blocks. This is chosen so that U and V can retain a block-sparse structure when conserving quantum numbers.</p>
<p>So one way to get a sorted list of all of the singular values is to loop over them all first, put them into a std::vector, then call std::sort on that vector.</p>
<p>Another way is to call the older interface for the SVD that takes U,S, and V as (reference) arguments:<br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?vers=cppv3&page=classes/decomp">http://itensor.org/docs.cgi?vers=cppv3&page=classes/decomp</a><br>
This older interface returns a Spectrum object which can be used to access a sorted list of all of the density matrix eigenvalues (squares of singular values).</p>
<p>Best regards,<br>
Miles</p>
<p>P.S. just for extra info, the behavior of the code in the presence of quantum numbers is not specifically programmed for each kind of quantum number, such as parity or otherwise. It is written in a very generic way, so would likely either work for parity and all other types of quantum numbers or fail for parity as well as all other quantum numbers.</p>
http://itensor.org/support/1932/singular-values-are-not-sorted-with-conserved-parity?show=1938#a1938Tue, 04 Feb 2020 02:00:19 +0000Issues using applyExpH
http://itensor.org/support/1925/issues-using-applyexph
<p>Hi,<br>
I am trying to calculate the MPS resulting from exp(-tau H)|psi> where where H has up to three site interaction terms, and the exponential is the usual Boltzmann operator in this case.<br>
I can't use expH because of the three term interactions so I moved to applyExpH, but I keep on having an allocation error which I cannot trace back.</p>
<p>Here is a snippet of my code</p>
<pre><code>auto args = Args("Cutoff=",1E-8,"MaxDim=",20,"Order=",2);
for (int i = 1; i<= Nstep; i++)
{
std::cout << "Step " << i << std::endl;
applyExpH(psi1,H,dt,res,args);
psi1 = res;
println("Norm: ",norm(res));
}
writeToFile(pfile,psi1);
</code></pre>
<p>The error I get is the following:<br>
terminate called after throwing an instance of 'std::bad<em>alloc'<br>
what(): std::bad</em>alloc<br>
Removing the three site interactions the error disappear so it must be related to the Hamiltonian structure. Is this a normal behaviour?</p>
<p>Regards,<br>
Raffaele</p>
http://itensor.org/support/1925/issues-using-applyexphFri, 31 Jan 2020 16:11:36 +0000Answered: Valence bond states - fast implementation
http://itensor.org/support/1920/valence-bond-states-fast-implementation?show=1921#a1921
<p>Hi, so if I understand correctly, you want to create a state which is like the one in the linked formula (|u1 d2> - |d1 u2>) (x) (|u3 d4> - |d3 u4>) (x) (|u5 d6> - |d5 u6>) ... </p>
<p>So a good way to do this is to create a two-site wavefunction (tensor with two indices) and set its elements explicitly so it is the singlet state on these two sites. It will have two non-zero elements. </p>
<p>Then SVD this tensor (really a matrix) to obtain a two-site MPS. </p>
<p>Next, create a longer MPS on N sites. You can then copy this two-site MPS you made above into the MPS over and over again in a loop, copying the tensors into the sites spanning each odd-numbered bond (sites 1 & 2, 3 & 4, 5 & 6, etc.).</p>
<p>Finally, update all of the physical indices of the MPS so that they are distinct, rather than repeating with a 2-site periodicity. You can do this by using a delta tensor:</p>
<p>psi.ref(n) *= delta(s,sites(n)); </p>
<p>where s is one of the indices of your original 2-site tensor and sites(n) is the n'th index obtained from a site set on N sites. (To see how to make a site set see some of the example codes included with ITensor.)</p>
<p>Alternatively you can do the two-site-dimer and SVD procedure from scratch each time on each bond, remaking it again in a loop. </p>
<p>For an actual example code that does this, you can see the following code:<br>
<a rel="nofollow" href="https://github.com/emstoudenmire/finiteTMPS/blob/master/mpo_ancilla.cc">https://github.com/emstoudenmire/finiteTMPS/blob/master/mpo_ancilla.cc</a><br>
around line 96.<br>
<em>Please note</em> this code is using ITensor version 2 notation, and we would recommend using the ITensor version 3 interface. Mainly this means you change "Aref" to just "ref".</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1920/valence-bond-states-fast-implementation?show=1921#a1921Wed, 29 Jan 2020 20:42:30 +0000Answered: Help with Trotter gates and ancilla purification - SwapGate
http://itensor.org/support/1916/help-with-trotter-gates-and-ancilla-purification-swapgate?show=1918#a1918
<p>Hi Nick,<br>
Thanks for the question. So I think the issue is with the site arguments you passed to BondGate. The idea there is that these should actually be 1,2, not 1,3. The reason is that after you swap site 3 over to site 2, now acting on sites 1 and 2 is effectively like acting on sites 1 and 3 of the original wavefunction. Then swapping 2 and 3 again would complete that process (though sometimes there are more efficient swapping patterns when acting on multiple bonds in a row).</p>
<p>I should consider just making it an error to input a pair of site numbers which are more that 1 apart, actually. The BondGate system is a bit of an older part of ITensor and could be a little better designed in hindsight. But it does work quite well and is very efficient (state of the art) when used for these kinds of calculations.</p>
<p>Please feel free to post additional questions below or of course let me know if that fix doesn't work -</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1916/help-with-trotter-gates-and-ancilla-purification-swapgate?show=1918#a1918Wed, 29 Jan 2020 03:33:53 +0000Answered: Conservation of quantum numbers in Hubbard sites
http://itensor.org/support/1913/conservation-of-quantum-numbers-in-hubbard-sites?show=1917#a1917
<p>Please see the comments above for the answer.</p>
http://itensor.org/support/1913/conservation-of-quantum-numbers-in-hubbard-sites?show=1917#a1917Mon, 27 Jan 2020 14:04:15 +0000Answered: Error in excited states code
http://itensor.org/support/1911/error-in-excited-states-code?show=1912#a1912
<p>Hi Rafael,<br>
This is a compilation issue, as you probably know, so it could be due to a few things. To begin with:<br>
1. are you using the very latest version of ITensor?<br>
2. what Makefile are you using to compile? Or what compilation flags / instructions? </p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1911/error-in-excited-states-code?show=1912#a1912Tue, 21 Jan 2020 17:44:16 +0000Answered: Entanglement entropy of a finite block of a spin chain
http://itensor.org/support/1907/entanglement-entropy-of-a-finite-block-of-a-spin-chain?show=1908#a1908
<p>Hi Yantao,<br>
This is certainly possible to do in a way that scales exponentially with the number of sites in the region "A" whose entanglement you want to compute. </p>
<p>You can see this previous question as one discussion with some example code for the case of a two site region "A":<br>
<a rel="nofollow" href="http://itensor.org/support/229/evaluate-block-entanglement-blocks-that-extend-the-lattice?show=229#q229">http://itensor.org/support/229/evaluate-block-entanglement-blocks-that-extend-the-lattice?show=229#q229</a></p>
<p>The basic idea is just to explicitly trace rho = psi^2 on all of the sites of region B, which is a trivial operation if the gauge center site is located inside of region A. Then if region A has Na sites, you will get its reduced density matrix as a tensor with 2*Na indices. You can diagonalize this tensor using the diagHermitian function.</p>
<p>There may be a better scaling algorithm in principle, but there is not one which has been published as far as I know. (E.g. one ambitious algorithm would be to try to find the eigenvalues of rho one-by-one using an iterative eigensolver such as Lanczos, where one would multiply an MPS onto rho and construct rho tensor-by-tensor each time to keep the scaling polynomial. But one might need to compute a lot of eigenvalues to get a good estimate of the entropy.)</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1907/entanglement-entropy-of-a-finite-block-of-a-spin-chain?show=1908#a1908Mon, 20 Jan 2020 17:57:05 +0000Initial state with specific momentum
http://itensor.org/support/1901/initial-state-with-specific-momentum
<p>Hi,</p>
<p>I was wondering if it is possible to prepare as initial state for the real time evolution a state with one (or more) free particles (let's say fermions) with specific momenta (k1, k2, etc). For instance, I would like to study the evolution of a state with two particles initially at large distance with opposite momenta. </p>
<p>Thanks a lot,<br>
Giuseppe </p>
http://itensor.org/support/1901/initial-state-with-specific-momentumTue, 14 Jan 2020 09:54:14 +0000Answered: A question about time evolution in tutorial/finiteT/metts.cc
http://itensor.org/support/1897/question-about-time-evolution-in-tutorial-finitet-metts-cc?show=1898#a1898
<p>Hi Zong-Sheng,<br>
Thanks for the question. Yes, that line of code is just normalizing the MPS to have norm equal to 1. The reason it only accesses the first MPS tensor (.ref(1)) is that the applyMPO function guarantees that the returned MPS will be in right-canonical gauge, so that the norm of the whole MPS equals the norm of the first MPS tensor.</p>
<p>The expression of the paper is the norm that the (unnormalized) METTS would have if one did the imaginary time evolution all in one big step. However, here the expH MPO is just for a step of tau, and so the norm afterward will be different (the same expression but with tau instead of beta). Dividing it off at every step or dividing it off at the very end will give the same final normalized state. </p>
<p>Hope that helps,<br>
Miles</p>
http://itensor.org/support/1897/question-about-time-evolution-in-tutorial-finitet-metts-cc?show=1898#a1898Sun, 05 Jan 2020 01:38:59 +0000Answered: Next nearest neighbor interaction in 2D DMRG
http://itensor.org/support/1894/next-nearest-neighbor-interaction-in-2d-dmrg?show=1895#a1895
<p>Hi Ajit,<br>
You are in luck. We do have a function already for making the square lattice with next-neighbor bonds but it just wasn't well documented. Following your question, I just added it to the documentation here:<br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?vers=cppv3&page=classes/lattice_functions">http://itensor.org/docs.cgi?vers=cppv3&page=classes/lattice_functions</a></p>
<p>We don't have a function for next-neighbor on the triangular lattice however. The codes for all of these lattice functions is meant to be straightforward with the hope that users would contribute additional ones we are missing. If you would consider contributing the triangular next-neighbor case that would be great if you have time.</p>
<p>The codes for these functions can be found in the files:<br>
itensor/mps/lattice/square.h<br>
itensor/mps/lattice/triangular.h</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1894/next-nearest-neighbor-interaction-in-2d-dmrg?show=1895#a1895Thu, 26 Dec 2019 23:37:24 +0000Answered: Zero entanglement entropy for Kitaev Chain at Delta=-1
http://itensor.org/support/1874/zero-entanglement-entropy-for-kitaev-chain-at-delta-1?show=1883#a1883
<p>Just a note also about the physics of the Kitaev chain: the ground states of the fermionic model versus the spin model are different (independent of DMRG or how you compute them). This is because for fermion systems, ground states should have a well-defined fermion parity. For this parity to be well-defined, the ground states have to be macroscopic superpositions of the ground states of the spin model. The spin model is just a simple ferromagnet, so has two product-state ground states.</p>
<p>So the behavior you are seeing is actually correct.</p>
http://itensor.org/support/1874/zero-entanglement-entropy-for-kitaev-chain-at-delta-1?show=1883#a1883Wed, 18 Dec 2019 15:52:58 +0000Answered: ITensor 3 gives wrong results for fermions without particle number conservation
http://itensor.org/support/1858/itensor-results-fermions-without-particle-number-conservation?show=1868#a1868
<p>Hi Jin,</p>
<p>Thanks for pointing out this issue. Indeed, it seems like AutoMPO in ITensor v3 is creating the wrong MPO when QNs are not conserved in this case. For example, here are the Hamiltonians made by AutoMPO for N = 2 (the MPO tensors are contracted together to get the full Hamiltonian):</p>
<p>ITensor v3, no QNs conserved:</p>
<p>H(1)*H(2) = <br>
ITensor ord=4: (2|id=794|n=1,Site,Fermion)' (2|id=794|n=1,Site,Fermion) (2|id=230|n=2,Site,Fermion) (2|id=230|n=2,Site,Fermion)' <br>
{norm=1.41 (Dense Real)}<br>
(2,1,2,1) -1.000000<br>
(1,2,1,2) 1.0000000</p>
<p>ITensor v2, no QNs conserved:</p>
<p>H.A(1)*H.A(2) = <br>
ITensor r=4: ("Spinless 1",2,Site|573)' ("Spinless 1",2,Site|573) ("Spinless 2",2,Site|989) ("Spinless 2",2,Site|989)'<br>
{norm=1.41 (Dense Real)}<br>
(2,1,2,1) -1.000000<br>
(1,2,1,2) -1.000000</p>
<p>When QNs are conserved, they both give the same correct Hamiltonian. It looks like in v3 when QNs are not conserved, the Fermion sign is not being put in correctly when the "Cdag" and "C" operators are being used, we will look into this.</p>
<p>Cheers,<br>
Matt</p>
http://itensor.org/support/1858/itensor-results-fermions-without-particle-number-conservation?show=1868#a1868Mon, 16 Dec 2019 19:45:36 +0000Answered: Improving applyExp()
http://itensor.org/support/1855/improving-applyexp?show=1856#a1856
<p>Hi Raffaele,</p>
<p>Thanks for reporting an issue. Could you elaborate more on your application? What matrix are you trying to exponentiate and what are you ultimately trying to calculate?</p>
<p>Right now, <code>applyExp</code> uses a pretty standard Krylov-based method for calculating the exponential of an operator applied to a vector (i.e. it builds the Krylov basis and then the Krylov matrix is exponentiated, you can see the implementation here: <a rel="nofollow" href="https://github.com/ITensor/ITensor/blob/7abb7b2760d0608713f846f6bc85f6b6b8c7e509/itensor/iterativesolvers.h#L970).">https://github.com/ITensor/ITensor/blob/7abb7b2760d0608713f846f6bc85f6b6b8c7e509/itensor/iterativesolvers.h#L970).</a> </p>
<p>The current implementation does not have restarts, so it may be limited in the timestep you can input (i.e. if you are calculating <code>exp(-t*H)*v</code>, for large <code>t</code> it may have convergence issues). We would be happy to add in restarts if there is a compelling use case, but we were waiting for a concrete example where that is necessary. For example, in the main use case for us (TDVP), the time step can be taken smaller by doing more sweeps of the MPS, and we have found that the current implementation is sufficient. </p>
<p>Also right now, consider that you can split up your timestep and do multiple calls of <code>applyExp</code>, for example you can try:</p>
<pre><code>auto expHv = applyExp(H,v,-t/2);
expHv = applyExp(H,expHv,-t/2);
</code></pre>
<p>instead of:</p>
<pre><code>auto expHv = applyExp(H,v,-t);
</code></pre>
<p>if your timestep <code>t</code> is too large for convergence. For a fixed <code>ErrGoal</code> you of course accumulate the error of both calls of <code>applyExp</code>.</p>
<p>Cheers,<br>
Matt</p>
http://itensor.org/support/1855/improving-applyexp?show=1856#a1856Fri, 13 Dec 2019 20:12:50 +0000ITensor3 is slower than same code on ITensor2
http://itensor.org/support/1849/itensor3-is-slower-than-same-code-on-itensor2
<p>Hello,</p>
<p>I recently switched from ITensor 2 to version 3 and I noticed that the same code runs noticeably slower on the newer version.<br>
A calculation that was taking ~7 hours in ITensor 2 now takes almost twice as much time.<br>
I am not sure whether it is ITensor that is responsible to this or something in the cluster configuration where I am running the code, but I would appreciate any help or ideas about what might be causing this.</p>
<p>In particular, on the cluster I am using, I only have access to certain gcc compilers, and in order to use c++17 I had to switch from gcc 4.9.3 to gcc9.1.0 (the only one that supports c++17).<br>
In both cases, I am using LAPACK 3.6.1.</p>
<p>Thanks,</p>
http://itensor.org/support/1849/itensor3-is-slower-than-same-code-on-itensor2Wed, 11 Dec 2019 22:03:53 +0000Answered: Different results for equivalent representations of S_x
http://itensor.org/support/1844/different-results-for-equivalent-representations-of-s_x?show=1847#a1847
<p>Hi Matthias,</p>
<p>Since Sx = 1/2(S+ + S-), I think to get the same Hamiltonian you would need to use:</p>
<pre><code>ampo += -2, "Sx", i, "Sx", i+1;
</code></pre>
<p>(since Sx<em>i Sx</em>i+1 = 1/2 (S+<em>i + S-</em>i+1) 1/2 (S+<em>i + S-</em>i+1) = 1/4 (S+ S+ + S- S- + S+ S- + S- S+)).</p>
<p>though I haven't tested it. Could you try it out?</p>
<p>Cheers,<br>
Matt</p>
http://itensor.org/support/1844/different-results-for-equivalent-representations-of-s_x?show=1847#a1847Mon, 09 Dec 2019 21:31:59 +0000Answered: How to deal with varying final results for different initial states of the system, while doing DMRG calculations?
http://itensor.org/support/1842/varying-results-different-initial-states-system-calculations?show=1843#a1843
<p>Thanks for the question. Yes, trying multiple initial states, especially when you suspect a convergence issue, is an important technique in DMRG.</p>
<p>There are some other techniques and considerations you can use also:</p>
<ol>
<li><p>try setting the "noise" DMRG sweeping parameter to be non-zero during some or all of your sweeps. It can often help with convergence.</p></li>
<li><p>modify your Hamiltonian on the boundary of your system to lift ground state degeneracies by adding "pinning fields". For example, in the case of a ferromagnetic phase, adding a uniform magnetic field to the boundary sites of your system will cause the true ground state to be the one aligned with the field.</p></li>
<li><p>of course, make sure you are doing sufficiently many sweeps to really converge your result (I assume you are already doing this one)</p></li>
</ol>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1842/varying-results-different-initial-states-system-calculations?show=1843#a1843Thu, 05 Dec 2019 09:45:46 +0000Answered: New Boson site operators
http://itensor.org/support/1825/new-boson-site-operators?show=1840#a1840
<p>Hi, thanks for the question about how the site classes and site sets work. </p>
<p>The shortest answer to your question is that to add new operators, it’s best to create your own new site type, using one of the provided ones as an example. You can copy, say, the boson.h file and just change the name of the class from BosonSite to CustomBosonSite say. Then add new operators and define your own new site set type at the top of the file.</p>
<p>The longer answer, regarding subclassing and reusing existing code, is that you technically can subclass these site classes, but that’s not how they’re intended to be used or extended. (In general C++ doesn’t have a great mechanism for extending things. Each one, such as inheritance, which seems promising at first ends up causing a ton of headaches when you really start using it more seriously.)</p>
<p>But a good approach for what you want to do would be to make a new class CustomBosonSite which just holds a BosonSite inside it (composition). Calling CustomBosonSite’s index() method is then defined as just calling .index() on the BosonSite object held inside of it. For the op(...) method, you would check if the name is one of the new ones you want to define and construct and return the desired operator. Otherwise, you would just call .op(...) on the BosonSite object internally as a fallback method. This way you could save yourself from having to copy-paste all of BosonSites internals into your class.</p>
<p>For some more background on how these site objects work, when they go into a site set object (such as BasicSiteSet) the site set holds a set of opaque “box” types (this is called type erasure) which can hold any one of the site types. This is so that different site types can be mixed and matched within a site set (e.g. S=1 sites throughout the bulk with S=1/2 sites at the edges). </p>
<p>When you call op(sites,”Name”,j) on some site set object “sites”, what it does is call the .op(“Name”,j) method on the site object held in “box” number j. This site object then runs its own op method which creates and returns an ITensor. The site set then returns this ITensor.</p>
<p>Hope that gives you the information you need. Please post another question below if you have a follow up.</p>
<p>Finally, in the new Julia version of ITensor we are almost done with, we are able to take great advantage of the dynamic and language reflection capabilities to make this all much more flexible and extensible with a minimum of code. So please look forward to that! </p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1825/new-boson-site-operators?show=1840#a1840Thu, 28 Nov 2019 02:45:08 +0000Answered: Casting SiteSet into appropriate type
http://itensor.org/support/1838/casting-siteset-into-appropriate-type?show=1839#a1839
<p>Actually I found a work around, so this is closed to me.</p>
<p>For those that are curious, here is my code</p>
<pre><code> auto sType = args->getString("SiteSet");
if (sType == "SpinHalf"){ auto rSites = SpinHalf(args->getInt("N")); rSites.read(f); sites = rSites; }
else if(sType == "SpinOne") { auto rSites = SpinOne(args->getInt("N")); rSites.read(f); sites = rSites; }
else if(sType == "SpinTwo") { auto rSites = SpinTwo(args->getInt("N")); rSites.read(f); sites = rSites; } }
</code></pre>
<p>so rSites is cast into the specific type needed, and then I read the SiteSet of interest into rSites, and then I just set sites = rSites.</p>
http://itensor.org/support/1838/casting-siteset-into-appropriate-type?show=1839#a1839Tue, 26 Nov 2019 05:02:59 +0000Answered: Broadcast operator over shared index
http://itensor.org/support/1826/broadcast-operator-over-shared-index?show=1836#a1836
<p>You could write the loops explicitly as you show.</p>
<p>An alternative is to write it in terms of <code>delta</code> tensors to constrain <code>idx_samp</code> of P and Q to be the same value, similar to this question here: <a rel="nofollow" href="http://www.itensor.org/support/1407/computing-the-partial-kronecker-product-of-two-itensors?show=1407#q1407">http://www.itensor.org/support/1407/computing-the-partial-kronecker-product-of-two-itensors?show=1407#q1407</a></p>
<p>So for your application, it would be something like:</p>
<pre><code>auto del = delta(idx_samp,prime(idx_samp),prime(idx_samp,2));
auto V = (P*U*prime(Q,idx_samp)*del).noPrime();
</code></pre>
<p>As is mentioned in the other post, this creates some unnecessary intermediate tensors so may not be the most efficient solution. Please let us know if either approach is not fast enough, it would be nice to have a more direct and efficient way of doing this in ITensor (but that kind of operation has not been very common so far in physics applications, so hasn't been a high priority to make special functionality for it).</p>
http://itensor.org/support/1826/broadcast-operator-over-shared-index?show=1836#a1836Mon, 25 Nov 2019 16:52:58 +0000Answered: how to compute the overlap with the original MPS after time evolution?
http://itensor.org/support/1827/compute-the-overlap-with-the-original-after-time-evolution?show=1829#a1829
<p>Yes, glad you figured out the answer, which is to use the function "overlap" in case you expect a real-valued overlap or the function "overlapC" if you expect a complex-valued output.</p>
<p>It's an interesting idea to define * to do overlap between MPS. We'll think about it. But one issue is simply a C++ issue, which is that function calls can only return a single type, so it would have to be a complex number to work in general. We could have psi * phi, where psi and phi are two MPS, result in a scalar ITensor though, which can be either real or complex.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1827/compute-the-overlap-with-the-original-after-time-evolution?show=1829#a1829Fri, 22 Nov 2019 17:47:09 +0000Answered: Obtain largest m from last sweep
http://itensor.org/support/1811/obtain-largest-m-from-last-sweep?show=1814#a1814
<p>You can gradually increase maxm, e.g. 50, 100, 150..., and set very big nsweeps, like 5000. Don't worry the bond dimension will go to very high because the truncation error will control it. Then you can add an arg in DMRGObserver.h, like "EnergyErrgoal" which is the difference between last two sweeps. Let dmrg stop if this quantity meet your convergence criteria, e.g. 1e-12. </p>
http://itensor.org/support/1811/obtain-largest-m-from-last-sweep?show=1814#a1814Tue, 19 Nov 2019 23:01:02 +0000Answered: Use removeQNs to partially remove QNs for MPS in Anderson-Holstein Model
http://itensor.org/support/1809/removeqns-partially-remove-qns-mps-anderson-holstein-model?show=1810#a1810
<p>Feng,<br>
This is a great idea for a feature we should have, so I opened an issue for it on our issue tracker page on Github.</p>
<p>However, unfortunately we will not be able to add this feature soon, as once we thought about the technical steps they are somewhat involved and we are also working to complete the Julia version of ITensor.</p>
<p>As a short-term fix, would you be able to just not conserve boson number in your initial ground state calculation? Maybe the ground state of that Hamiltonian has zero boson number anyway? Or if not, maybe you can include a chemical potential term to tune to the zero-boson-number ground state case?</p>
<p>You can always measure the total expected boson number after DMRG of course, to check.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1809/removeqns-partially-remove-qns-mps-anderson-holstein-model?show=1810#a1810Mon, 11 Nov 2019 18:08:21 +0000Answered: Using itensor as basis for a mathematical toolbox
http://itensor.org/support/1795/using-itensor-as-basis-for-a-mathematical-toolbox?show=1808#a1808
<p>Hi Sebastian,<br>
Thanks for sharing about your plans. Yes, it is indeed an error to put two copies of exactly the same Index on an ITensor, due to the fact that it would lead to an ambiguity when using the star operation to contract. (It does make me think of a possibly interesting future idea where we do allow it, but then enforce the tensor elements must remain symmetry under exchange of identical indices...)</p>
<p>That is great you are planning to implement heuristics for optimal contraction order. That is something we definitely want to add too, we are just thinking of the best place to handle it, whether automatically / internally, or by calling a certain function.</p>
<p>We are actually very interested in having ITensor become more useful for general applied math applications beyond quantum physics. But since applied math topics are quite diverse, we cannot always anticipate what functionality will be needed. So I think we will continue implementing ones we know about (automatic differentiation; point-wise non-linearities; Khatri-Rao product; slicing would be four off-hand examples of things we don't have but would like to) and also rely very much on feedback from users about additional features they need.</p>
<p>So please do share with us any ideas you have about making ITensor better. And we do have lots of features coming in the future but it will take a bit of time since we are doing an entire port to the Julia language currently (though almost done!).</p>
<p>Miles</p>
http://itensor.org/support/1795/using-itensor-as-basis-for-a-mathematical-toolbox?show=1808#a1808Fri, 08 Nov 2019 16:52:58 +0000Answered: Are extremely small singular values (less than ~10^-15) trustworthy?
http://itensor.org/support/1806/are-extremely-small-singular-values-less-than-trustworthy?show=1807#a1807
<p>Good question, though I don't feel comfortable giving a totally absolute answer. It's one of those "it depends" things as with any very technical matter.</p>
<p>But as a rule of thumb, when working with double-precision floating point numbers most operations are only trustworthy to about a precision of 10^-13 or so. This is because, among other reasons, that while double can store numbers much more precise than that, precision losses occur when subtracting two similar numbers for example. It's hard to avoid these kinds of operations in most algorithms of course.</p>
<p>Here is a sample calculation I just did in the Julia REPL to illustrate this:</p>
<p>Start by generating some random numbers:</p>
<p>julia> r1 = rand()<br>
0.034238108102722764</p>
<p>julia> r2 = rand()<br>
0.7802465824048777</p>
<p>julia> r3 = rand()<br>
0.09507249159735309</p>
<p>Now do some arithmetic and then undo it</p>
<p>julia> x = (r1/r2)*r3-100<br>
-99.9958281108584</p>
<p>julia> y = (100+x)/r3*r2 # y should equal r1 if using exact arithmetic<br>
0.03423810810274365</p>
<p>julia> r1<br>
0.034238108102722764 # you can see the last few digits differ from y</p>
<p>julia> y-r1<br>
2.0886070650760757e-14</p>
http://itensor.org/support/1806/are-extremely-small-singular-values-less-than-trustworthy?show=1807#a1807Fri, 08 Nov 2019 16:44:26 +0000Answered: Lapack flags missing in sample/tutorial makefiles?
http://itensor.org/support/1794/lapack-flags-missing-in-sample-tutorial-makefiles?show=1804#a1804
<p>Haha, god damn it. This took me one hour. You are correct, somehow FLAGS became FLASG, but I have do idea how this happened. I fixed it and now your original makefiles work. Thanks!</p>
http://itensor.org/support/1794/lapack-flags-missing-in-sample-tutorial-makefiles?show=1804#a1804Fri, 08 Nov 2019 10:26:59 +0000Answered: Severe Discrepancy between MPO and Trotter Time-Evolution?
http://itensor.org/support/1789/severe-discrepancy-between-mpo-and-trotter-time-evolution?show=1802#a1802
<p>In addition to Matt's answer, which I also agree looks very likely to be the issue, I'd like to note that we have been finding that the toExpH approach to performing time evolution has not always been the most reliable unfortunately (though it depends on details of the Hamiltonian and time step size etc.). So in general you might not be able to get as good of results with that method as, say, the Trotter method for cases where both can be used.</p>
<p>In the near future, we are planning to offer alternative time evolution methods which will supersede the toExpH approach.</p>
<p>Miles</p>
http://itensor.org/support/1789/severe-discrepancy-between-mpo-and-trotter-time-evolution?show=1802#a1802Thu, 07 Nov 2019 19:04:36 +0000Answered: How to realize Kondo-Heisenberg model with good quantum number on ITensor-3
http://itensor.org/support/1781/realize-kondo-heisenberg-model-with-quantum-number-itensor?show=1792#a1792
<p>Hello,</p>
<p>The error you are seeing when you try to conserve Nf but not Sz is due to the fact that currently in ITensor, you can't use a SiteSet that has some indices with QNs and some without. When you set <code>"ConserveSz=",false</code>, in the <code>SpinHalfSite</code> definition it will lead to the case where the Index is made without any QNs. If you would like to make that case work, you could try changing this line:</p>
<p><a rel="nofollow" href="https://github.com/ITensor/ITensor/blob/v3/itensor/mps/sites/spinhalf.h#L59">https://github.com/ITensor/ITensor/blob/v3/itensor/mps/sites/spinhalf.h#L59</a></p>
<p>from <code>s = Index(2,ts);</code> to <code>s = Index(QN(),2,ts);</code> (I haven't tried it, so please let us know if that works). This will make an Index with an empty QN, which should work. It may be a good idea for us to add an option for that case. One could argue that if you set <code>"ConserveQNs=",true</code> and <code>"ConserveSz=",false</code> then it should default to making an Index with empty QNs.</p>
<p>As for the cases you are seeing that are running without error but are not converging, you may have to play around with the <code>Sweeps</code> object, like changing the bond dimension growth schedule, the noise, or the number of davidson iterations. Perhaps someone else (like Miles) can comment on strategies for getting more complicated Hamiltonians like this to converge with DMRG.</p>
<p>-Matt</p>
http://itensor.org/support/1781/realize-kondo-heisenberg-model-with-quantum-number-itensor?show=1792#a1792Mon, 04 Nov 2019 15:45:42 +0000Different results for spin up and down
http://itensor.org/support/1786/different-results-for-spin-up-and-down
<p>Hi,</p>
<p>I'm running tDMRG for a simple anderson impurity coupled to two semi-infinite chain at different chemical potential, but get different dynamics for different spin states. Details are following:</p>
<p>First in the DMRG part, I decouple left chain, impurity, right chain to calculate the ground state of the decoupled system. Left chain and right chain are both half filled with same number of spin-up and spin-down electrons, and impurity is empty. My DMRG results are correct compared with analytic results (for a finite chain with even number of sites, the ground state of half filling has exactly local occupation of 0.5 for both spin-up and spin-down states.)</p>
<p>Secondly, I quench the whole system by coupling the impurity site and chains, and measure the dynamics of local occupation of spin-up and spin-down states. But these two occupations deviate very fast, which is unphysical considering that the Hamiltonian is symmetric under spin inversion). See the following results</p>
<p>t=0.01, Nup = 0.000945655, Ndn = 0.000945656<br>
t=0.02, Nup = 0.00370455, Ndn = 0.0037134 <br>
t=0.03, Nup = 0.00812654, Ndn = 0.00818666<br>
t=0.04, Nup = 0.0140243, Ndn = 0.0142351<br>
t=0.05, Nup = 0.0211824, Ndn = 0.0217184<br>
t=0.06, Nup = 0.0293665, Ndn = 0.03049 <br>
t=0.07, Nup = 0.0383324, Ndn = 0.0404003<br>
t=0.08, Nup = 0.0478346, Ndn = 0.0512999<br>
t=0.09, Nup = 0.057634, Ndn = 0.0630419<br>
t=0.10, Nup = 0.0675047, Ndn = 0.0754844</p>
<p>My code is:<br>
#include"itensor/all.h"<br>
#include <math.h><br>
#include <br>
using namespace itensor;</p>
<pre><code>int main(int argc, char *argv[])
{
float U=4;
float e0=-2;
float tb=10;
float td=3.1623;
float V=4;
int L=101;
double tau=0.01;
float t_tot=3;
auto Nc=L/2+1;//center site, impurity
double el=V/2;
double er=-V/2;
//Read ground-state
Electron sites;
readFromFile("site_file",sites);
MPS psi(sites);
readFromFile("ground_state",psi);
auto ampo = AutoMPO(sites);
//Right Chain
for(int j=Nc+1;j <=L-1; j+=1)
{
ampo += -tb,"Cdagup",j,"Cup",j+1;
ampo += -tb,"Cdagup",j+1,"Cup",j;
ampo += -tb,"Cdagdn",j,"Cdn",j+1;
ampo += -tb,"Cdagdn",j+1,"Cdn",j;
ampo += er,"Ntot",j;
}
ampo+=er,"Ntot",L;
//Left chain
for(int j=1;j < Nc-1; j+=1)
{
ampo += -tb,"Cdagup",j,"Cup",j+1;
ampo += -tb,"Cdagup",j+1,"Cup",j;
ampo += -tb,"Cdagdn",j,"Cdn",j+1;
ampo += -tb,"Cdagdn",j+1,"Cdn",j;
ampo += el,"Ntot",j;
}
ampo+=el,"Ntot",Nc-1;
//Impurity site
ampo+=e0,"Ntot",Nc;
ampo+=U,"Nup",Nc,"Ndn",Nc;
//Coupling
ampo+= -td,"Cdagup",Nc-1,"Cup",Nc;
ampo+= -td,"Cdagup",Nc,"Cup",Nc-1;
ampo+= -td,"Cdagdn",Nc-1,"Cdn",Nc;
ampo+= -td,"Cdagdn",Nc,"Cdn",Nc-1;
ampo+= -td,"Cdagup",Nc+1,"Cup",Nc;
ampo+= -td,"Cdagup",Nc,"Cup",Nc+1;
ampo+= -td,"Cdagdn",Nc+1,"Cdn",Nc;
ampo+= -td,"Cdagdn",Nc,"Cdn",Nc+1;
auto nt=round(t_tot/tau);
auto expH=toExpH(ampo,tau*Cplx_i);
auto args=Args("Method=","DensityMatrix","Cutoff=",1E-9,"MaxDim=",1000);
Real Ild, Ilu, Ird, Iru, nu, nd;
for(int j=1;j<=nt;j++){
psi=applyMPO(expH,psi,args);
psi.noPrime().normalize();
printf("t=%g\n",tau*j);
psi.position(Nc);
//Occu
nu=std::real(eltC(psi(Nc)*Nu*dag(prime(psi(Nc),"Site"))));
nd=std::real(eltC(psi(Nc)*Nd*dag(prime(psi(Nc),"Site"))));
printf("Nu=%g, Nd=%g, ",nu,nd);
return 0;
}
</code></pre>
<p>Can anyone help? THANK YOU!</p>
http://itensor.org/support/1786/different-results-for-spin-up-and-downMon, 04 Nov 2019 00:32:07 +0000Answered: Difference between S_x S_x +S_y S_y and S+S- +S-S+ for MPO
http://itensor.org/support/1782/difference-between-s_x-s_x-s_y-s_y-and-s-s-s-s-for-mpo?show=1784#a1784
<p>Hi, thanks for the question.</p>
<p>So I believe the answer to your first question is that S+S- + S-S+ is proportional to SxSx + SySy, not SxSx+SzSz. So unless your wavefunction is perfectly spin-rotationally invariant you will in general get a different answer when measuring these operators which are different.</p>
<p>You don’t have to convert operators to S+ S- form if you aren’t conserving the total Sz quantum number. However if you are conserving total Sz, you must input your Hamiltonian in terms of operators which change total Sz by a well-defined amount, so mainly Sz, S+, and S- (and not Sx or Sy).</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1782/difference-between-s_x-s_x-s_y-s_y-and-s-s-s-s-for-mpo?show=1784#a1784Sun, 03 Nov 2019 02:59:17 +0000Answered: Problem about convergence of tJ model
http://itensor.org/support/1780/problem-about-convergence-of-tj-model?show=1783#a1783
<p>Hi, thanks for the question. Are you using the very latest version of ITensor on the v3 branch? We recently fixed a bug specifically with the tJ site set which was causing Hamiltonians made from it to not be Hermitian, which could lead to the behavior you are seeing.</p>
<p>Please pull and recompile ITensor and then please let me know if the behavior persists. If it does we'll be happy to look deeper into it.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1780/problem-about-convergence-of-tj-model?show=1783#a1783Sat, 02 Nov 2019 15:20:06 +0000Answered: tDMRG parallel calculation
http://itensor.org/support/1774/tdmrg-parallel-calculation?show=1775#a1775
<p>Thanks for the question. We don’t have a parallel time evolution code available. Just out of curiosity though, what part of the algorithm were you hoping to parallelize and did you mean across multiple cores or using MPI across different nodes?</p>
<p>Best regards,<br>
Miles </p>
http://itensor.org/support/1774/tdmrg-parallel-calculation?show=1775#a1775Thu, 24 Oct 2019 13:33:03 +0000Answered: How to calculate two-operator correlation functions with conserved quantum numbers
http://itensor.org/support/1768/calculate-operator-correlation-functions-conserved-quantum?show=1769#a1769
<p>Hi, so instead of removing QNs at all, I would recommend using the fact that Sx = (S+ + S-)/2. Then if you measure four correlation functions: </p>
<pre><code><S+ S+>, <S+ S->, <S- S+>, <S- S->
</code></pre>
<p>, you can recombine those numbers to get </p>
<pre><code><Sx Sx>
</code></pre>
<p>. It doesn’t require any extra code if you wrap your measurement code in a function and pass the operator names into this function in the four combinations above.</p>
<p>Does that sound good to you?</p>
<p>Miles</p>
http://itensor.org/support/1768/calculate-operator-correlation-functions-conserved-quantum?show=1769#a1769Tue, 15 Oct 2019 01:02:40 +0000Answered: Error while compiling itebd package
http://itensor.org/support/1764/error-while-compiling-itebd-package?show=1765#a1765
<p>Hi, so I believe the error is coming because you are perhaps using the v3 branch of ITensor, whereas the iTEBD code requires the v2 branch. Please try switching to the v2 branch (git checkout v2) and recompiling (make clean; make).</p>
<p>Also, please note that the iTEBD code is maintained by a separate developer from us, and not maintained as part of ITensor. We are happy to help you to try to get it to work, but if it ultimately requires fixing bugs in that code you will need to contact the developer of it.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1764/error-while-compiling-itebd-package?show=1765#a1765Tue, 08 Oct 2019 14:24:00 +0000Answered: Difference between "Fit" and "DensityMatrix" for ApplyMPO
http://itensor.org/support/1753/difference-between-fit-and-densitymatrix-for-applympo?show=1754#a1754
<p>Hello,</p>
<p>The "DensityMatrix" algorithm is described here:</p>
<p><a rel="nofollow" href="http://tensornetwork.org/mps/algorithms/denmat_mpo_mps/">http://tensornetwork.org/mps/algorithms/denmat_mpo_mps/</a></p>
<p>It is a direct method (in that it only requires one sweep over the system), and is very reliable. However, it's accuracy may be limited to around 1e-8, because it relies on forming the density matrix which involves squaring the singular values, which can decrease the precision (but that is only an issue if you need very high precision).</p>
<p>The "Fit" algorithm involves variationally optimizing the overlap between an initial guess MPS and the MPO*MPS you are interesting in approximating with a sweeping algorithm similar to DMRG. It is known to get "stuck" (i.e. not find the correct MPS approximation) if the initial guess is not very good, or may take a lot of sweeps to converge (so you may want to try increasing the number of sweeps). This algorithm scales better with the bond dimensions of the input MPS/MPO compared to the "DensityMatrix" method.</p>
<p>If in your code applying the MPO to the MPS is not a performance bottleneck, and you do not need very high precision for your final MPS, then the "DensityMatrix" method is better to use. Otherwise, you will need to use the "Fit" method (and possibly play around with finding a better initial guess in order to get it to converge properly).</p>
<p>Cheers,<br>
Matt</p>
http://itensor.org/support/1753/difference-between-fit-and-densitymatrix-for-applympo?show=1754#a1754Tue, 01 Oct 2019 14:32:46 +0000Answered: Implementing AutoMPO for thermal state calculations
http://itensor.org/support/1751/implementing-autompo-for-thermal-state-calculations?show=1752#a1752
<p>So I figured it out, it was somewhere else in my code that the issue was arising. For anyone else having the same issue, AutoMPO automatically puts the identity on operators that are not specified.</p>
http://itensor.org/support/1751/implementing-autompo-for-thermal-state-calculations?show=1752#a1752Tue, 01 Oct 2019 01:44:41 +0000Answered: Time evolution of Hamiltonian containing 4-operator term with MPO.
http://itensor.org/support/1749/time-evolution-hamiltonian-containing-operator-term-with?show=1750#a1750
<p>Hi, so unfortunately our toExpH feature is limited to Hamiltonians consisting of at most 2-operator terms only. The reason is that it's technical to extend the same method that lets AutoMPO work for > 2 operator terms to also define the exponential of H, even though in principle this could be done perhaps.</p>
<p>But additionally, since implementing toExpH, we and the tensor network community have found that MPO-based time evolution is not a particulary reliable or accurate time-evolution method (in relative terms, since it does work but just not as well) compared to other methods. The best method to use would be TDVP which only needs the Hamiltonian MPO as input. (See the recent review by Paeckel et al. for a technical discussion of both time-evolution methods.) So this is unfortunate given the convenience of MPO methods, but is a useful thing to keep in mind.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1749/time-evolution-hamiltonian-containing-operator-term-with?show=1750#a1750Thu, 26 Sep 2019 16:42:08 +0000Answered: Can an Observer function access pre- and post- truncation eigenvalues?
http://itensor.org/support/1747/can-observer-function-access-post-truncation-eigenvalues?show=1748#a1748
<p>Hi Jon,<br>
So looking at the current ITensor code, the Spectrum object only contains the post-truncation density matrix eigenvalues. This could be modified if you really need them. Probably an easier way to go about this, though (if cost isn't a huge issue), would be to do the SVD twice inside of DMRG: once without any truncation, then a second time with truncation.</p>
<p>To do the SVD step twice, just repeat line 404 of this file:<br>
<a rel="nofollow" href="https://github.com/ITensor/ITensor/blob/v3/itensor/mps/dmrg.h">https://github.com/ITensor/ITensor/blob/v3/itensor/mps/dmrg.h</a></p>
<p>but the first time, write the line like this:</p>
<p>auto spec_full = psi.svdBond(b,phi,(ha==1?Fromleft:Fromright),PH,{args,"Truncate=",false});</p>
<p>The "spec_full" Spectrum object should have the full spectrum contained inside.</p>
<p>As you can see from line 423 of dmrg.h, the Observer is given the truncation error though its args. Take a look at this file:<br>
<a rel="nofollow" href="https://github.com/ITensor/ITensor/blob/v3/itensor/mps/DMRGObserver.h">https://github.com/ITensor/ITensor/blob/v3/itensor/mps/DMRGObserver.h</a><br>
to see how DMRGObserver grabs this truncation error, and takes a max over it over each sweep, only reporting the max. You could modify DMRGObserver or make your own observer which does a different thing with the truncation error information.</p>
<p>Due to limitations of C++, the observer doesn't have access to the spectrum. You'll have to modify the code in dmrg.h directly to save / print / otherwise access the spectrum during DMRG.</p>
<p>Finally, definitely consider also how meaningful the spectrum of eigenvalues is <em>during</em> DMRG versus that of the MPS <em>after</em> DMRG. As you know, these eigenvalues during DMRG will change depending on many possible, reasonable choices of the sweep parameters. So they might not be precisely physically meaningful, and rather reflect how the optimization was done. But of course toward the later sweeps, they should become close to those of the fully optimized MPS.</p>
<p>Miles</p>
http://itensor.org/support/1747/can-observer-function-access-post-truncation-eigenvalues?show=1748#a1748Tue, 24 Sep 2019 11:59:37 +0000Answered: Allocate an ITensor with given index structure
http://itensor.org/support/1732/allocate-an-itensor-with-given-index-structure?show=1737#a1737
<p>Hello,</p>
<p>An easy way to replace the indices of an ITensor is by multiplying with a series of delta tensors. If the original tensor has indices {i,j,k} and you want it changed to {a,b,c}, you can do:</p>
<pre><code>G2 = G2 * delta(i,a) * delta(j,b) * delta(k,c);
</code></pre>
<p>In your case, {i,j,k} would be the indices of G2, and {a,b,c} would be the corresponding indices of G1.</p>
<p>Cheers,<br>
Matt</p>
http://itensor.org/support/1732/allocate-an-itensor-with-given-index-structure?show=1737#a1737Mon, 16 Sep 2019 18:32:42 +0000Answered: TRG sample code provided on the hompage produces errors during compilation
http://itensor.org/support/1733/sample-provided-hompage-produces-errors-during-compilation?show=1734#a1734
<p>Thank you for catching that, that needs to be fixed in the way that you show.</p>
<p>The correct code can be found in the "sample" directory of the ITensor library (<a rel="nofollow" href="https://github.com/ITensor/ITensor/blob/v3/sample/trg.cc">https://github.com/ITensor/ITensor/blob/v3/sample/trg.cc</a> ), we forgot to update the website with the proper code.</p>
<p>Cheers,<br>
Matt</p>
http://itensor.org/support/1733/sample-provided-hompage-produces-errors-during-compilation?show=1734#a1734Mon, 16 Sep 2019 13:58:19 +0000Answered: Question about InputGroup and Args
http://itensor.org/support/1724/question-about-inputgroup-and-args?show=1727#a1727
<p>Hi Nick,<br>
I'm not sure I understand the part of your question about the input parameters changing mid program. I believe when you read in the input file the parameters are set at that point (are read into the InputGroup object), then when you retrieve them they will be whatever they were when the file was read. Are you planning on changing your input file while your program is running? Conceptually that's possible but I would not recommend it.</p>
<p>In terms of how the input.h / InputGroup system relates to Args, they were developed separately so don't really interoperate. At one point I made them have a similar interface so it would be easier to remember how to use them. I did plan to later on make them more interoperable, like having the option to retrieve the input parameters as an Args object. But I had more pressing things so haven't done it. It would be a good project for someone to do and I think would not be too hard; the code for each is relatively straightforward and well written I think.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1724/question-about-inputgroup-and-args?show=1727#a1727Fri, 13 Sep 2019 17:49:20 +0000Answered: Efficient calculation of magnetization susceptibility
http://itensor.org/support/1719/efficient-calculation-of-magnetization-susceptibility?show=1720#a1720
<p>Hi RS,<br>
Good question. Yes: making an MPO is definitely the way to go. I've used this technique before and it works very well. </p>
<p>In fact, there is some code here you can use or copy to make the MPO:<br>
<a rel="nofollow" href="https://github.com/emstoudenmire/finiteTMPS/blob/master/S2.h">https://github.com/emstoudenmire/finiteTMPS/blob/master/S2.h</a></p>
<p>(It is ITensor v2 code, which shouldn't be hard to upgrade to v3 if you read our guide, or we can chat about it).</p>
<p>For measuring expectation values of MPOs, there's no need to think about the gauge of the MPS. The reason is that the algorithm to compute the expectation value contracts the entire MPS with the MPO with another (entire) copy of the MPS. So the gauge simply plays no role.</p>
<p>In ITensor (v3) you can use the function inner(psi,W,psi) where W is your MPO to compute <psi|W|psi>. Use innerC if your MPS is complex-valued.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1719/efficient-calculation-of-magnetization-susceptibility?show=1720#a1720Mon, 02 Sep 2019 18:41:41 +0000Answered: std::bad_alloc in Transfer Matrix calculation
http://itensor.org/support/1712/std-bad_alloc-in-transfer-matrix-calculation?show=1713#a1713
<p>Hi Yixuan,<br>
Yes, the reason for this error message is that your system has run out of memory / RAM. So one solution is definitely to try a system with more RAM if possible.</p>
<p>But another solution could be to write any large tensors you are not using at a particular step to disk. You can estimate the size of various tensors by multiplying the dimension of their indices together. Using this estimate, you might find that individual MPS tensors themselves aren't using a lot of memory, but tensors formed from the MPS can use a very large amount. (Or you might find that the MPS tensors alone are using a lot of memory; it depends on the details.)</p>
<p>We have some automatic facilities to write parts of an MPS to disk. But these may not work ideally for a transfer matrix calculation and are designed mostly to be used inside a DMRG calculation. </p>
<p>But you can even do writing to disk manually by just writing a tensor to a particular file with a good file name, then overwriting the tensor with an empty tensor to 'free' it from memory. Later, when you need the tensor again you can read it back in from the file and overwrite the read-in tensor onto your empty tensor to restore it.</p>
<p>If you decide to follow one of the three approaches above and run into issues, please post a comment below or a new question.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1712/std-bad_alloc-in-transfer-matrix-calculation?show=1713#a1713Thu, 29 Aug 2019 20:20:26 +0000Answered: Error with symmetry while measuring the properties of an MPS wavefunction (with conserved QNs)
http://itensor.org/support/1704/error-symmetry-measuring-properties-wavefunction-conserved?show=1711#a1711
<p>Hello,</p>
<p>An immediate thing to note is that since the state you are measuring has a well-defined Sz quantum number, measuring Sx will always be zero (since the Sx operator will change the total spin of your state, so Sx|psi> will have a different total Sz from |psi> so <psi|Sx|psi> must be zero).</p>
<p>However, this question brought up the fact that this operation is currently not as easy as it should be to do right now in ITensor. Currently, this is the easiest way I can think of to measure a non-QN conserving operator of a QN-conserving MPS:</p>
<pre><code>auto N = 10;
auto sites = SpinOne(N);
auto state = InitState(sites,"Up");
auto psi = MPS(state);
// Measure Sx on site j
auto j = 3;
psi.position(j);
// Get the site index without QNs
auto sj = removeQNs(sites(j));
// Create a SpinOneSite from the Index
// without QNs to use in the op function
auto Sxj = op(SpinOneSite(sj),"Sx");
auto sxj = elt(psi(j)*Sxj*dag(prime(psi(j),"Site")));
PrintData(sxj);
</code></pre>
<p>We are discussing alternative solutions to be able to do this more generally (without manually modifying the Index and then creating the correct Site type), but unfortunately they require fairly technical solutions right now given the current system.</p>
<p>Cheers,<br>
Matt</p>
http://itensor.org/support/1704/error-symmetry-measuring-properties-wavefunction-conserved?show=1711#a1711Thu, 29 Aug 2019 14:30:29 +0000Disappearing value of Sx and Sy, while measuring expected values of spin (per site)
http://itensor.org/support/1705/disappearing-value-while-measuring-expected-values-spin-site
<p>I'm trying to measure expected values of <code>Sx</code>, <code>Sy</code> and <code>Sz</code> on each site for given Hamiltonian and graph. My code looks as follows:</p>
<pre><code>#include "itensor/all.h"
using namespace itensor;
int
main(int argc, char* argv[])
{
int Nx = 8; // Nx can be understood as the size of an elementary cell
auto N = atoi(argv[1])*Nx;
auto sites = SpinOne(N,{"ConserveQNs=",false});
auto ampo = AutoMPO(sites);
// [Definitiion of my Hamiltonian]
auto H = toMPO(ampo);
auto state = InitState(sites);
for (int i = 1; i <= N; i++) {
state.set(i,"Up");
}
auto sweeps = Sweeps(10);
sweeps.maxm() = 50,100,200,300,400;
sweeps.cutoff() = 1E-10;
println(sweeps);
//
// Begin the DMRG calculation
// for the ground state
//
auto [en0,psi0] = dmrg(H,randomMPS(sites),sweeps,{"Quiet=",true});
//
// Print the final energies reported by DMRG
//
printfln("\n Ground State Energy = %.10f",en0);
//
// Measuring Sx, Sy & Sz
//
println("Ground state");
println("\nj | Sx | Sy | Sz | S_total |: ");
for( auto j : range1(N) ) {
// Re-gauge psi0 to get ready to measure at position j
psi0.position(j);
auto ket = psi0(j);
auto bra = dag(prime(ket,"Site"));
auto Sxjop = op(sites,"Sx",j);
auto Syjop = op(sites,"Sy",j);
auto Szjop = op(sites,"Sz",j);
//take an inner product
auto sxj = eltC(bra*Sxjop*ket);
auto syj = eltC(bra*Syjop*ket);
auto szj = eltC(bra*Szjop*ket);
println(j, " | ", sxj, " | ", syj, " | ", szj, " | ", sxj + syj + szj, " | ");
}
return 0;
</code></pre>
<p>}</p>
<p>When I run the above program I get:</p>
<pre><code>Ground state
j | Sx | Sy | Sz |:
1 | (2.82726e-12,0) | (0,-2.64747e-28) | (-0.98518,0) |
[...]
</code></pre>
<p>However, if I only change the part:</p>
<pre><code>[...]
auto Sxjop = op(sites,"Sx",j);
auto Syjop = op(sites,"Sy",j);
auto Szjop = op(sites,"Sz",j);
[...]
</code></pre>
<p>into:</p>
<pre><code>[...]
auto Sxjop = op(sites,"Sx2",j);
auto Syjop = op(sites,"Sy2",j);
auto Szjop = op(sites,"Sz2",j);
[...]
</code></pre>
<p>I get:</p>
<pre><code>Ground state
j | Sx^2 | Sy^2 | Sz^2 | S_total^2 |:
1 | (0.5,0) | (0.5,0) | (1,0) | (2,0) |
[...]
</code></pre>
<p>which makes sense, because I believe the square of total spin satisfies following rules: </p>
<p>$$<br>
S<em>{total}^2 = S</em>x^2 + S<em>y^2 + S</em>z^2<br>
S_{total}^2 = S ( S + 1),<br>
$$</p>
<p>so for the spin @@ S = 1 @@ I should get @@ S_{total}^2 = 2 @@, which holds.</p>
<p>But I have to measure the values <code>Sx</code>, <code>Sy</code> and <code>Sz</code> instead of their squares. Do you have any suggestions?</p>
http://itensor.org/support/1705/disappearing-value-while-measuring-expected-values-spin-siteWed, 28 Aug 2019 14:40:33 +0000Answered: What is "restricted sweeping over sub-region" as described in docs?
http://itensor.org/support/1700/what-is-restricted-sweeping-over-sub-region-described-docs?show=1702#a1702
<p>Hello,</p>
<p>In the documentation page you link to (<a rel="nofollow" href="https://itensor.org/docs.cgi?page=classes/dmrg">https://itensor.org/docs.cgi?page=classes/dmrg</a> ) the last DMRG version listed can be used for "restricted sweeping".</p>
<p>That version accepts boundary tensors that represent the Hamiltonian projected into a fixed basis (you can think of it as a boundary condition for the DMRG calculation). You would have to pre-calculate those boundary tensors by projecting your Hamiltonian into the MPS basis you are interested in. </p>
<p>If you have any questions about how it would be used, please let us know.</p>
<p>Cheers,<br>
Matt</p>
http://itensor.org/support/1700/what-is-restricted-sweeping-over-sub-region-described-docs?show=1702#a1702Tue, 27 Aug 2019 14:30:25 +0000Answered: Segmentation fault when trying to read in site and wavefunctions
http://itensor.org/support/1683/segmentation-fault-when-trying-read-site-and-wavefunctions?show=1699#a1699
<p>Question is answered in above comments</p>
http://itensor.org/support/1683/segmentation-fault-when-trying-read-site-and-wavefunctions?show=1699#a1699Fri, 23 Aug 2019 00:54:10 +0000Answered: Index does not contain given QN block
http://itensor.org/support/1665/index-does-not-contain-given-qn-block?show=1666#a1666
<p>Hi, so one thing that jumps out at me is that you already give the vector "v" a size, but then use emplace_back to put things into it, which will put more things at the end, still leaving 2*dim+1 default-initialized pair<QN,long> 's at the beginning.</p>
<p>There may be other issues but this looks like a definite one!</p>
<p>Miles</p>
http://itensor.org/support/1665/index-does-not-contain-given-qn-block?show=1666#a1666Thu, 08 Aug 2019 18:27:20 +0000Answered: solve an eigenvalue problem of non-hermitian tensor
http://itensor.org/support/1615/solve-an-eigenvalue-problem-of-non-hermitian-tensor?show=1664#a1664
<p>I ported <code>arnoldi</code> to ITensor V3 to find dominant eigenvectors and eigenvalues of non-Hermitian sparse matrices. You can take a look at these tests:</p>
<p><a rel="nofollow" href="https://github.com/ITensor/ITensor/blob/v3/unittest/iterativesolvers_test.cc#L252">https://github.com/ITensor/ITensor/blob/v3/unittest/iterativesolvers_test.cc#L252</a></p>
<p>to get an idea for how it is used.</p>
<p>Cheers,<br>
Matt</p>
http://itensor.org/support/1615/solve-an-eigenvalue-problem-of-non-hermitian-tensor?show=1664#a1664Wed, 07 Aug 2019 20:37:39 +0000Answered: Different boson number cutoffs for different sites
http://itensor.org/support/1639/different-boson-number-cutoffs-for-different-sites?show=1659#a1659
<p>Just to begin answering this question - it’s a good question.</p>
<p>Yes you can definitely create two different types of sites when making your own site set in ITensor. This is easier to do and works better in version 3 of ITensor. </p>
<p>Essentially all you have to do is to first follow the procedure for making each type of site separately, using classes like BosonSite as an example, but adjust the dimension of the site index and/or range of the quantum numbers to what you want. </p>
<p>Now that you have two different site classes, “AType” and “BType” say, you can make your site set as:<br>
using MySiteSet = MixedSiteSet<AType,BType>; <br>
which will make the odd-numbered sites be AType sites and the even-numbered sites BType sites.</p>
<p>See the sample/mixedspin.cc sample code for an example of this using in action.</p>
<p>Alternatively, if the AType and BType sites are similar enough in their design, you could have them be just the same type and control their properties through passing named arguments (Args) and looking at the site number when constructing them. But this could ultimately make things more complicated, since when getting operators you will also have to put in checks about what kind of site you are making operators for.</p>
<p>Which of the above two ways to go depends then on the details.</p>
<p>Good luck! </p>
<p>Miles</p>
http://itensor.org/support/1639/different-boson-number-cutoffs-for-different-sites?show=1659#a1659Wed, 07 Aug 2019 14:45:10 +0000