ITensor Support Q&A - Recent questions and answers
http://itensor.org/support/qa
Powered by Question2AnswerAnswered: I think diagHermitian may not be working properly.
http://itensor.org/support/2160/i-think-diaghermitian-may-not-be-working-properly?show=2163#a2163
<p>Simple mistake, I used S+ and S- instead of Sx and Sy, and so my Hamiltonian was in fact not Hermitian. Fixing this solved the issue.</p>
http://itensor.org/support/2160/i-think-diaghermitian-may-not-be-working-properly?show=2163#a2163Wed, 03 Jun 2020 18:05:31 +0000Answered: Various questions about QN conservation in Julia
http://itensor.org/support/2156/various-questions-about-qn-conservation-in-julia?show=2157#a2157
<p>Hi Sujay,<br>
Thanks for the good & detailed questions. These touch on things we want everyone to understand when working in a more hands-on way with the QN conserving ITensor system. We're trying to find the best way to document and introduce them, and one way is just by building a knowledge base on this forum. As you probably know, the draft of the ITensor Book on the website also introduces some QN ITensor concepts: <a rel="nofollow" href="http://itensor.org/docs.cgi?vers=julia&page=book">http://itensor.org/docs.cgi?vers=julia&page=book</a> . And we will soon publish an ITensor paper that provides many details.</p>
<p>To answer your questions:</p>
<p>(1) yes we require the quantum numbers to be integers for reasons of efficiency and correctness. E.g. we wouldn't want to store them as floating point because that would introduce all sorts of complications. But your question (which others have asked before) does remind me that Julia has facilities for exact computations with rational numbers, which we might consider expanding QN's to use in the future. For now please just make an integer correspondence between the quantum numbers as used on paper and in ITensor (e.g. we have the convention of working in units of 1/2 for spin quantum numbers, so 1/2 becomes 1, 1 becomes 2, etc.).</p>
<p>(2) The notation <code>A => B</code> in Julia creates a <code>Pair(A,B)</code> object, which is just a struct holding the values A and B. It can be an unfamiliar notation coming from other languages, and it was for me too. So it is nothing specific to ITensor but just a convenient way to group two values together that we've adopted for this Index constructor. Each pair denotes a subspace of the Index, meaning that the entire index labels the basis of a vector space (of dimension 3 here) and each subspace occurs sequentially giving the space a direct-sum structure. The second number of each pair is the dimension of that subspace. So the 1's are saying that each subspace is of dimension 1.</p>
<p>(3) I'm not sure exactly in what sense you're asking about having an arbitrary number of QNs at once, but I can comment on a few relevant things here. One is that an Index can have as many QN subspaces as you want. So in code like:</p>
<pre><code>i = Index(QN(0)=>1, QN(1)=>2, Q(2)=4, ... )
</code></pre>
<p>the list of QN=>Int pairs can go on as long as you want, up to the memory limits of the machine. On the other hand, <em>within</em> a QN object itself, you can only have up to 4 different types of quantum numbers stored. So like <code>QN(("A",1),("B",0),("C",-1),("D",3))</code> would be reaching the limit of 4 different QN values. This is for reasons of efficiency as it greatly reduces allocations while on the other hand we've so far heard of few cases where more than 4 QN names were needed at once. But if you definitely do need more, we can work with you to lift this restriction.</p>
<p>I don't know much about the Schwinger model or its symmetries. Could you provide more information about how you're thinking of implementing it and the Hamiltonian used? Our ITensor QN system is currently only designed to handle the case of global, Abelian symmetries of a Hamiltonian. So it does not handle non-Abelian symmetries such as global SU(2) for example. But local symmetries such as in lattice gauge theories are an interesting case I think we've just not thought about. So it's not obvious to me whether our existing system can handle that case, or whether it could with some small changes, or even what is the right approach to such symmetries in tensor networks more broadly. This review could provide some information about the status of this topic: <a rel="nofollow" href="https://arxiv.org/abs/1810.12838">https://arxiv.org/abs/1810.12838</a></p>
<p>(4) Regarding the construction of QN-conserving MPOs, some of the precise details can get rather involved and at the same time many are just conventions and could vary from one implementation to another. The conventions we use in ITensor code are that for a QN-conserving MPO with total flux zero (such as the Hamiltonian, which by definition has to be total flux zero since it preserves the quantum numbers), all of the MPO tensors are themselves <em>individually</em> flux zero. This isn't formally necessary, but is a very natural and convenient convention. So when constructing each tensor, flux non-zero operators such as S+ or S- are "balanced" by bond or link indices of the MPO having subspaces which cancel out the flux of the operator to keep things net flux zero. </p>
<p>I gave a pretty detailed answer about some of these conventions in this forum question:<br>
<a rel="nofollow" href="http://itensor.org/support/2083/properly-handle-quantum-number-for-system-spin-half-moments?show=2083#q2083">http://itensor.org/support/2083/properly-handle-quantum-number-for-system-spin-half-moments?show=2083#q2083</a></p>
<p>Please take a look at that, even though the question is about a C++ code file that makes the Heisenberg MPO. Both my answer there as well as the C++ example itself could be helpful. If you'd like to discuss how some of that C++ code would be adapted to the Julia version we could discuss that in the future.</p>
<p>Ok hope all of that helps you to make some more progress - I understand it's a lot to digest.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/2156/various-questions-about-qn-conservation-in-julia?show=2157#a2157Tue, 02 Jun 2020 22:00:42 +0000Answered: Using Sx, Sy in SpinOne
http://itensor.org/support/2152/using-sx-sy-in-spinone?show=2154#a2154
<p>Adding on a bit to what JR said, basically, if you want to conserve total Sz, then you need to avoid the use of Sx and Sy operators directly in your code and express everything that requires Sx and Sy in terms of S+ and S-.</p>
<p>I agree that there are situations in which this can feel awkward; I remember asking this same question a while back on the GitHub page for the Julia version of this code.</p>
<p>The reasoning behind this design choice is that S+ and S- have a definite QN flux: an S+/S- operator on a site always increases/decreases the total Sz by 1. In contrast, Sx and Sy don't have this property: an Sx/Sy operator on a site has a component that increase total Sz by 1 and a component that decreases total Sz by 1.</p>
http://itensor.org/support/2152/using-sx-sy-in-spinone?show=2154#a2154Tue, 02 Jun 2020 05:01:08 +0000Answered: how to compute the ground state energy in a given symmetry sector?
http://itensor.org/support/2147/how-compute-the-ground-state-energy-in-given-symmetry-sector?show=2150#a2150
<p>Hi Yantao,<br>
Thanks for the question. This is a good question because it is one of the more subtle aspects of ITensor, though it is also very simple to use in the end.</p>
<p>The answer to your questions is that the way quantum-number-conserving tensors work in the ITensor library (both the C++ and Julia versions) is that they always change whichever quantum numbers you are conserving by a <em>definite amount</em>. And for the case of acting with the Hamiltonian or a "gate" which is an exponential of a Hamiltonian term, the change to the total quantum number is zero, so no change at all.</p>
<p>Practically what this means is the following:<br>
1. if you initialize an ITensor DMRG calculation with an MPS made of quantum-number conserving ITensors, then it is guaranteed that the resulting, optimized MPS will have the same total quantum numbers as the initial state<br>
2. if you do a calculation such as TEBD, then as long as your gates conserve the quantum numbers (are zero-flux QNITensors) then the total quantum numbers of your MPS will not change</p>
<p>So if you just prepare an initial state in the symmetry sector you want, the calculations will stay in that symmetry sector. You can check the total quantum number at any point during or after a calculation by calling <code>totalQN(psi)</code> (or <code>totalqn(psi)</code> in Julia) on an MPS <code>psi</code>.</p>
<p>Of course please comment below if you have more questions about this -</p>
<p>Miles</p>
http://itensor.org/support/2147/how-compute-the-ground-state-energy-in-given-symmetry-sector?show=2150#a2150Mon, 01 Jun 2020 14:51:18 +0000Answered: Applying and Storing Local Operator on MPS and Generalized Orthogonalization of MPS
http://itensor.org/support/2142/applying-storing-operator-generalized-orthogonalization?show=2146#a2146
<p>Hi Ajit,<br>
Thanks for the timely question, as this is an important operation to do when working with MPS. As Matt said above, the short answer to your question is that you just do <code>psi[n] = T</code> to set the nth tensor of an MPS to be <code>T</code>. </p>
<p>But for a longer example, I just adapted the code formula for doing this from the C++ version to the new Julia version of ITensor.</p>
<p>Please see the code formula for this here:<br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?page=formulas/mps_onesite_op&vers=julia">http://itensor.org/docs.cgi?page=formulas/mps_onesite_op&vers=julia</a></p>
<p>And let us know if you have any more questions.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/2142/applying-storing-operator-generalized-orthogonalization?show=2146#a2146Sat, 30 May 2020 23:50:38 +0000Implementing local gauge symmetries
http://itensor.org/support/2140/implementing-local-gauge-symmetries
<p>Hi everybody, </p>
<p>I'm trying to set up the lattice Schwinger model which is a 1+1D theory with a U(1) gauge symmetry. I have defined a mixed site set consisting of a spin half site (the matter field) and a boson site (the gauge field) with a cutoff. The Hamiltonian is as given in Eq. 2 of this paper: <a rel="nofollow" href="https://arxiv.org/pdf/1312.6654.pdf.">https://arxiv.org/pdf/1312.6654.pdf.</a> </p>
<p>In addition to a global U(1) symmetry (which I know how to implement natively in iTensor), the physical Hilbert space satisfies a Gauss' law that commutes with the Hamiltonian, is site-dependent, and has the following form:</p>
<p>G_i = E_(i+1) - E_i + (-1)^i n_i = 0</p>
<p>where n_i is the matter number operator at site i and E_i is the gauge electric field (which is diagonal in the site basis). Is there a way to implement this sort of local, site-dependent symmetry to further constrain the block structure of the tensors? I haven't been able to find a way, and the only resource I have found so far is an earlier post discussing how to implement separate symmetries on two sublattices of the lattice. </p>
<p>While the Schwinger model is special in that you can eliminate the gauge degree of freedom, being able to implement gauge symmetries would provide a large speedup when we move to more complicated systems, so it would be great to know whether or not this is possible. </p>
<p>Any pointers would be greatly appreciated! </p>
<p>Thanks.</p>
http://itensor.org/support/2140/implementing-local-gauge-symmetriesTue, 26 May 2020 18:08:46 +0000Answered: Calculating Expectation Value And Correlator From MPS in ITensor Julia
http://itensor.org/support/2134/calculating-expectation-value-correlator-from-itensor-julia?show=2136#a2136
<p>Hi Ajit,<br>
Thanks for the question. I just began working on a "Code Formula" about this which you can find at this link:</p>
<p><a rel="nofollow" href="http://itensor.org/docs.cgi?vers=julia&page=formulas/measure_mps">http://itensor.org/docs.cgi?vers=julia&page=formulas/measure_mps</a></p>
<p>The formula already gives a working example for the case of measuring the "Sz" operator on each site of an MPS. I'll expand it over time to show some other examples and more context. Then later I'll add another formula about measuring correlation functions. (Though if you understand the above example and how to measure correlation functions in the C++ version of ITensor, the translation of the code for that case is very similar.)</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/2134/calculating-expectation-value-correlator-from-itensor-julia?show=2136#a2136Tue, 26 May 2020 02:28:00 +0000The block size and index in QDense
http://itensor.org/support/2133/the-block-size-and-index-in-qdense
<p>Hi,</p>
<p>When I print a tensor in QDense format, the result is as follows:</p>
<p>A----size(): 136<br>
A----offsets: Block: 0,0,0, Offset: 0<br>
Block: 1,2,0, Offset: 12<br>
Block: 1,0,1, Offset: 20<br>
Block: 0,1,1, Offset: 68<br>
Block: 2,2,1, Offset: 76<br>
Block: 2,0,2, Offset: 88<br>
Block: 1,1,2, Offset: 115<br>
Block: 3,2,2, Offset: 127<br>
Block: 3,0,3, Offset: 130<br>
Block: 2,1,3, Offset: 133</p>
<p>The size of each dimension is: 10 x 5 x 10 (by reviewing the dim in Con.Lis/Con.Ris/Con.Nis). There will be 500 elements (10x5x10) and 136 dense elements (A.size()) in this 3-order tensor. I have three questions:</p>
<p>1) What is the block size in this case? For example, the number of elements between blocks (1,0,1) and (0,1,1) is 68 - 20 = 48. Also, how many blocks in this case?</p>
<p>2) How to map the index of block (4 x 3 x 4?) to the coordination (10 x 5 x 10) in the COO format?</p>
<p>3) Is the block size fixed for all blocks?</p>
<p>Thank you so much in advance for any comments!</p>
http://itensor.org/support/2133/the-block-size-and-index-in-qdenseMon, 25 May 2020 06:46:23 +0000Answered: Sites of spin higher than 1/2 and 1?
http://itensor.org/support/2125/sites-of-spin-higher-than-1-2-and-1?show=2131#a2131
<p>Hi Sujay,<br>
Thanks for the question. This is something we are hoping to make easier in the Julia version of ITensor compared to the C++ version, where it was possible to make custom site types / physical degrees of freedom. </p>
<p>I have just created a comprehensive example and discussion on the ITensor website here:<br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?vers=julia&page=formulas/site_type">http://itensor.org/docs.cgi?vers=julia&page=formulas/site_type</a><br>
using the case of S=3/2 as the example.</p>
<p>Please let me know if this covers your question, if the code works for you, or if you have any questions about the writeup there.</p>
<p>I should post another example about how to mix different site types together, but basically it's as simple as making an array of indices where every other Index object carries a different tag corresponding to the types you want. So like alternating between "S=1/2" and "S=3/2" tags for example, with the indices also having the appropriate dimensions of 2 and 4 respectively.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/2125/sites-of-spin-higher-than-1-2-and-1?show=2131#a2131Fri, 22 May 2020 03:23:15 +0000Answered: Is it possible to create a quantum system with different types of sites?
http://itensor.org/support/2122/possible-create-quantum-system-with-different-types-sites?show=2124#a2124
<p>Hi Sujay,<br>
Thanks for the question: yes this is definitely possible.</p>
<p>An example showing how to do this in the Julia version of ITensor can be found here:<br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?vers=julia&page=formulas/mixed_sites_dmrg">http://itensor.org/docs.cgi?vers=julia&page=formulas/mixed_sites_dmrg</a><br>
Later we will update this example to show how to include quantum number conservation; it can already be done so please reply below if you have a question about that.</p>
<p>For the C++ version, an example of doing this can be found in the sample code itensor/sample/mixedspin.cc. Also we have an example here: <br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?vers=cppv3&page=formulas/gs_holst_polaron">http://itensor.org/docs.cgi?vers=cppv3&page=formulas/gs_holst_polaron</a></p>
<p>Best,<br>
Miles</p>
http://itensor.org/support/2122/possible-create-quantum-system-with-different-types-sites?show=2124#a2124Thu, 21 May 2020 15:23:11 +0000runtime performance of Julia vs c++ DMRG
http://itensor.org/support/2119/runtime-performance-of-julia-vs-c-dmrg
<p>Can you provide any preliminary data on Julia vs C++ runtime for iTensor’s DMRG? Is the algorithm implemented in Julia the same 2-site algorithm implemented in Julia?</p>
http://itensor.org/support/2119/runtime-performance-of-julia-vs-c-dmrgWed, 20 May 2020 21:46:33 +0000Answered: complexities of delta Tensor multiplication and the / operation
http://itensor.org/support/2105/complexities-delta-tensor-multiplication-and-the-operation?show=2116#a2116
<p>Hi Chia-Min,</p>
<p><code>T.replaceInds(...)</code> and <code>delta</code> should both essentially be no-ops (they should just be replacing the indices in the IndexSet, and not doing anything to the storage). <code>T.replaceInds(...)</code> actually calls <code>delta</code> internally. You can see the code path for that in the contract function here: </p>
<p><a rel="nofollow" href="https://github.com/ITensor/ITensor/blob/v3/itensor/itdata/diag.cc#L160">https://github.com/ITensor/ITensor/blob/v3/itensor/itdata/diag.cc#L160</a></p>
<p>If you see that it is taking up more time than expected, please let us know. </p>
<p>The / operation should have a lower complexity, since the <code>delta</code> contraction you show involves making the intermediate tensor <code>delta(...) * T1</code> which will result in a dense tensor with 4 indices. There are a few things we could try to improve the second example you show, for example return a sparse result for the intermediate, or make contraction into a lazy operation so that both contractions could be "fused" together and something like / (if that is considered best) would be called.</p>
<p>-Matt</p>
http://itensor.org/support/2105/complexities-delta-tensor-multiplication-and-the-operation?show=2116#a2116Mon, 18 May 2020 20:54:56 +0000How do we properly add two IQMPO's?
http://itensor.org/support/2110/how-do-we-properly-add-two-iqmpos
<p>(I'll use the language of ITensorV2 for this question, but I don't believe my question is version specific.)</p>
<p>As discussed by <a rel="nofollow" href="https://arxiv.org/pdf/1008.3477.pdf">Schollwock</a> (pg 58 and 42), if I wish to add two MPO's, say <br>
Ha = A1 * A2 * ... *AN<br>
and<br>
Hb = B1 * B2 * ... *BN<br>
for some N-site system; then I'll need to form the direct product out of all the local tensors Ai and Bi. In other words, form a larger tensor with Ai and Bi on the diagonal: Mi = diagonal(Ai,Bi), where Ha+Hb = M1 * M2 * ... * MN. From which it follows the new tensor would have dimensions dim(Mi) = dim(Ai) + dim(Bi).</p>
<p>It's not so clear to me how one would do this if Ai and Bi are block sparse IQTensors. If LinkA and LinkB represent the sets of Link indices for A and B, then would I need to create a new set LinkM, where the dimensions of like-QN sectors are summed? What is the best way of doing this, or are there functions which already handle this?</p>
<p>I'm aware there is a function add(Ha,Hb), however, doing this fails with the complaint: </p>
<pre><code>From line 271, file itensor_operators.cc
ITensorT::operator+=: different index structure
</code></pre>
<p>In this particular run, Ha and Hb are nearly identical, and have identical quantum number. (I'm happy to share my code if that will help.)</p>
http://itensor.org/support/2110/how-do-we-properly-add-two-iqmposThu, 14 May 2020 19:50:35 +0000Answered: How to construct singlet state under QN conservation?
http://itensor.org/support/2101/how-to-construct-singlet-state-under-qn-conservation?show=2102#a2102
<p>Hi, so here is some example code below that shows you how to construct a singlet state as an ITensor. Please let me know if you are instead wanting to construct this state as an MPS.</p>
<p>Before showing the code, let me point out that in the comment you are referencing, what I said was that the state (Up+Dn) is not a state with well-defined Sz. However, the state (UpDn-DnUp) is a different state from that one, and does have a well-defined Sz of zero. So it's not correct to say that (UpDn-DnUp) does not have Sz as a good quantum number; it does.</p>
<p>The easiest way to make this state with ITensor is to obtain a set of indices corresponding to spins. I assume you are interested in spin-half (S=1/2) spins.</p>
<pre><code>auto N = 2;
auto s = SpinHalf(N,{"ConserveQNs=",true});
Print(s(1));
Print(s(2));
auto psi = ITensor(s(1),s(2));
psi.set(s(1)(1),s(2)(2), 1.0/Sqrt2);
psi.set(s(1)(2),s(2)(1), -1.0/Sqrt2);
PrintData(psi);
Print(flux(psi)); //here flux is total Sz
</code></pre>
http://itensor.org/support/2101/how-to-construct-singlet-state-under-qn-conservation?show=2102#a2102Tue, 12 May 2020 03:14:03 +0000Answered: Where can I find the documents for all classes defined in ITensor?
http://itensor.org/support/2096/where-can-find-the-documents-for-all-classes-defined-itensor?show=2100#a2100
<p>Hi, thanks for the question. I just added a documentation page for BondGate here:<br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?vers=cppv3&page=classes/bondgate">http://itensor.org/docs.cgi?vers=cppv3&page=classes/bondgate</a></p>
<p>Please let us know if there are some other docs that you need which are missing and we will try to add them if we can.</p>
<p>You can also see some helpful examples of how BondGate is used and can be used such as here:<br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?vers=cppv3&page=formulas/tevol_trotter">http://itensor.org/docs.cgi?vers=cppv3&page=formulas/tevol_trotter</a></p>
<p>Also, please note it's not strictly necessary to use the BondGate class to do gate-based / Trotter time evolution with ITensor. There's a tutorial code itensor/tutorial/05_gates/gates.cc which contains a nearly working example of doing such a time evolution method "from scratch" just using more basic ITensor functions and objects. The idea of the tutorial is that you are supposed to add the (two or three lines) of code that actually contracts each gate with the two-site wavefunction tensor, then test that it works. If you need help with the solution for that please just ask in a comment below.</p>
<p>Also if you want to post the code you are trying to make using BondGate, and have questions about that, feel free to post that too.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/2096/where-can-find-the-documents-for-all-classes-defined-itensor?show=2100#a2100Mon, 11 May 2020 19:11:10 +0000Answered: Issue with Linux (Ubuntu 16.04) install of Itensor V3
http://itensor.org/support/2071/issue-with-linux-ubuntu-16-04-install-of-itensor-v3?show=2098#a2098
<p>(Answer is in the comments).</p>
http://itensor.org/support/2071/issue-with-linux-ubuntu-16-04-install-of-itensor-v3?show=2098#a2098Mon, 11 May 2020 16:18:24 +0000Project MPS into inversion-symmetry subspace.
http://itensor.org/support/2089/project-mps-into-inversion-symmetry-subspace
<p>By inversion-symmetry I mean the exchange of lattice indices @@c<em>i\to c</em>{ -i}@@. I need to project the state into the subspace with +1 (or -1) eigenvalue of inversion symmetry, how can I do that in MPS language? Thanks in advance.</p>
http://itensor.org/support/2089/project-mps-into-inversion-symmetry-subspaceFri, 08 May 2020 21:05:08 +0000Eigenvalues of Transfer Operator in iDMRG
http://itensor.org/support/2087/eigenvalues-of-transfer-operator-in-idmrg
<p>Hi Miles,</p>
<p>I am trying to look at dynamical quantum phase transitions (DQPTs) in a particular model by numerically finding Fisher zero lines @@z \in \mathcal{C} @@ such that @@\langle \psi (0) | \psi (z) \rangle = 0@@, where @@ | \psi (z) \rangle := e^{zH} | \psi (0) \rangle@@. </p>
<p>I would like to work directly in the thermodynamic limit using iDMRG code based on <a rel="nofollow" href="https://github.com/ITensor/ITensor/blob/v2/sample/idmrg.cc">this example</a>, and identify Fisher zeros based on crossings in the eigenspectrum of the Transfer Matrix. How would I compute the transfer matrix of two MPS and obtain its eigenvalues, similarly to <a rel="nofollow" href="https://tenpy.github.io/reference/tenpy.networks.mps.TransferMatrix.html">what is done</a> in TenPy?</p>
<p>Also, are there any subtleties I need to be aware of when performing real and imaginary time evolution of iMPS in ITensor, or can I use the same functionality as for generic MPS?</p>
<p>Thanks so much for your help!</p>
http://itensor.org/support/2087/eigenvalues-of-transfer-operator-in-idmrgFri, 08 May 2020 19:32:31 +0000Answered: How do we properly handle quantum number for a system of spin-half moments?
http://itensor.org/support/2083/properly-handle-quantum-number-for-system-spin-half-moments?show=2085#a2085
<p>Hi, these are good questions. Glad you are working through this example, as it's very instructive about the structure of QN-conserving MPOs. First of all, please note that some of the choices in this code and MPO convention are not unique, but only up to gauge transformations. However, a lot of the choices are natural and reasonable for reasons we could get into after further discussion.</p>
<p>The broadest context here is that this is an MPO which is symmetry-preserving, so in the parlance of ITensor has net zero QN flux. We find for such MPOs, it's most natural to further require every MPO tensor individually to have zero flux too, just to set a clear convention. So that's the convention used here, which I think you already know.</p>
<p>To answer your first question, yes, the QN-flux of the S+ operator for the case of S=1/2 is equal to +2. Similarly the QN-flux of S- is -2. These fluxes are given in "ITensor units", where as you know +1 (ITensor) corresponds to +1/2 (physical) and +2 (ITensor) to +1 (physical) etc, </p>
<p>So because the S+ operator has net +2 flux, the MPO bond connecting it to the S- operator, which by convention points Out, or away from the S+ operator when making the S+ S- term, carries -2 flux. This makes all of the tensor net flux zero for those blocks.</p>
<p>Similarly for the case of S- S+ the MPO bond will carry +2 flux.</p>
<p>The other 0-flux sector of the MPO bond indices is for cases like the Sz Sz terms or for all identity operators to the right or left.</p>
<p>To your second question, regarding the dimensions. This just comes from the particular MPO (in this case a Hamiltonian) which is being made, and how many different types of terms. Roughly speaking, when not using additional compression tricks, the dimension of an MPO for a Hamiltonian with T different kinds of terms is T+2. So here T=3 (Sz Sz, S+ S-, S- S+). The +2 part in the T+2 within the MPO corresponds to the cases where there are identity operators either to the left (i.e. we haven't put down any non-trivial operators yet) or to the right (we are done placing all operators). </p>
<p>Finally, to your question, the dimension come from how many different terms carry the same QN flux across a bond. The two identity-string cases plus the Sz Sz terms all carry zero flux, so that's 3 different settings of the bond in the zero-flux sector. The remaining two cases are S+ S- (1 case in the -2 sector, so dimension of 1 there) and S- S+ (1 case in the +2 sector, so a dimension of 1 there also).</p>
<p>Hope that helps!</p>
<p>Miles</p>
http://itensor.org/support/2083/properly-handle-quantum-number-for-system-spin-half-moments?show=2085#a2085Fri, 08 May 2020 18:38:32 +0000Answered: TDVP not working with itensor 3.1.2
http://itensor.org/support/2080/tdvp-not-working-with-itensor-3-1-2?show=2081#a2081
<p>Hi Raffaele,<br>
Thanks for catching this. I know the change to ITensor which is causing this bug, but didn't expect that the change would break the TDVP code. Could you please provide a minimal example to reproduce? Then I'll be better able to identify and fix the case which is breaking - thanks.</p>
<p>Miles</p>
http://itensor.org/support/2080/tdvp-not-working-with-itensor-3-1-2?show=2081#a2081Fri, 08 May 2020 15:46:51 +0000Answered: Products of 2-site and 4-site wavefunctions
http://itensor.org/support/2072/products-of-2-site-and-4-site-wavefunctions?show=2079#a2079
<p>Hi, regarding the two parts of your question, let me answer them in reverse order:</p>
<p>(2) for the second part of your question, regarding tetramers, the main issue with the code you tried is that you are making tensors with 4 indices (which is fine) but then just splitting them into <em>two</em> pieces using the SVD (two, not counting the singular values, which you could multiply into either U or V). To end up with a proper MPS that you can use, each MPS tensor has to carry only <em>one</em> site index. But the code you wrote would result in some tensors of psi carrying three site indices, while others carry just one.</p>
<p>What I'd recommend is that you draw out, using tensor diagrams, what each part of the tetramer code above is doing and I think you'll see what I mean.</p>
<p>The solution to making tetramers is to keep going past the code you wrote by iterating the SVD step. Take the singular values "D" and multiply them into "V" (which you have stored into psi.ref(n+1). Next call the svd function on D*V, splitting off the second site index of that tetramer. Then finally split the third and fourth site indices apart with one more SVD. Throughout this process, you can use the ITensor function "commonindex" to get the newly created "Link" indices made by previous calls to svd, which you will need to pass as the "row" indices to the SVD function (using our new SVD interface, which would be better for this purpose).</p>
<p>(1) regarding setting a wavefunction all up, the answer is sort of similar to making dimers. The code you showed does, I think, make tensors which carry two site indices, whereas an MPS has to have tensors carrying only one site index each. Again, please diagram out what your code is doing and you should see where it's going wrong, in terms of resulting in a set of tensors you are putting into "psi" which do not have a proper MPS structure.</p>
<p>Hope that helps -</p>
<p>Miles</p>
http://itensor.org/support/2072/products-of-2-site-and-4-site-wavefunctions?show=2079#a2079Thu, 07 May 2020 20:10:34 +0000Answered: Compare ground state overlap of DMRG "psi" with ED ground state.
http://itensor.org/support/2068/compare-ground-state-overlap-of-dmrg-psi-with-ed-ground-state?show=2069#a2069
<p>Hi, good question. Here's a sample code that can do this for you where I chose the case of four sites generated like auto sites = SpinHalf(4);. In the code below, psi is an MPS which could be from a DMRG calculation, say:</p>
<pre><code>auto T = ITensor(1.0);
for(auto j : range1(N))
{
T *= psi(j);
}
auto P = permute(T,sites(1),sites(2),sites(3),sites(4));
Print(P);
for(auto n1 : range1(sites(1)))
for(auto n2 : range1(sites(2)))
for(auto n3 : range1(sites(3)))
for(auto n4 : range1(sites(4)))
{
printfln("%d %d %d %d %.12f",n1,n2,n3,n4,P.elt(n1,n2,n3,n4));
}
</code></pre>
<p>Does the above code do what you are looking for?</p>
http://itensor.org/support/2068/compare-ground-state-overlap-of-dmrg-psi-with-ed-ground-state?show=2069#a2069Wed, 06 May 2020 18:32:04 +0000Answered: Error in excited states code
http://itensor.org/support/1911/error-in-excited-states-code?show=2064#a2064
<p>Hello Miles,</p>
<p>I have the same issue when running the code in <a rel="nofollow" href="https://www.itensor.org/docs.cgi?vers=cppv3&page=formulas/excited_dmrg">https://www.itensor.org/docs.cgi?vers=cppv3&page=formulas/excited_dmrg</a></p>
<p>The error : `From line 1604, file itensor.cc</p>
<p>div(ITensor) not defined for non QN conserving ITensor</p>
<p>div(ITensor) not defined for non QN conserving ITensor<br>
make: *** [Makefile:33: build] Aborted `</p>
<p>I use itensor v3 and run 'make' in the folder '..\itensor\My_programs'</p>
<p>The error occur when I add line <code>auto [en1,psi1] = dmrg(H,wfs,randomMPS(sites),sweeps,{"Quiet=",true,"Weight=",20.0});</code></p>
<p>Thank you in advance.</p>
http://itensor.org/support/1911/error-in-excited-states-code?show=2064#a2064Tue, 05 May 2020 11:24:47 +0000Answered: Sparsity of Input Tensors in /sample/hubbard_2d.cc or dmrg.cc with ConserveQNs Enabled
http://itensor.org/support/2055/sparsity-input-tensors-sample-hubbard_2d-conserveqns-enabled?show=2058#a2058
<p>Hello,</p>
<p>For a single ITensor with QNs, you can use the function <code>nnz</code> to get the number of nonzero elements. For example:</p>
<pre><code>auto i = Index(QN(0), 2, QN(1), 2);
auto A = randomITensor(QN(), i, prime(dag(i)));
PrintData(nnz(A)); // 8
PrintData(dim(inds(A))); // 16
</code></pre>
<p>Here, <code>dim(inds(A))</code> gets the total number of elements the ITensor could have, if it was dense, so the sparsity is <code>nnz(A)/dim(inds(A))</code>.</p>
<p>You can use these on individual ITensors of the MPO or MPS in the DMRG calculation.</p>
<p>-Matt</p>
http://itensor.org/support/2055/sparsity-input-tensors-sample-hubbard_2d-conserveqns-enabled?show=2058#a2058Mon, 04 May 2020 14:11:09 +0000Answered: Input size of the DMRG and Hubbards
http://itensor.org/support/2056/input-size-of-the-dmrg-and-hubbards?show=2057#a2057
<p>Answers of Miles:</p>
<p>Yes you certainly can change N because those are just examples. As far as the question of whether it makes sense, I could interpret that question in a few different ways:</p>
<p>increasing N, or Nx,Ny will definitely make the program use more time and memory. For a 1d calculation, increasing N will have a linear cost, so not too bad, though if N is 100,000 then the cost will be 1000 times what it is now, which could be many hours or even days. For a 2d calculation, increasing Nx has a similar cost, but increasing Ny will impose an exponential cost, so you won't be able to increase it much beyond about Ny = 10 without running out of memory or computer time.</p>
<p>in terms of whether it makes sense physically to increase N that much, usually it does not. Often you can determine the bulk behavior of most lattice models on systems of linear dimension about 100 at most, and even much smaller. The reason is that for gapped systems, the correlation length is often about 10 lattice sites or less, except very close to critical points. At or near a critical point or gapless phase, it can make sense to study larger systems because of the slow, power-law scaling of correlations and strong boundary effects, but even here one can often extract a lot of information on smaller systems by doing detailed scaling analyses and extrapolations.</p>
<p>It's a very general question and answer, and a more specific answer depends on the system you are studying and what physical property you are measuring. Always see what you can get out of studying smaller systems before going to larger systems, of course.</p>
http://itensor.org/support/2056/input-size-of-the-dmrg-and-hubbards?show=2057#a2057Sun, 03 May 2020 18:09:19 +0000Answered: What governs runtime and memory usage of "H = MPO(ampo,sites)"?
http://itensor.org/support/2051/what-governs-runtime-and-memory-usage-of-h-mpo-ampo-sites?show=2054#a2054
<p>Hi, thanks for this question. Also congrats on asking what I think is the first Julia-related question on this forum! </p>
<p>Your question is a good one, about what sort of inputs work well with AutoMPO or not. Without going far into the details of the algorithm, the main steps of it are:<br>
(1) collect and sort terms (meaning sort each term in site order)<br>
(2a) create an uncompressed, sparse version of the MPO<br>
(2b) create a matrix at each bond which contains the coefficients weighting each operator string to the left and right of that bond (note that these matrices are highly redundant, and are not MPO matrices<br>
(3) SVD all of the matrices in (2b), and truncate singular values which are zero. Use the truncated U and V^\dagger matrices to compress the "big", uncompressed sparse MPO from (2a)</p>
<p>So I believe the bottleneck you are hitting comes from either (2a) or (3). I'd have to do profiling to see. There are two hypothetical improvements we could do:<br>
(2a+) don't make the full uncompressed MPO all at once, even in a sparse form<br>
(3) don't make uncompressed matrices with all of the coefficients<br>
What I mean here loosely is that there's a different way of coding the AutoMPO algorithm which builds the (2b) matrices on some bond j already in the compressed basis of bond j-1. </p>
<p>Anyway, you can see that it's technical, and right now I can't guarantee that I know how to do the above improvements in a general way and that they will work.</p>
<p>Unfortunately, this means your input is currently outside of the design scope of AutoMPO. But I appreciate you filing an issue, because if there was some change in recent versions which we can revert which at least alleviates your issue we'll see if we can find it.</p>
<p>But I think your best bet is actually this: for highly unusual and non-local Hamiltonians, it's really best to invest in hand-crafting an MPO. A few years ago I was working on quantum chemistry DMRG calculations, which also involve highly non-local terms, and had to make custom MPOs quite often. So it's necessary for such challenging cases until we can make AutoMPO an even more general solution. (Though I'm sure people will still continue to find cases it can't quite handle!)</p>
<p>It's great that you are using ITensor to study interesting systems outside of the usual condensed matter setting. Again, we'll keep your issue open and try to at least alleviate the memory usage and ultimately later on devise a better-scaling algorithm, though it's sort of an open area of algorithm research for us still.</p>
<p>Best,<br>
Miles</p>
http://itensor.org/support/2051/what-governs-runtime-and-memory-usage-of-h-mpo-ampo-sites?show=2054#a2054Fri, 01 May 2020 15:30:08 +0000DMRGpy installation
http://itensor.org/support/2052/dmrgpy-installation
<p>Hello,<br>
I have a question concerning the DMRGpy library installation <a rel="nofollow" href="https://github.com/joselado/dmrgpy">https://github.com/joselado/dmrgpy</a></p>
<ol>
<li>I use Windows10 and installed Itensor via Cygwin64.<br>
In Anaconda Prompt I typed <code>git clone https://github.com/joselado/dmrgpy</code></li>
</ol>
<p>and <code>set DMRGROOT="C:/Users/(...)/dmrgpy/src",</code> and <br>
in python script I wrote <code>import os ; import sys ; sys.path.append(os.environ["DMRGROOT"])</code></p>
<p>I got the following error <code>ImportError: cannot import name 'spinchain' from 'dmrgpy' (unknown location)</code></p>
<p>How one can relate libraries BLAS, LAPACK to dmrgpy?</p>
<ol>
<li>Is using DMRGpy as effective as Itensor? i.e. Is any problem to be computed in Itensor can be implemented in DMRGpy as well?</li>
</ol>
<p>Sorry for the questions, however Joselado didn't replied. </p>
<p>Thank you.</p>
http://itensor.org/support/2052/dmrgpy-installationThu, 30 Apr 2020 16:55:40 +0000Answered: Has findtype been depricated?
http://itensor.org/support/2049/has-findtype-been-depricated?show=2050#a2050
<p>Hi, so in version 3 of ITensor we have replaced the type of an Index with a set of “Index tags” which are up to four short strings such as “Site” or “n=5” which can describe or label an Index. </p>
<p>The function closest to findtype in version 3 is findIndex, which is described near the bottom of the following documentation page:<br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?vers=cppv3&page=classes/itensor">http://itensor.org/docs.cgi?vers=cppv3&page=classes/itensor</a></p>
<p>Please post a comment below if you have more questions about this or Index tags in v3. </p>
<p>Miles </p>
http://itensor.org/support/2049/has-findtype-been-depricated?show=2050#a2050Thu, 30 Apr 2020 03:25:32 +0000Answered: Possible error in ITensor Library v3 - mpoalgs.cc(?)
http://itensor.org/support/2024/possible-error-in-itensor-library-v3-mpoalgs-cc?show=2046#a2046
<p>It appears that this bug is not causing errors in the code (the reported errors are unrelated, see the comments above). I'll push a fix anyway, since the code is a bit confusing as it is.</p>
http://itensor.org/support/2024/possible-error-in-itensor-library-v3-mpoalgs-cc?show=2046#a2046Tue, 28 Apr 2020 18:14:17 +0000Answered: 3-component Hubbard model
http://itensor.org/support/2030/3-component-hubbard-model?show=2033#a2033
<p>Hi Rafael,<br>
I think your idea of using more than one site in a unit cell is the right thing to do for creating multi-component / multi-band models of interacting electrons. Basically let's say you have 3 "flavors" or "labels" of electrons. Then sites 1,4,7,10 etc. are all considered (by you) to be flavor 1; sites 2,5,8, etc. flavor 2; and 3,6,9, etc. flavor 3.</p>
<p>You then just define the Hamiltonian parameters as from on paper, so like if t1 is the hopping between sites which are both flavor 1, you just have t1 go between every third site, being sites 1,4,7, (i.e. the flavor 1 sites). That is it's a 3rd neighbor hopping. Similar for a t2.</p>
<p>In contrast, a local term like a Hunds interaction would happen inside the unit cell, so like between just sites 2 and 3, then sites 5 and 6, etc. repeating that way.</p>
<p>If that's still not too clear, perhaps you could provide the specific Hamiltonian or a link to it and we could discuss more?</p>
<p>Best,<br>
Miles</p>
http://itensor.org/support/2030/3-component-hubbard-model?show=2033#a2033Mon, 27 Apr 2020 20:37:26 +0000Answered: Accessing tensor elements
http://itensor.org/support/2031/accessing-tensor-elements?show=2032#a2032
<p>Hi, thanks for the question. So the new way of getting elements of tensors in v3 is to use .elt instead of .real and .eltC instead of .cplx. But in fact, those are just renamings and have the same interface and behavior.</p>
<p>So for the particular error you are getting, I believe it's not so much a version 2 versus version 3 issue. It's probably rather that the ITensor rho doesn't have one or both of the indices I and Ip. Did you confirm by printing out rho, I, and Ip that it has exactly those indices?</p>
<p>Also, I'm not sure if you ran your code in debug mode or not, but if you do run the debug build you'll often get nicer error messages in cases like these.</p>
<p>Best,<br>
Miles</p>
http://itensor.org/support/2031/accessing-tensor-elements?show=2032#a2032Mon, 27 Apr 2020 20:33:10 +0000Answered: About parallelDMRG in version3
http://itensor.org/support/2027/about-paralleldmrg-in-version3?show=2028#a2028
<p>Hi, glad you are interested in ITensor and the parallel DMRG code.</p>
<p>Unfortunately, due to other pressing priorities, we will not have time ourselves to upgrade and test that code soon. For one thing, we are hard at work finalizing a new version of the core ITensor library in the Julia language.</p>
<p>So until we do get around to updating that code, there are a couple paths you could consider:</p>
<ol>
<li><p>are you sure you need to use parallel DMRG? How large is the system size that's necessary for your study? Are there Hamiltonian parameters you can parallelize over instead, in the sense of doing separate DMRG runs with different Hamiltonians?</p></li>
<li><p>it would be great if you would be willing to upgrade the parallel DMRG code for us, and make the new version public. We'd be happy to credit you on the website. There is a version 2 to version 3 upgrade guide which covers the major changes in the library between those versions: <a rel="nofollow" href="http://itensor.org/docs.cgi?vers=cppv3&page=upgrade2to3">http://itensor.org/docs.cgi?vers=cppv3&page=upgrade2to3</a><br>
and we could answer questions you may have about the upgrade process.</p></li>
</ol>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/2027/about-paralleldmrg-in-version3?show=2028#a2028Thu, 23 Apr 2020 19:00:08 +0000Answered: Kronecker product and thermal states
http://itensor.org/support/2013/kronecker-product-and-thermal-states?show=2016#a2016
<p>Hi Raffaele,<br>
Good question: I think the tutorial/finiteT/ancilla.cc code you referenced would be a good starting point for doing what you are asking, but for other site types.</p>
<p>That code has a portion like this:</p>
<pre><code>auto psi = MPS(sites);
for(int n = 1; n <= 2*N; n += 2)
{
auto s1 = sites(n);
auto s2 = sites(n+1);
auto wf = ITensor(s1,s2);
wf.set(s1(1),s2(2), ISqrt2);
wf.set(s1(2),s2(1), -ISqrt2);
ITensor D;
psi.ref(n) = ITensor(s1);
psi.ref(n+1) = ITensor(s2);
svd(wf,psi.ref(n),D,psi.ref(n+1));
psi.ref(n) *= D;
}
</code></pre>
<p>The main parts that would need to be generalized are:</p>
<ol>
<li><p>instead of defining a singlet state |up,dn> - |dn,up> as in the above code, you'll probably want to define some other kind of maximally entangled state. As you probably know, the ancilla/purification method doesn't depend on the precise initial state used, as long as it's maximally entangled (unitarily equivalent to a Bell-pair state, meaning up to a unitary acting on the ancilla sites). A more general state that's good to define is one where the quantum numbers of the ancilla sites are different from the ones on the physical site in such a way that the overall entangled state has well-defined total quantum numbers. And you can just make all the coefficients the same sign. For the spin case above, the resulting state would be the Sz=0 triplet state rather than the singlet state.</p></li>
<li><p>you'll need to add two additional loops inside the code, where instead of writing each wf.set line by hand, you write something like:</p>
<p>for(int n : range1(d)) <br>
{<br>
wf.set(s1(n),s2(d+1-n), 1.0);<br>
}<br>
wf /= norm(wf); //normalize to 1.0</p></li>
</ol>
<p>where above the d+1-n argument to s2 is because of the idea I mentioned in step #1 above about pairing physical-ancilla states together to make the total quantum number always the same (assuming here that your sites have the property that state n and state d+1-n together have a fixed number of particles).</p>
<p>Also note above d is the site dimension.</p>
<p>Even if d is very large, as you said is the case for you, the above code should run rather quickly. If it doesn't then you probably have a bug or we'll need to have a closer look.</p>
<p>Best,<br>
Miles</p>
http://itensor.org/support/2013/kronecker-product-and-thermal-states?show=2016#a2016Thu, 16 Apr 2020 19:02:25 +0000About Hubbard model to tJ limit
http://itensor.org/support/2012/about-hubbard-model-to-tj-limit
<p>Dear all,</p>
<p>I am using the exthubbard.cc code in the sample folder to calculate ground state of Hubbard model. My question is, if I take a very high value of U1 in exthubbard.cc, i.e. in the limit t/U1 >> 1, does this model gives results corresponding to tJ model (tJ model is the Hubbard model in large on-site interaction limit)?</p>
<p>Sincerely<br>
Sreetama</p>
http://itensor.org/support/2012/about-hubbard-model-to-tj-limitThu, 16 Apr 2020 01:36:44 +0000Answered: Sub-tensor in an ITensor
http://itensor.org/support/2006/sub-tensor-in-an-itensor?show=2009#a2009
<p>Hi Chia-Min,<br>
Thanks for the question. Basically, we don't have that feature right now, because many technicalites of C++ make it quite a lot of work to add. (And there are some design questions about ITensor itself too that we need to think through.) But tensor slicing is high on our list of features we want to add, and plan to add.</p>
<p>So for now, please do an element by element approach. In some cases, such as two-index tensors, you can also construct an ITensor from a matrix using the matrixITensor function. So this could be helpful for you. </p>
<p>If you're really stuck or find this kind of step to be a bottleneck, please let me and Matt know, and we could definitely help you craft some custom code which works on a lower layer of ITensor to help your specific case.</p>
<p>Finally, we think adding tensor slicing support will be much easier and go a lot faster in Julia, so we plan to explore it in the new ITensors.jl first.</p>
<p>Best, <br>
Miles</p>
http://itensor.org/support/2006/sub-tensor-in-an-itensor?show=2009#a2009Mon, 13 Apr 2020 21:48:08 +0000Answered: Not conserving parity in Electron sites
http://itensor.org/support/2007/not-conserving-parity-in-electron-sites?show=2008#a2008
<p>Dear Sreetama,<br>
Thanks for the questions. Please let me know if I'm missing something, but the parity as defined for that code is by definition equal to the number of particles modulo two. So if the particle number is constant or conserved, then the parity will be conserved also.</p>
<p>So I don't believe there is actually a scenario possible where particle number will be conserved but parity won't be, essentially by definition. However, if you can provide an example such as a Hamiltonian for which this is the case then I could definitely help you set up your code to handle it.</p>
<p>Also, please note that for Electron sites, the default behavior is that only particle number "Nf" is conserved, while parity is not separately conserved since it would be redundant and would not make the tensors any more sparse. So maybe that is already the behavior you want? It is the behavior you will obtain if you just make the sites as:<br>
auto sites = Electron(N);</p>
<p>Happy to discuss more -</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/2007/not-conserving-parity-in-electron-sites?show=2008#a2008Mon, 13 Apr 2020 21:13:02 +0000Answered: Guidelines for asking questions
http://itensor.org/support/2003/guidelines-for-asking-questions?show=2004#a2004
<p>Just posting this answer so the question appears with a blue badge ;^)</p>
http://itensor.org/support/2003/guidelines-for-asking-questions?show=2004#a2004Fri, 10 Apr 2020 01:00:12 +0000Answered: Conserve QN in ancilla method
http://itensor.org/support/1991/conserve-qn-in-ancilla-method?show=2000#a2000
<p>Hi, so the issue you encountered is actually not to do with QNs per se, but rather to do with a change in behavior of MPO functions in ITensor v3 (versus version 2).</p>
<p>The change in behavior is that functions such as applyMPO no longer automatically "un prime" site indices. So when acting with an MPO of the kind produced by AutoMPO which has sites s1,s2,s3... and sites s1', s2', s3',...onto an MPS, the resulting MPS psi will have primed site indices. It's necessary to call psi.noPrime(); afterward to remove the primes.</p>
<p>The ancilla.cc tutorial code you used wasn't properly upgraded to version 3, but I'll upgrade it right now. Unfortunately it was still appearing to run correctly without QN conservation because when there are no QNs, the code doesn't check Index arrows (even though it could) so certain incorrect algorithms sometimes slip through the automatic error checking.</p>
<p>In your own code, please add a line:<br>
psi.noPrime();<br>
after the call to applyMPO, and I'll do the same in that tutorial code.</p>
<p>Thanks for pointing this out -</p>
<p>Miles</p>
http://itensor.org/support/1991/conserve-qn-in-ancilla-method?show=2000#a2000Wed, 08 Apr 2020 14:59:43 +0000Answered: Using openmp timing omp_get_wtime() breaks ITensor 2 calculations
http://itensor.org/support/1977/openmp-timing-omp_get_wtime-breaks-itensor-calculations?show=1987#a1987
<p>That code is running fine for me in ITensor v2 and v3 for both 1 and 2 threads. I am using ITensor v2 and v3 compiled with MKL. What errors are you seeing?</p>
http://itensor.org/support/1977/openmp-timing-omp_get_wtime-breaks-itensor-calculations?show=1987#a1987Mon, 06 Apr 2020 19:18:49 +0000Answered: Excited states in the Hubbard model
http://itensor.org/support/1983/excited-states-in-the-hubbard-model?show=1986#a1986
<p>Hi Rafael,<br>
This is similar to a bug some other users have reported. I just patched ITensor to hopefully fix it. Could you please "git pull" the latest version of ITensor on the v3 branch, fully recompile the library, then check if your code now works as expected? Thanks!</p>
<p>Miles</p>
http://itensor.org/support/1983/excited-states-in-the-hubbard-model?show=1986#a1986Mon, 06 Apr 2020 18:31:19 +0000Answered: Error when calculating excited states (with conserved quantities)
http://itensor.org/support/1581/error-when-calculating-excited-states-conserved-quantities?show=1985#a1985
<p>Hi, sorry for the long delay on this, but I just merged a pull request that I believe fixes this bug. If you are still encountering it, or have your code above, please check that the latest v3 branch of ITensor fixes this issue. Thanks!</p>
<p><a rel="nofollow" href="https://github.com/ITensor/ITensor/pull/341">https://github.com/ITensor/ITensor/pull/341</a></p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1581/error-when-calculating-excited-states-conserved-quantities?show=1985#a1985Mon, 06 Apr 2020 18:23:25 +0000Answered: Operators with complex coefficients
http://itensor.org/support/1980/operators-with-complex-coefficients?show=1984#a1984
<p>(See answer to question in comments above)</p>
http://itensor.org/support/1980/operators-with-complex-coefficients?show=1984#a1984Mon, 06 Apr 2020 14:51:58 +0000Answered: SVD operation is too slow.
http://itensor.org/support/1978/svd-operation-is-too-slow?show=1979#a1979
<p>Good question, thanks. By default, ITensor uses a custom SVD implementation which is more reliable in general than the LAPACK implementations, which have occasionally crashed for various users. So until this is fixed we offer our custom SVD as the default.</p>
<p>But recently we added an option to call the "gesdd" and "gesvd" LAPACK methods which can be much faster (and more accurate) than ours.</p>
<p>So I would recommend you add "SVDMethod=","gesdd" to the named arguments you are passing to the svd function, and you should see much better performance. For this to work you will need to pull and compile the latest version of ITensor (v3 branch) if you haven't already.</p>
<p>Please let me know if you don't see a speedup or comparable performance to your other code which uses LAPACK! </p>
<p>Best regards,<br>
Miles</p>
<p>P.S. I just updated the documentation to list the SVDMethod option: <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></p>
http://itensor.org/support/1978/svd-operation-is-too-slow?show=1979#a1979Mon, 23 Mar 2020 17:32:22 +0000Answered: Z_4 symmetry
http://itensor.org/support/1969/z_4-symmetry?show=1976#a1976
<p>Hi, so to answer your question more definitively, I ran your code and the more technical (ITensor specific) reason for the error is that the way you have defined the operators does not lead to operators with a well-defined quantum number "flux" (i.e. the operators do not change a state by a definite QN amount, which is required of QN ITensors).</p>
<p>One case where this error is occurring is in your definition of the "Cdagup" operator. If you work through the fluxes of the two elements you are setting, they are different. One element is in a block of flux QN({3,4}) whereas the other is in a block of flux QN({1,4}). I note that you switched around the definition of the "UD" state and the "Dn" state from that of the Electron site set so that "UD" is state 3 and "Dn" is state 4. I imagine you had a good reason to try this, but I just wanted to point it out to emphasize this is important to notice when doing the flux calculation.</p>
<p>For more information on how the flux of operator blocks are defined, here is a page in the ITensor book (which I just added back to the v3 version of the book):<br>
<a rel="nofollow" href="http://itensor.org/docs.cgi?vers=cppv3&page=book/block_sparse">http://itensor.org/docs.cgi?vers=cppv3&page=book/block_sparse</a></p>
<p>Please let me know if you have any questions about the above -</p>
<p>Miles</p>
http://itensor.org/support/1969/z_4-symmetry?show=1976#a1976Sat, 14 Mar 2020 19:42:40 +0000Answered: TEBD for Holstein model
http://itensor.org/support/1958/tebd-for-holstein-model?show=1964#a1964
<p>Hi, good question. For this case (different site types), you can also use swap gates to time evolve with further-neighbor interactions. The swap gate would be defined in a straightforward / standard way, similar to a "crossed" pair of identity operators (diagrammatically it looks like two lines crossing over each other).</p>
<p>The main limitation of our existing system, however, is that the part of the code in the BondGate class that makes swap gates for you currently assumes both sites have the same dimension.</p>
<p>So until we extend our system to handle this case, I'd recommend one of these courses of action (I think #2 actually would be best!):</p>
<p>1) extend the code in itensor/mps/bondgate.h in the makeSwapGate function for your needs, i.e. to make a swap gate which is defined appropriately for two different dimension sites</p>
<p>2) rather than using swap gates at all, use a different trick, which eventually I want to make the standard approach in ITensor. This other trick is, whenever reaching a step which involves a swap "gate", to not actually use a gate at all, but just merge (contract) the two neighboring MPS tensors whose site indices are to be swapped, then SVD the merged tensor back apart so that afterward the site indices are in the reverse order. This skips the extra cost of applying a gate to the MPS and automatically works for any dimension of sites. To implement this idea #2, you'd have to modify or make your own version of the code in itensor/mps/tevol.h for the gateTEvol function, which is actually a rather simple algorithm.</p>
<p>Best regards,<br>
Miles</p>
http://itensor.org/support/1958/tebd-for-holstein-model?show=1964#a1964Tue, 10 Mar 2020 12:48:02 +0000Avoiding local minima in DMRG
http://itensor.org/support/1959/avoiding-local-minima-in-dmrg
<p>Hi,</p>
<p>I am trying to use DMRG to compute a gap between Sz=0 and Sz=1 states.<br>
My (fermionic) model is by no means intricate: a given 1D tight-binding model at half-filling with Hubbard interactions.<br>
I am sure there is a gap in my particular system, but I am getting 0.<br>
I tested several different things, so let me try to summarize my struggles:</p>
<p>1) Getting stuck in local minima (which depends on the initial state) while conserving symmetries</p>
<p>In principle, I want to converse N and Sz in this type of calculations: first, calculations are faster; second, I can get the gap by simply computing groundstates with the desired QNs. When I do that, I have to initialize my system in a state that has the QNs that I want. If I use Fock states, I can easily get stuck in local minima (as replied by Miles in <a rel="nofollow" href="http://itensor.org/support/105/sweeps-system-size-clarification-choice-intial-state-dmrg).">http://itensor.org/support/105/sweeps-system-size-clarification-choice-intial-state-dmrg).</a> I believe this is what happens in my code, even though I've tried many different initial guesses (all of them Fock states). For that reason, now I want to feed DMRG with an "arbitrary" combination of states (similarly to what is asked in <a rel="nofollow" href="http://www.itensor.org/support/1359/how-to-create-a-particular-initial-state-as-a-mps,">http://www.itensor.org/support/1359/how-to-create-a-particular-initial-state-as-a-mps,</a> <a rel="nofollow" href="http://itensor.org/support/1357/setting-random-initial-product-state,">http://itensor.org/support/1357/setting-random-initial-product-state,</a> and <a rel="nofollow" href="http://itensor.org/support/490/starting-initial-state-as-product-state-of-singlets?show=490#q490)">http://itensor.org/support/490/starting-initial-state-as-product-state-of-singlets?show=490#q490)</a> <strong>that still has the right N and Sz</strong>. However, I have not been able to create states as in the first and second links while conserving QNs (I get errors saying "Setting Tensor element non-zero would violate its symmetry"). In addition, I don't fully understand the syntax of the solution proposed in the third link to make something similar for electrons.<br>
Let me give a concrete example. Let's say that instead of starting with a Neel-like Fock state, |up,dn,up,dn,...>, I want to start with something like 1/sqrt(2)(|up>+|dn>)1/sqrt(2)(|up>-|dn>)..., which has the same N and Sz. How can I run DMRG, starting from this initial state, and still conserving N and Sz?</p>
<p>2) "ConserveQNs"==false not working properly in version v3 for electrons?</p>
<p>While I could not fix the previous issue, other option that I had in mind was to not conserve symmetries at all (which allows me to start with a randomized wave function via the "randomMPS" function) and then look for the ground state (which has Sz=0) and to excited states (until I get one with Sz=1). Since the Sz=1 can be degenerate, to explore this option I would probably need to add a Zeeman splitting term in the Hamiltonian as well. However, it looks like there is a bug in version v3 when "ConserveQNs"==false is set for electrons (I think this is acknowledged in <a rel="nofollow" href="https://github.com/ITensor/ITensor/issues/311).">https://github.com/ITensor/ITensor/issues/311).</a> For that reason, I am installing version v2 and exploring that route.</p>
<p>I believe this should be a quite common problem for people more experienced than me in DMRG calculations (I have just started). So, if someone has any other idea in mind to tackle this difficulty, please let me know. </p>
<p>Let me add that I have also played with the "noise" parameter in DMRG, but I couldn't fix my problems with that.</p>
<p>Best,<br>
Gonçalo Catarina</p>
<p>EDIT: minor modifications to my questions, before any reply, for the sake of clarity.</p>
http://itensor.org/support/1959/avoiding-local-minima-in-dmrgMon, 09 Mar 2020 12:20:52 +0000ITensor in Jupyter Notebooks
http://itensor.org/support/1955/itensor-in-jupyter-notebooks
<p>I was wondering if anyone had success getting ITensor running in Jupyter notebooks using Xeus-Cling. [I am new to Xeus-Cling, so I am undoubtedly doing something naive.] If you have any suggestions, please let me know.</p>
<p>What I did so far:<br>
- Installed Xeus-Cling using conda<br>
- Compiled Itensor, using the flag: ITENSOR<em>MAKE</em>DYLIB=1</p>
<p>I start up a notebook, and run:</p>
<pre><code>#pragma cling add_include_path("/Users/emueller/Itensor3Clean/itensor")
#pragma cling add_library_path("/Users/emueller/Itensor3Clean/itensor/lib")
#include "itensor/index.h"
</code></pre>
<p>Everything works fine, I can create and manipulate index objects.</p>
<p>The problem comes when I try to include some of the other header files. For example:</p>
<pre><code>#include "itensor/itensor.h"
</code></pre>
<p>yields an error (quoted below so as not not mess up the flow of the question) -- along with the errors that I get when I try to include a few other headers.</p>
<p>In case it matters, I am using Mac OSX 10.14.6, Cling 0.6, Xeus 0.23.3. ITensor 3.0. </p>
<p>ITensor works great for me when run in the regular way (compiling and linking using Clang). I think that getting it running in a Jupyter notebook would be great for teaching, and also make for a good development workflow (at least for me). </p>
<p>Erich</p>
<p>Sample include's, and the error messages:</p>
<pre><code>#include "itensor/itensor.h"
</code></pre>
<p>yeilds</p>
<p>In file included from input<em>line</em>1:1:<br>
In file included from /Users/emueller/anaconda/envs/cling/include/c++/v1/new:90:<br>
In file included from /Users/emueller/anaconda/envs/cling/include/c++/v1/exception:80:<br>
In file included from /Users/emueller/anaconda/envs/cling/include/c++/v1/cstddef:110:<br>
/Users/emueller/anaconda/envs/cling/include/c++/v1/type<em>traits:1078:75: error: no member named 'value' in 'std::<strong>1::integral_constant<bool, true>'<br>
_IsNotSame<decltype(</strong>is</em>referenceable_impl::__test<_Tp>(0)), __two>::va...</p>
<p>and so on...</p>
<pre><code>#include "itensor/util/readwrite.h"
</code></pre>
<p>yields</p>
<p>In file included from input<em>line</em>37:1:<br>
In file included from /Users/emueller/Itensor3Clean/itensor/itensor/util/readwrite.h:19:<br>
In file included from /Users/emueller/anaconda/envs/cling/include/c++/v1/fstream:188:<br>
/Users/emueller/anaconda/envs/cling/include/c++/v1/filesystem:852:13: error: no viable overloaded '+='<br>
__pn_ += preferred_separator;</p>
<p>and so on...</p>
<pre><code> #include "itensor/tensor/lapack_wrap.h"
</code></pre>
<p>yields</p>
<p>In file included from input<em>line</em>39:1:<br>
In file included from /Users/emueller/Itensor3Clean/itensor/itensor/tensor/lapack<em>wrap.h:84:<br>
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs<br>
/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework/Headers/Accelerate.h:20:<br>
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs<br>
/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework/Headers/../Frameworks/vecLib.framework/Headers/vecLib.h:64:<br>
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs<br>
/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Headers/Sparse/Solve.h:4462:<br>
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs<br>
/MacOSX.sdk/System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Headers/Sparse/SolveImplementation.h:53:<br>
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs<br>
/MacOSX.sdk/usr/include/os/log.h:14:<br>
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs<br>
/MacOSX.sdk/usr/include/os/trace.h:8:<br>
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs<br>
/MacOSX.sdk/usr/include/os/trace</em>base.h:95:27: error: expected unqualified-id<br>
extern struct mach_header __dso_handle;</p>
<p>and so on...</p>
http://itensor.org/support/1955/itensor-in-jupyter-notebooksMon, 02 Mar 2020 19:25:19 +0000Answered: Computing entanglement in an block of arbitrary size
http://itensor.org/support/1952/computing-entanglement-in-an-block-of-arbitrary-size?show=1954#a1954
<p>Hi Rafael,</p>
<p>the following method works for me: I set up the RDM of the subsystem as it is described in <a rel="nofollow" href="https://arxiv.org/abs/1605.00674">https://arxiv.org/abs/1605.00674</a> ( see Fig. 6 ). Once I have obtained the RDM, i use diagHermitian to obtain the spectrum and from that the entanglement entropy. </p>
<p>All the best,<br>
Matthias</p>
http://itensor.org/support/1952/computing-entanglement-in-an-block-of-arbitrary-size?show=1954#a1954Fri, 28 Feb 2020 08:16:06 +0000Answered: AutoMPO with products of three/four terms operators
http://itensor.org/support/1944/autompo-with-products-of-three-four-terms-operators?show=1951#a1951
<p>(This question was answered in the above comments thread.)</p>
http://itensor.org/support/1944/autompo-with-products-of-three-four-terms-operators?show=1951#a1951Fri, 21 Feb 2020 22:20:49 +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 +0000