- Comp-phys-alps-users - lists.phys.ethz.ch

Re: [ALPS-users] parameter t' does not seem to work
by yulian chen 22 Oct '18

22 Oct '18

OK. Here's my python script: ---------------------------------------- import pyalps parms = [ { 'LATTICE' : "2 band sublattice open chain lattice", 'MODEL' : "boson Hubbard", 'CONSERVED_QUANTUMNUMBERS' : 'N', 'T' : 0, 't0' : 5, 't1' : 1, 'SWEEPS' : 30, 'NUMBER_EIGENVALUES' : 1, 'L' : 4, 'Nmax' : 1, 'MAXSTATES' : 300, 'N_total' : 2, 'MEASURE_LOCAL[n]' : 'n' } ] input_file = pyalps.writeInputFiles('ssh',parms) res = pyalps.runApplication('dmrg',input_file,writexml=True) ----------------------------------------- p.s. Since t' is a string literal, I changed it to t1. And I made the same change in my Model XML File. So it doesn't matter. (I used the command line until you taught me to check the lattice. And t' is supported in the command line tool. Now I can run the simulations using python.) Is there anything wrong in the python script? Thanks, Yulian

2 1

Re: [ALPS-users] parameter t' does not seem to work
by yulian chen 22 Oct '18

22 Oct '18

Hello Rongyang, Thank you again. With your help, I have checked the graph generated from my lattice definition and corrected my Lattice XML File. But I have a follow-up question that the tunneling rate t' of the second type bond term does not work. I can run the simulation without any bug indicated. Then I found the ground energy is the same as when I used the "open chain lattice" with a single tunneling rates t. Next, I deleted the t' in my Parameter XML File. I ran the calculation again and the ground energy I got was still the same. I have read the tutorials on ALPS WIKI about the definition of the models. It is said that 'If the lattice contains more than one site per unit-cell, the <BASIS> command should contain one <SITEBASIS> entry for each site of the unit-cell. Each entry should have a different Type, corresponding to the definitions given in the lattice library file.' ( http://alps.comp-phys.org/mediawiki/index.php/Tutorials:ModelHOWTO) There is only one type of <SITEBASIS> in my Model XML File. Is this the source of the problem? -----------------------Model XML File-------------------------- <MODELS> <SITEBASIS name="boson"> <PARAMETER name="Nmax" default="infinity"/> <QUANTUMNUMBER name="N" min="0" max="Nmax"/> <OPERATOR name="bdag" matrixelement="sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="b" matrixelement="sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR> <OPERATOR name="n" matrixelement="N"/> </SITEBASIS> <BASIS name="boson"> <SITEBASIS ref="boson"/> <CONSTRAINT quantumnumber="N" value="N_total/2"/> </BASIS> <SITEOPERATOR name="double_occupancy" site="x"> n(x)*(n(x)-1)/2 </SITEOPERATOR> <BONDOPERATOR name="boson_hop" source="x" target="y"> bdag(x)*b(y)+bdag(y)*b(x) </BONDOPERATOR> <HAMILTONIAN name="boson Hubbard"> <PARAMETER name="mu" default="0"/> <PARAMETER name="t" default="1"/> <PARAMETER name="t'" default="1"/> <PARAMETER name="U" default="0"/> <PARAMETER name="V" default="0"/> <BASIS ref="boson"/> <SITETERM site="i"> <PARAMETER name="mu#" default="mu"/> <PARAMETER name="U#" default="U"/> -mu#*n(i)+U#*n(i)*(n(i)-1)/2 </SITETERM> <BONDTERM type="0" source="i" target="j"> -t*boson_hop(i,j) </BONDTERM> <BONDTERM type="1" source="i" target="j"> -t'*boson_hop(i,j) </BONDTERM> </HAMILTONIAN> </MODELS> ---------------------END----------------------------- Is there anything wrong with my Model XML File? How can I solve this problem? Best, Yulian

2 1

Re: [ALPS-users] parameter t' does not seem to work
by cyl119zj 22 Oct '18

22 Oct '18

1 0

The way I sucessfully defined Spin 1/2 Sy operator in ALPS MPS calculations and some talks
by adfws 22 Oct '18

22 Oct '18

Hi everyone, Now I'm going to share a way I found to define Sy operator in ALPS MPS calculation to inspire further justifications about it. First why it's hard to define Sy operators in ALPS MPS calculations? Because there are 2 obstacles you will face to define and use Sy site operator: When you want to directly measure something about Sy like Sy and Sy:Sy correlations, you enable COMPLEX to 1 so that you can use I in models xml file. Then you define site operator Sy like this: <SITEOPERATOR name="Sy" site="x"> I/2*(Sminus(x)-Splus(x)) </SITEOPERATOR> However this will not work in ALPS MPS, you get wrong result when measuring local Sy and get exceptions when you measure correlations like Sy:Sy. There are 2 obstacles. One is that mps_optim's local operator measurement code has a real bug that would lead to wrong measurement results: MPS measurement part would form the wrong local operator to be measured. For example, when you measure Sy. Since Sy is built in SITEOPERATOR as I/2*(Sminus(x)-Splus(x)), the bug is that MPS actually measure Sminus(x)+Splus(x) with all number multipliers before Sminus(x) and Splus(x) unexpectedly set to 1. It measures the wrong operator so it gives you wrong measurement result. The detailed tests are here : https://gitee.com/whitesnow1970/learn-Python-in-alps/blob/master/share/The_… In order to bypass this bug, the resolution is defining number multipliers as operators: <OPERATOR name="half_I" matrixelement="I/2"/> <OPERATOR name="half" matrixelement="1/2"/> and define your Sy like: <SITEOPERATOR name="Sy" site="x"> minus_half_I(x)*Splus(x)+half_I(x)*Sminus(x) </SITEOPERATOR> Now all multipliers are 1, who cares you later set it to1? This is justified in my spin 1/2 <Sy> measurements tests. My local Sy measurements results were right. The second obstacle is not a bug but a restriction. When you measure correlations like Sy:Sy, where Sy is defined in SITEOPERATOR by sums. MPS measurement stops you from measure correlation Sy:Sy and says you have sums in Sy definition. The stopping information is: Cannot measure sum of terms in LOCAL_AT and CORRELATIONS My resolution is not a standard way so require further justification, it is implemented as follows: Make a repeated definition of Sy in front of Sy's SITEOPERATOR definition with matrix elements. Since in principle you cannot define Sy by matrix elements because it doesn't change Sz quantum number by simply one line. This is a dummy definition, which is assumed to be overwritten by later definition. First define: <OPERATOR name="Sy" matrixelement="I/2"> <CHANGE quantumnumber="Sz" change="-1"/> </OPERATOR> Later define: <SITEOPERATOR name="Sy" site="x"> minus_half_I(x)*Splus(x)+half_I(x)*Sminus(x) </SITEOPERATOR> Where minus_half_I(x) is c*identity operator as mentioned above. I assume later definition covers the former one and I found by doing that MPS will not stop you any longer from measuring Sy:Sy by " Cannot measure sum of terms in LOCAL_AT and CORRELATIONS" exceptions. This is the fact I rely on to bypass this obstacle. In my tests, the Sy:Sy correlation matrix in my spin 1/2 calculation was also right. With this final definition of Sy, you can both bypass the local operator measurement bug in MPS and the restriction of sums when you want a summed local operator to be in MPS correlation measurements. In ALPS DMRG both are unnecessary, just use my original definition is fine. But in mps_optim you have to do this in order to directly measure Sy. I think ALPS MPS is not as polished as developed ALPS DMRG, this is the reason it possesses such limitations. My resolution above can bypass such limitation if one cannot code C++ and modify the open-sourced code. However, it needs further justification because redefinition of operator isn't a standard way in ALPS. (My model xml file: https://gitee.com/whitesnow1970/learn-Python-in-alps/blob/master/share/HSy.…) So how much did I tested? For spin 1/2. I used mps_optim to get ground statesof H=+-I/2*(Sminus(i)-Splus(i)). So the ground states are two eigenstates of Sy with eigenvalue +-0.5. I measure my built "Sy" for these two states, both for <"Sy"> and <"Sy"*"Sy"> to get expectation value of "Sy" and "Sy"'s uncertainty. If uncertainty vanishes I will conclude the state is an eigenstate of "Sy" with eigenvalue <"Sy">. My result showed that "Sy" have the identical eigenstates and eigenvalues with Sy=I/2*(Sminus(i)-Splus(i)). So in spin 1/2 space "Sy"=Sy. However I didn't try this for spin 1 yet because my way seems not that global for all spin lengths. Finally, this is a nice start to use Sy operator in ALPS MPS. Otherwise you will have to break everything into Sz,Splus,Sminus and cannot measure Sy directly. This gets more unconvenient when one measure correlations like Sy:Sy. Welcome to further talks and tests about it~ ( -'`-) LiuBiao ll070616(a)126.com

1 0

Re: [ALPS-users] Sy operator
by Synge Todo 22 Oct '18

22 Oct '18

Unfortunately, the current version of Looper does not support models with complex matrix elements... Best, Synge > 2018/10/19 4:02、galeskis <galeskis(a)phys.ethz.ch>のメール: > > I was trying to use the looper algorithm, would this work? The Sx works fine and they should be equivalent... > > > > Sent from my Samsung Galaxy smartphone. > > -------- Original message -------- > From: jmm <mauricio.matera(a)gmail.com> > Date: 18/10/2018 18:47 (GMT+01:00) > To: comp-phys-alps-users(a)lists.phys.ethz.ch > Subject: Re: [ALPS-users] Sy operator > > You must be surge that your simulation is handling complex values... > > > M > > El jue., 18 oct. 2018 13:28, Stanislaw Galeski <galeskis(a)phys.ethz.ch> escribió: > Dear All, > > I am struggling to define the Sy operator in my Hamiltonian. For the > 'Spin' hamiltonian the Sx operator is defined as > > <SITEOPERATOR name="Sx" site="x"> > 1/2*(Splus(x)+Sminus(x)) > </SITEOPERATOR> > > however when i attempted defining Sy in a similar manner: > > <SITEOPERATOR name="Sy" site="x"> > 1j/2*(Splus(x)-Sminus(x)) > </SITEOPERATOR> > > the simulations halt without producing any output. Could you point me > how to implement the Sy operator properly and where am i making a > mistake? > > In the long run I am attempting to apply two different fields in the XY > plane, GammaX along x and GammaY along y > > Kind regards, > Stan > > > ---- > Comp-phys-alps-users Mailing List for the ALPS Project > http://alps.comp-phys.org/ > > List info: https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users > Archive: https://lists.phys.ethz.ch//pipermail/comp-phys-alps-users > > Unsubscribe by writing a mail to comp-phys-alps-users-leave(a)lists.phys.ethz.ch. > > > ---- > Comp-phys-alps-users Mailing List for the ALPS Project > http://alps.comp-phys.org/ > > List info: https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users > Archive: https://lists.phys.ethz.ch//pipermail/comp-phys-alps-users > > Unsubscribe by writing a mail to comp-phys-alps-users-leave(a)lists.phys.ethz.ch.

1 0

parameter t' does not seem to work
by yulian chen 22 Oct '18

22 Oct '18

Dear all, I was trying to run a simulation on the one-dimensional Bose-Hubbarad with alternating tunneling rates t1 and t2, which is the bosonic analogue of the Su-Schrieffer-Heeger(SSH) model. The lattice with one unit cell is made of A and B sites. So there are two types of edges defined in the unicell: ------------------------------- <UNITCELL name="sublattice1d" dimension="1"> <VERTEX type="0"/> <VERTEX type="1"/> <EDGE type="0"><SOURCE vertex="1" offset="0"/><TARGET vertex="2" offset="0"/></EDGE> <EDGE type="1"><SOURCE vertex="2" offset="0"/><TARGET vertex="1" offset="1"/></EDGE> </UNITCELL> ------------------------------- Then I run a DMRG calculation. But I found that the results are the same as when I used the "open chain lattice" with a single tunneling rates t. The parameter t' does not seem to work. I think it should be something wrong with my Model XML File. I have read one posting said that the number of types of bond operators should be equal to the number of types of edges defined in the unitcell. Is there anything wrong with my Model XML File? Is my bond operator wrong? My Model XML File is: ------------------------------- <MODELS> <SITEBASIS name="boson"> <PARAMETER name="Nmax" default="infinity"/> <QUANTUMNUMBER name="N" min="0" max="Nmax"/> <OPERATOR name="bdag" matrixelement="sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="b" matrixelement="sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR> <OPERATOR name="n" matrixelement="N"/> </SITEBASIS> <BASIS name="boson"> <SITEBASIS ref="boson"/> <CONSTRAINT quantumnumber="N" value="N_total"/> </BASIS> <SITEOPERATOR name="double_occupancy" site="x"> n(x)*(n(x)-1)/2 </SITEOPERATOR> <BONDOPERATOR name="boson_hop" source="x" target="y"> bdag(x)*b(y)+bdag(y)*b(x) </BONDOPERATOR> <HAMILTONIAN name="boson Hubbard"> <PARAMETER name="mu" default="0"/> <PARAMETER name="t" default="1"/> <PARAMETER name="t'" default="1"/> <PARAMETER name="U" default="0"/> <PARAMETER name="V" default="0"/> <BASIS ref="boson"/> <SITETERM site="i"> <PARAMETER name="mu#" default="mu"/> <PARAMETER name="U#" default="U"/> -mu#*n(i)+U#*n(i)*(n(i)-1)/2 </SITETERM> <BONDTERM type="0" source="i" target="j"> -t*boson_hop(i,j) </BONDTERM> <BONDTERM type="1" source="i" target="j"> -t'*boson_hop(i,j) </BONDTERM> </HAMILTONIAN> </MODELS> ------------------------------- What should I do to solve the problem that parameter t' does not seem to work? Thanks, Yulian Chen

2 1

Sy operator
by Stanislaw Galeski 18 Oct '18

18 Oct '18

Dear All, I am struggling to define the Sy operator in my Hamiltonian. For the 'Spin' hamiltonian the Sx operator is defined as <SITEOPERATOR name="Sx" site="x"> 1/2*(Splus(x)+Sminus(x)) </SITEOPERATOR> however when i attempted defining Sy in a similar manner: <SITEOPERATOR name="Sy" site="x"> 1j/2*(Splus(x)-Sminus(x)) </SITEOPERATOR> the simulations halt without producing any output. Could you point me how to implement the Sy operator properly and where am i making a mistake? In the long run I am attempting to apply two different fields in the XY plane, GammaX along x and GammaY along y Kind regards, Stan

3 2

How to define the superlattice Bose-Hubbard model?
by yulian chen 18 Oct '18

18 Oct '18

Hello everybody, I was trying to run a simulation on the one-dimensional superlattice Bose-Hubbarad with alternating tunneling rates t1 and t2, which is the bosonic analogue of the Su-Schrieffer-Heeger(SSH) model. The lattice with one unit cell is made of A and B sites. To this end, I have adaped the following unit-cell: <UNITCELL name="sublattice1d" dimension="1"> <VERTEX type="0"/> <VERTEX type="1"/> <EDGE type="0"><SOURCE vertex="1" offset="0"/><TARGET vertex="2" offset="0"/></EDGE> <EDGE type="1"><SOURCE vertex="2" offset="0"/><TARGET vertex="1" offset="1"/></EDGE> <EDGE type="0"><SOURCE vertex="1" offset="1"/><TARGET vertex="2" offset="1"/></EDGE> </UNITCELL> This enters into the lattice graph: <LATTICEGRAPH name = "2 band sublattice open chain lattice"> <FINITELATTICE> <LATTICE ref="chain lattice"/> <EXTENT dimension="1" size ="L"/> <BOUNDARY type="open"/> </FINITELATTICE> <UNITCELL ref="sublattice1d"/> </LATTICEGRAPH> And the Hamiltonian: <HAMILTONIAN name="boson Hubbard"> <PARAMETER name="mu" default="0"/> <PARAMETER name="hop" default="1"/> <PARAMETER name="hop'" default="1"/> <PARAMETER name="U" default="0"/> <BASIS ref="boson"/> <SITETERM site="i"> <PARAMETER name="mu#" default="mu"/> <PARAMETER name="U#" default="U"/> -mu#*n(i)+U#*n(i)*(n(i)-1)/2 </SITETERM> <BONDTERM type="0" source="i" target="j"> -hop*boson_hop(i,j) </BONDTERM> <BONDTERM type="1" source="i" target="j"> -hop'*boson_hop(i,j) </BONDTERM> </HAMILTONIAN> However when I run a DMRG calculation.I still get the wrong results.I compare the ground state energy of it with which I calculated by matlab using ED method.All the parameters of the two calculation are the same. I seem to misunderstand the implementation. So the question I want to ask is that are there any wrong in the definitions of my lattice or the model in XML. Thank you for any kind of heplful remarks. Yulian Chen

2 2

Why are mps_optim and dmrg different in <Sy> here after COMPLEX enabled?
by adfws 17 Oct '18

17 Oct '18

Hi everyone, I'm wondering if I can do some calculation with Sy in my spin 1/2 chain. Eventually I enabled COMPLEX to be 1, which sufficed me to have I(1i in matlab) in model xml files. There my H=sum(Sy(i)) for spin 1/2 chain with 4 sites. So the ground state is simply the case when all spin point to y down. Energy -0.5*4=-2 and all site measurements with Sy=-0.5. The question is that this is perfect with dmrg but not mps_optim, if I just change 'dmrg' in python script to 'mps_optim' <Sy> changes. My result is as follows: dmrg result: [[-0.5 -0.5 -0.5 -0.5]] mps_optim result: [[ 0. +1.54555976e-16j 0. +2.35922393e-16j 0. +9.39602206e-16j 0. +9.38558145e-32j]] Both get identical right energy value -2 but inconsistent in <Sy>. Great complex number result in MPS. Is there something I can do to make it right? All files are here: https://gitee.com/whitesnow1970/learn-Python-in-alps/tree/master/share LiuBiao ll070616(a)126.com

1 0

error in compilation
by benoît grémaud 04 Oct '18

04 Oct '18

Dear All, I am trying to install alps on a new linux machine fedora 28. Linux 4.18.10-200.fc28.x86_64 g++ is as follows: g++ (GCC) 8.1.1 20180712 (Red Hat 8.1.1-5) I've tried different sources (including boost): 2.2.b4, 2.2.b5 and 2.3.0 and also the latest snapshot. all versions fail compiling at the same point: Building CXX object src/alps/CMakeFiles/alps.dir/alea/observablefactory.C.o In file included from /home/gremaud/alps/alps/src/alps/alea/histogrameval.h:36, from /home/gremaud/alps/alps/src/alps/alea/observablefactory.C:38: /home/gremaud/alps/alps/src/alps/alea/histogram.h: In member function ‘alps::HistogramObservable<T>::const_iterator alps::HistogramObservable<T>::rbegin() const’: /home/gremaud/alps/alps/src/alps/alea/histogram.h:88:59: error: could not convert ‘((const alps::HistogramObservable<T>*)this)->alps::HistogramObservable<T>::histogram_.std::vector<unsign ed int>::rbegin()’ from ‘std::vector<unsigned int>::reverse_iterator’ {aka ‘std::reverse_iterator<__gnu_cxx::__normal_iterator<unsigned int*, std::vector<unsigned int> > >’} to ‘alps::His togramObservable<T>::const_iterator’ {aka ‘__gnu_cxx::__normal_iterator<const unsigned int*, std::vector<unsigned int> >’} const_iterator rbegin() const { return histogram_.rbegin();} ~~~~~~~~~~~~~~~~~^~ /home/gremaud/alps/alps/src/alps/alea/histogram.h: In member function ‘alps::HistogramObservable<T>::const_iterator alps::HistogramObservable<T>::rend() const’: /home/gremaud/alps/alps/src/alps/alea/histogram.h:90:55: error: could not convert ‘((const alps::HistogramObservable<T>*)this)->alps::HistogramObservable<T>::histogram_.std::vector<unsign ed int>::rend()’ from ‘std::vector<unsigned int>::reverse_iterator’ {aka ‘std::reverse_iterator<__gnu_cxx::__normal_iterator<unsigned int*, std::vector<unsigned int> > >’} to ‘alps::Histo gramObservable<T>::const_iterator’ {aka ‘__gnu_cxx::__normal_iterator<const unsigned int*, std::vector<unsigned int> >’} const_iterator rend() const { return histogram_.rend();} The same versions were perfectly compiling a while ago on fedora 27 and centos 7. I've also tried without boost sources but the installed one from fedora but it didn't work as well. Can you help me? thanks Best regards, Benoît -------------------- Researcher at CNRS, Centre de Physique Théorique (Marseille, France) and UMI MajuLab (Singapore) Visiting Associate Professor at the Centre for Quantum Technologies (NUS, Singapore)

1 0