Dear All, I am trying to implement "density dependent hopping" into the BH model via dwa/worm code, and I am getting totally wrong results. Namely I have added operators to the "boson" sitebasis:
<OPERATOR name="bdag" matrixelement="sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="bdagn" matrixelement="N*sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="b" matrixelement="sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR> <OPERATOR name="bn" matrixelement="(N-1)*sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR>
I have modified the boson Hubbard Hamiltonian:
<HAMILTONIAN name="boson Hubbard"> <PARAMETER name="mu" default="0"/> <PARAMETER name="t" default="1"/> <PARAMETER name="U" default="0"/> <PARAMETER name="t'" default="0"/> <PARAMETER name="te'" default="0"/> <PARAMETER name="V" default="0"/> <PARAMETER name="V'" default="0"/> <PARAMETER name="t0" default="t"/> <PARAMETER name="t1" default="t'"/> <PARAMETER name="te0" default="te"/> <PARAMETER name="te1" default="te'"/> <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 source="i" target="j"> <PARAMETER name="t#" default="0"/> <PARAMETER name="te#" default="0"/> <PARAMETER name="V#" default="0"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i))+te#*(bdagn(i)*b(j)+bdagn(j)*b(i)+bdag(i)*bn(j)+bdag(j)*bn(i)-bdag(i)*b(j)-bdag(j)*b(i))+ V#*n(i)*n(j) </BONDTERM> </HAMILTONIAN>
I have ran the code on square lattice (run script below) of dimension L=4:
with t=0.05 and te=0 <n^2>=3.30186272922 with t=0.05 and te=1e-9 I get <n^2>=15.6658661081 with t=0.05 and te=0.05 I get <n^2>=15..... with t=0.0 and te=0.05 I get <n^2>=3.19...
It seems when exactly one hopping term is present the output is (hopefully) reasonable. When two are present even with infinitesimal amplitude the code goes wrong. This leads me to a conclusion that the problem at least in part is "logical" in nature (the code seems to look for hopping operators and treat them in special way).
The result is the same up to mc errors no matter whether I use worm or dwa. I see no error from either code with that particular input.
Ultimately makes no sense to me. Can anyone hint me what is the problem?
Best, Mateusz Łącki
PS. My run script is here:
import sys sys.path.append('/home/lacki/alps/install22b4/lib') import pyalps
bin_dir = '/home/lacki/alps/install22b4/bin/'
for code in ['dwa','worm']: for models in ['models'+sys.argv[1],]: for t,te in [(0.05,0),(0,0.05),(0.05,0.05),(0.1,0.0),(0.0,0.1),(0.05,1e-9),(0,0),(0.,1e-9),(1e-9,0) ]: parms = [] parms.append( { 'LATTICE_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/lattices.xml", 'MODEL_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/"+models+'.xml', 'LATTICE' : "square lattice", 'MODEL' : "boson Hubbard", 'T' : 0.1, 'L' : 4 , 't' : t , 'te' : te, 'mu' : 1.1, 'U' : 1.0 , 'Nmax' : 5 , 'THERMALIZATION' : 100000, 'SWEEPS' : 20000000, 'SKIP' : 10, 'MEASURE[Winding Number]': 1, 'MEASURE[Local Density^2]': 1, } ) input_file = pyalps.writeInputFiles('parm1a'+models+'_'+str(t)+'_'+str(te)+'_'+code, parms) res = pyalps.runApplication(bin_dir+'dwa', input_file, Tmin=5, writexml=True)
naturally line :
res = pyalps.runApplication(bin_dir+'dwa', input_file, Tmin=5, writexml=True)
is wrong. The conclusion that dwa returns the same as worm is wrong. Worm gives: Found two raising operators Which is self-explanatory.
And DWA works only on BH models as was mentioned above. Best, Mateusz
On 01/06/2020, Mateusz Łącki mateusz.lacki@gmail.com wrote:
Dear All, I am trying to implement "density dependent hopping" into the BH model via dwa/worm code, and I am getting totally wrong results. Namely I have added operators to the "boson" sitebasis:
<OPERATOR name="bdag" matrixelement="sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="bdagn" matrixelement="N*sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="b" matrixelement="sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR> <OPERATOR name="bn" matrixelement="(N-1)*sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR>
I have modified the boson Hubbard Hamiltonian:
<HAMILTONIAN name="boson Hubbard"> <PARAMETER name="mu" default="0"/> <PARAMETER name="t" default="1"/> <PARAMETER name="U" default="0"/> <PARAMETER name="t'" default="0"/> <PARAMETER name="te'" default="0"/> <PARAMETER name="V" default="0"/> <PARAMETER name="V'" default="0"/> <PARAMETER name="t0" default="t"/> <PARAMETER name="t1" default="t'"/> <PARAMETER name="te0" default="te"/> <PARAMETER name="te1" default="te'"/> <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 source="i" target="j"> <PARAMETER name="t#" default="0"/> <PARAMETER name="te#" default="0"/> <PARAMETER name="V#" default="0"/>
-t#*(bdag(i)*b(j)+bdag(j)*b(i))+te#*(bdagn(i)*b(j)+bdagn(j)*b(i)+bdag(i)*bn(j)+bdag(j)*bn(i)-bdag(i)*b(j)-bdag(j)*b(i))+ V#*n(i)*n(j)
</BONDTERM> </HAMILTONIAN>
I have ran the code on square lattice (run script below) of dimension L=4:
with t=0.05 and te=0 <n^2>=3.30186272922 with t=0.05 and te=1e-9 I get <n^2>=15.6658661081 with t=0.05 and te=0.05 I get <n^2>=15..... with t=0.0 and te=0.05 I get <n^2>=3.19...
It seems when exactly one hopping term is present the output is (hopefully) reasonable. When two are present even with infinitesimal amplitude the code goes wrong. This leads me to a conclusion that the problem at least in part is "logical" in nature (the code seems to look for hopping operators and treat them in special way).
The result is the same up to mc errors no matter whether I use worm or dwa. I see no error from either code with that particular input.
Ultimately makes no sense to me. Can anyone hint me what is the problem?
Best, Mateusz Łącki
PS. My run script is here:
import sys sys.path.append('/home/lacki/alps/install22b4/lib') import pyalps
bin_dir = '/home/lacki/alps/install22b4/bin/'
for code in ['dwa','worm']: for models in ['models'+sys.argv[1],]: for t,te in [(0.05,0),(0,0.05),(0.05,0.05),(0.1,0.0),(0.0,0.1),(0.05,1e-9),(0,0),(0.,1e-9),(1e-9,0) ]: parms = [] parms.append( { 'LATTICE_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/lattices.xml", 'MODEL_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/"+models+'.xml', 'LATTICE' : "square lattice", 'MODEL' : "boson Hubbard", 'T' : 0.1, 'L' : 4 , 't' : t , 'te' : te, 'mu' : 1.1, 'U' : 1.0 , 'Nmax' : 5 , 'THERMALIZATION' : 100000, 'SWEEPS' : 20000000, 'SKIP' : 10, 'MEASURE[Winding Number]': 1, 'MEASURE[Local Density^2]': 1, } ) input_file = pyalps.writeInputFiles('parm1a'+models+'_'+str(t)+'_'+str(te)+'_'+code, parms) res = pyalps.runApplication(bin_dir+'dwa', input_file, Tmin=5, writexml=True)
I can refine my question now:
the worm code works when tehre is a "raising/lowering operator" R(i) and L(i). Then the hopping is expected to be of the form R(i)*L(j)+L(i)*R(j).
In particular this means (trivially) that in the Fock basis of the two-site space (i,j) the matrix form of the operator R(i)*L(j) has rank 1. If I want to define an arbitrary "hopping" two-site operator, which is not decomposable as a product (therefore its matrix has rank
1). Can I do it with worm code at all?
My understanding is that the L and R operators are used to move the worm heads and create it. To me it looks like a nontrivial change to the worm code, but perhaps I am missing something?
Best, Mateusz
On 01/06/2020, Mateusz Łącki mateusz.lacki@gmail.com wrote:
naturally line :
res = pyalps.runApplication(bin_dir+'dwa', input_file, Tmin=5, writexml=True)
is wrong. The conclusion that dwa returns the same as worm is wrong. Worm gives: Found two raising operators Which is self-explanatory.
And DWA works only on BH models as was mentioned above. Best, Mateusz
On 01/06/2020, Mateusz Łącki mateusz.lacki@gmail.com wrote:
Dear All, I am trying to implement "density dependent hopping" into the BH model via dwa/worm code, and I am getting totally wrong results. Namely I have added operators to the "boson" sitebasis:
<OPERATOR name="bdag" matrixelement="sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="bdagn" matrixelement="N*sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="b" matrixelement="sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR> <OPERATOR name="bn" matrixelement="(N-1)*sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR>
I have modified the boson Hubbard Hamiltonian:
<HAMILTONIAN name="boson Hubbard"> <PARAMETER name="mu" default="0"/> <PARAMETER name="t" default="1"/> <PARAMETER name="U" default="0"/> <PARAMETER name="t'" default="0"/> <PARAMETER name="te'" default="0"/> <PARAMETER name="V" default="0"/> <PARAMETER name="V'" default="0"/> <PARAMETER name="t0" default="t"/> <PARAMETER name="t1" default="t'"/> <PARAMETER name="te0" default="te"/> <PARAMETER name="te1" default="te'"/> <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 source="i" target="j"> <PARAMETER name="t#" default="0"/> <PARAMETER name="te#" default="0"/> <PARAMETER name="V#" default="0"/>
-t#*(bdag(i)*b(j)+bdag(j)*b(i))+te#*(bdagn(i)*b(j)+bdagn(j)*b(i)+bdag(i)*bn(j)+bdag(j)*bn(i)-bdag(i)*b(j)-bdag(j)*b(i))+ V#*n(i)*n(j)
</BONDTERM> </HAMILTONIAN>
I have ran the code on square lattice (run script below) of dimension L=4:
with t=0.05 and te=0 <n^2>=3.30186272922 with t=0.05 and te=1e-9 I get <n^2>=15.6658661081 with t=0.05 and te=0.05 I get <n^2>=15..... with t=0.0 and te=0.05 I get <n^2>=3.19...
It seems when exactly one hopping term is present the output is (hopefully) reasonable. When two are present even with infinitesimal amplitude the code goes wrong. This leads me to a conclusion that the problem at least in part is "logical" in nature (the code seems to look for hopping operators and treat them in special way).
The result is the same up to mc errors no matter whether I use worm or dwa. I see no error from either code with that particular input.
Ultimately makes no sense to me. Can anyone hint me what is the problem?
Best, Mateusz Łącki
PS. My run script is here:
import sys sys.path.append('/home/lacki/alps/install22b4/lib') import pyalps
bin_dir = '/home/lacki/alps/install22b4/bin/'
for code in ['dwa','worm']: for models in ['models'+sys.argv[1],]: for t,te in [(0.05,0),(0,0.05),(0.05,0.05),(0.1,0.0),(0.0,0.1),(0.05,1e-9),(0,0),(0.,1e-9),(1e-9,0) ]: parms = [] parms.append( { 'LATTICE_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/lattices.xml", 'MODEL_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/"+models+'.xml', 'LATTICE' : "square lattice", 'MODEL' : "boson Hubbard", 'T' : 0.1, 'L' : 4 , 't' : t , 'te' : te, 'mu' : 1.1, 'U' : 1.0 , 'Nmax' : 5 , 'THERMALIZATION' : 100000, 'SWEEPS' : 20000000, 'SKIP' : 10, 'MEASURE[Winding Number]': 1, 'MEASURE[Local Density^2]': 1, } ) input_file = pyalps.writeInputFiles('parm1a'+models+'_'+str(t)+'_'+str(te)+'_'+code, parms) res = pyalps.runApplication(bin_dir+'dwa', input_file, Tmin=5, writexml=True)
That is not implemented in DWA at all, if my memory did not fail me.
On 1 Jun 2020, at 6:45 PM, Mateusz Łącki mateusz.lacki@gmail.com wrote:
I can refine my question now:
the worm code works when tehre is a "raising/lowering operator" R(i) and L(i). Then the hopping is expected to be of the form R(i)*L(j)+L(i)*R(j).
In particular this means (trivially) that in the Fock basis of the two-site space (i,j) the matrix form of the operator R(i)*L(j) has rank 1. If I want to define an arbitrary "hopping" two-site operator, which is not decomposable as a product (therefore its matrix has rank
1). Can I do it with worm code at all?
My understanding is that the L and R operators are used to move the worm heads and create it. To me it looks like a nontrivial change to the worm code, but perhaps I am missing something?
Best, Mateusz
On 01/06/2020, Mateusz Łącki mateusz.lacki@gmail.com wrote:
naturally line :
res = pyalps.runApplication(bin_dir+'dwa', input_file, Tmin=5, writexml=True)
is wrong. The conclusion that dwa returns the same as worm is wrong. Worm gives: Found two raising operators Which is self-explanatory.
And DWA works only on BH models as was mentioned above. Best, Mateusz
On 01/06/2020, Mateusz Łącki mateusz.lacki@gmail.com wrote:
Dear All, I am trying to implement "density dependent hopping" into the BH model via dwa/worm code, and I am getting totally wrong results. Namely I have added operators to the "boson" sitebasis:
<OPERATOR name="bdag" matrixelement="sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="bdagn" matrixelement="N*sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="b" matrixelement="sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR> <OPERATOR name="bn" matrixelement="(N-1)*sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR>
I have modified the boson Hubbard Hamiltonian:
<HAMILTONIAN name="boson Hubbard"> <PARAMETER name="mu" default="0"/> <PARAMETER name="t" default="1"/> <PARAMETER name="U" default="0"/> <PARAMETER name="t'" default="0"/> <PARAMETER name="te'" default="0"/> <PARAMETER name="V" default="0"/> <PARAMETER name="V'" default="0"/> <PARAMETER name="t0" default="t"/> <PARAMETER name="t1" default="t'"/> <PARAMETER name="te0" default="te"/> <PARAMETER name="te1" default="te'"/> <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 source="i" target="j"> <PARAMETER name="t#" default="0"/> <PARAMETER name="te#" default="0"/> <PARAMETER name="V#" default="0"/>
-t#*(bdag(i)*b(j)+bdag(j)*b(i))+te#*(bdagn(i)*b(j)+bdagn(j)*b(i)+bdag(i)*bn(j)+bdag(j)*bn(i)-bdag(i)*b(j)-bdag(j)*b(i))+ V#*n(i)*n(j)
</BONDTERM> </HAMILTONIAN>
I have ran the code on square lattice (run script below) of dimension L=4:
with t=0.05 and te=0 <n^2>=3.30186272922 with t=0.05 and te=1e-9 I get <n^2>=15.6658661081 with t=0.05 and te=0.05 I get <n^2>=15..... with t=0.0 and te=0.05 I get <n^2>=3.19...
It seems when exactly one hopping term is present the output is (hopefully) reasonable. When two are present even with infinitesimal amplitude the code goes wrong. This leads me to a conclusion that the problem at least in part is "logical" in nature (the code seems to look for hopping operators and treat them in special way).
The result is the same up to mc errors no matter whether I use worm or dwa. I see no error from either code with that particular input.
Ultimately makes no sense to me. Can anyone hint me what is the problem?
Best, Mateusz Łącki
PS. My run script is here:
import sys sys.path.append('/home/lacki/alps/install22b4/lib') import pyalps
bin_dir = '/home/lacki/alps/install22b4/bin/'
for code in ['dwa','worm']: for models in ['models'+sys.argv[1],]: for t,te in [(0.05,0),(0,0.05),(0.05,0.05),(0.1,0.0),(0.0,0.1),(0.05,1e-9),(0,0),(0.,1e-9),(1e-9,0) ]: parms = [] parms.append( { 'LATTICE_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/lattices.xml", 'MODEL_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/"+models+'.xml', 'LATTICE' : "square lattice", 'MODEL' : "boson Hubbard", 'T' : 0.1, 'L' : 4 , 't' : t , 'te' : te, 'mu' : 1.1, 'U' : 1.0 , 'Nmax' : 5 , 'THERMALIZATION' : 100000, 'SWEEPS' : 20000000, 'SKIP' : 10, 'MEASURE[Winding Number]': 1, 'MEASURE[Local Density^2]': 1, } ) input_file = pyalps.writeInputFiles('parm1a'+models+'_'+str(t)+'_'+str(te)+'_'+code, parms) res = pyalps.runApplication(bin_dir+'dwa', input_file, Tmin=5, writexml=True)
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@lists.phys.ethz.ch.
Indeed I have looked through the DWA source, and it seems indeed very BH specific. What about worms?
Now my understanding is that: - all the worm codes work by expansion of the \exp(-beta H) into worldlines which are defined by the interaction-picture representation of the path integral w.r.t to H0 (diagonal part of H0) - the expansion (I skip the integral signs, times, etc...) is (let Y=\exp(-\beta H0)) like : 0) H = H0+ Y H1 Y +YH0 Y H0 Y+.....
If I want to have two hopping operators(lets call them H1 and H2) or equivalently one two-site hopping operator H4 I have two options:
a)H = H0+ Y H1 Y + YH2 Y +YH1 Y H2 Y+YH2 Y H1 Y+YH2 Y H2 Y+YH1 Y H1 Y+ b) H = H0+ Y H4 Y +YH4 Y H4 Y+.....
As I read these codes it seems to me they implement expansion 0) and expansion a) (if it is valid at all) is not implemented (worm code looks for a raising operator and quits if it finds more then one) and DWA is BH-specific.
As for a) the modification of ALPS code would entail a non-trivial generalization, one would have to pick whether I lower or raise by H1 or H2 with correct weights.
As for b) two-site operator does not preserve the Fock-state nature of the states in the worldlines and it seems completely inappropriate for this task.
Best, Mateusz
On 01/06/2020, Tama MA tamama@yotcopi.com wrote:
That is not implemented in DWA at all, if my memory did not fail me.
On 1 Jun 2020, at 6:45 PM, Mateusz Łącki mateusz.lacki@gmail.com wrote:
I can refine my question now:
the worm code works when tehre is a "raising/lowering operator" R(i) and L(i). Then the hopping is expected to be of the form R(i)*L(j)+L(i)*R(j).
In particular this means (trivially) that in the Fock basis of the two-site space (i,j) the matrix form of the operator R(i)*L(j) has rank 1. If I want to define an arbitrary "hopping" two-site operator, which is not decomposable as a product (therefore its matrix has rank
1). Can I do it with worm code at all?
My understanding is that the L and R operators are used to move the worm heads and create it. To me it looks like a nontrivial change to the worm code, but perhaps I am missing something?
Best, Mateusz
On 01/06/2020, Mateusz Łącki mateusz.lacki@gmail.com wrote:
naturally line :
res = pyalps.runApplication(bin_dir+'dwa', input_file, Tmin=5, writexml=True)
is wrong. The conclusion that dwa returns the same as worm is wrong. Worm gives: Found two raising operators Which is self-explanatory.
And DWA works only on BH models as was mentioned above. Best, Mateusz
On 01/06/2020, Mateusz Łącki mateusz.lacki@gmail.com wrote:
Dear All, I am trying to implement "density dependent hopping" into the BH model via dwa/worm code, and I am getting totally wrong results. Namely I have added operators to the "boson" sitebasis:
<OPERATOR name="bdag" matrixelement="sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="bdagn" matrixelement="N*sqrt(N+1)"> <CHANGE quantumnumber="N" change="1"/> </OPERATOR> <OPERATOR name="b" matrixelement="sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR> <OPERATOR name="bn" matrixelement="(N-1)*sqrt(N)"> <CHANGE quantumnumber="N" change="-1"/> </OPERATOR>
I have modified the boson Hubbard Hamiltonian:
<HAMILTONIAN name="boson Hubbard"> <PARAMETER name="mu" default="0"/> <PARAMETER name="t" default="1"/> <PARAMETER name="U" default="0"/> <PARAMETER name="t'" default="0"/> <PARAMETER name="te'" default="0"/> <PARAMETER name="V" default="0"/> <PARAMETER name="V'" default="0"/> <PARAMETER name="t0" default="t"/> <PARAMETER name="t1" default="t'"/> <PARAMETER name="te0" default="te"/> <PARAMETER name="te1" default="te'"/> <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 source="i" target="j"> <PARAMETER name="t#" default="0"/> <PARAMETER name="te#" default="0"/> <PARAMETER name="V#" default="0"/>
-t#*(bdag(i)*b(j)+bdag(j)*b(i))+te#*(bdagn(i)*b(j)+bdagn(j)*b(i)+bdag(i)*bn(j)+bdag(j)*bn(i)-bdag(i)*b(j)-bdag(j)*b(i))+ V#*n(i)*n(j)
</BONDTERM> </HAMILTONIAN>
I have ran the code on square lattice (run script below) of dimension L=4:
with t=0.05 and te=0 <n^2>=3.30186272922 with t=0.05 and te=1e-9 I get <n^2>=15.6658661081 with t=0.05 and te=0.05 I get <n^2>=15..... with t=0.0 and te=0.05 I get <n^2>=3.19...
It seems when exactly one hopping term is present the output is (hopefully) reasonable. When two are present even with infinitesimal amplitude the code goes wrong. This leads me to a conclusion that the problem at least in part is "logical" in nature (the code seems to look for hopping operators and treat them in special way).
The result is the same up to mc errors no matter whether I use worm or dwa. I see no error from either code with that particular input.
Ultimately makes no sense to me. Can anyone hint me what is the problem?
Best, Mateusz Łącki
PS. My run script is here:
import sys sys.path.append('/home/lacki/alps/install22b4/lib') import pyalps
bin_dir = '/home/lacki/alps/install22b4/bin/'
for code in ['dwa','worm']: for models in ['models'+sys.argv[1],]: for t,te in [(0.05,0),(0,0.05),(0.05,0.05),(0.1,0.0),(0.0,0.1),(0.05,1e-9),(0,0),(0.,1e-9),(1e-9,0) ]: parms = [] parms.append( { 'LATTICE_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/lattices.xml", 'MODEL_LIBRARY' : "/nfs/andy2/home/lacki/robota/2020_Staggered/qmctest/"+models+'.xml', 'LATTICE' : "square lattice", 'MODEL' : "boson Hubbard", 'T' : 0.1, 'L' : 4 , 't' : t , 'te' : te, 'mu' : 1.1, 'U' : 1.0 , 'Nmax' : 5 , 'THERMALIZATION' : 100000, 'SWEEPS' : 20000000, 'SKIP' : 10, 'MEASURE[Winding Number]': 1, 'MEASURE[Local Density^2]': 1, } ) input_file = pyalps.writeInputFiles('parm1a'+models+'_'+str(t)+'_'+str(te)+'_'+code, parms) res = pyalps.runApplication(bin_dir+'dwa', input_file, Tmin=5, writexml=True)
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@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@lists.phys.ethz.ch.
comp-phys-alps-users@lists.phys.ethz.ch