Dear All, could I ask if the DWA code actually supports the extended BH model (as defined in “boson Hubbard” hamiltonian in a standard issue of models.xml)? the results I obtain seem not to depend at all on the value of the V parameter. With sparsediag I observe no such behaviour.
thebondterm contains “hopping” (proportional to t#) and interaction (proportional to V#). If I wanted to split (as the hopping is treated separately in worm-type algorithms I guess…) it into two bond-terms it seems that only the last bondterm is taken into account:
this results in t=0 result <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"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM>
this in V=0 result: <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="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="t#" default="0"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM>
Best, Mateusz Łącki
Hi Mateusz,
Extended BHM is supported in the later version of DWA.
Several checks: 1. Can you download the latest version from trunk? 2. Can you check whether +V is supported also?
Best regards, Tamama
Sent from my iPhone
On 11 Oct 2016, at 11:13 PM, Mateusz Łącki mateusz.lacki@gmail.com wrote:
Dear All, could I ask if the DWA code actually supports the extended BH model (as defined in “boson Hubbard” hamiltonian in a standard issue of models.xml)? the results I obtain seem not to depend at all on the value of the V parameter. With sparsediag I observe no such behaviour.
thebondterm contains “hopping” (proportional to t#) and interaction (proportional to V#). If I wanted to split (as the hopping is treated separately in worm-type algorithms I guess…) it into two bond-terms it seems that only the last bondterm is taken into account:
this results in t=0 result
<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"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM>
this in V=0 result:
<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="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="t#" default="0"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM>
Best, Mateusz Łącki
Indeed it was a matter of old binaries. Anyway I get the segmentation fault even in the case of V=0 which is a BH model, and this used to work before. I will try the older versions.
The input that gives me a segmentation fault is just (version I have just downloaded from svn):
LATTICE="open chain lattice" L=30
MODEL="boson Hubbard" Nmax=5 N_total=5
t=.5 U=10 mu=0.2
THERMALIZATION=15000 SWEEPS=200000 SKIP=50
MEASURE[Local Density]=1 tof_phase=0
{ T=0.08 }
On 11 Oct 2016, at 17:59, Tama Ma tamama@yotcopi.com wrote:
Hi Mateusz,
Extended BHM is supported in the later version of DWA.
Several checks:
- Can you download the latest version from trunk?
- Can you check whether +V is supported also?
Best regards, Tamama
Sent from my iPhone
On 11 Oct 2016, at 11:13 PM, Mateusz Łącki mateusz.lacki@gmail.com wrote:
Dear All, could I ask if the DWA code actually supports the extended BH model (as defined in “boson Hubbard” hamiltonian in a standard issue of models.xml)? the results I obtain seem not to depend at all on the value of the V parameter. With sparsediag I observe no such behaviour.
thebondterm contains “hopping” (proportional to t#) and interaction (proportional to V#). If I wanted to split (as the hopping is treated separately in worm-type algorithms I guess…) it into two bond-terms it seems that only the last bondterm is taken into account:
this results in t=0 result
<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"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM>
this in V=0 result:
<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="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="t#" default="0"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM>
Best, Mateusz Łącki
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.
The following param worked well with me some months ago. Can you try this first? Let’s see if segmentation fault goes away...
LATTICE="square lattice"; L=4;
MODEL="boson Hubbard"; Nmax = 2; U = 1.0; V = 0.05; mu = 0.5; T = 0.1;
SWEEPS=50000; THERMALIZATION=100000; SKIP=500;
{ t=0.07; }
On 12 Oct 2016, at 2:58 AM, Mateusz Łącki mateusz.lacki@gmail.com wrote:
Indeed it was a matter of old binaries. Anyway I get the segmentation fault even in the case of V=0 which is a BH model, and this used to work before. I will try the older versions.
The input that gives me a segmentation fault is just (version I have just downloaded from svn):
LATTICE="open chain lattice" L=30
MODEL="boson Hubbard" Nmax=5 N_total=5
t=.5 U=10 mu=0.2
THERMALIZATION=15000 SWEEPS=200000 SKIP=50
MEASURE[Local Density]=1 tof_phase=0
{ T=0.08 }
On 11 Oct 2016, at 17:59, Tama Ma tamama@yotcopi.com wrote:
Hi Mateusz,
Extended BHM is supported in the later version of DWA.
Several checks:
- Can you download the latest version from trunk?
- Can you check whether +V is supported also?
Best regards, Tamama
Sent from my iPhone
On 11 Oct 2016, at 11:13 PM, Mateusz Łącki mateusz.lacki@gmail.com wrote:
Dear All, could I ask if the DWA code actually supports the extended BH model (as defined in “boson Hubbard” hamiltonian in a standard issue of models.xml)? the results I obtain seem not to depend at all on the value of the V parameter. With sparsediag I observe no such behaviour.
thebondterm contains “hopping” (proportional to t#) and interaction (proportional to V#). If I wanted to split (as the hopping is treated separately in worm-type algorithms I guess…) it into two bond-terms it seems that only the last bondterm is taken into account:
this results in t=0 result
<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"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM>
this in V=0 result:
<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="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="t#" default="0"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM>
Best, Mateusz Łącki
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.
I have changed something in the input file, then changed it back, and the segmentation fault has vanished. I will report it again if it reoccurs.
Thanks for help Regards, Mateusz
On 12 Oct 2016, at 05:43, Tama MA - Yotcopi tamama@yotcopi.com wrote:
The following param worked well with me some months ago. Can you try this first? Let’s see if segmentation fault goes away...
LATTICE="square lattice"; L=4;
MODEL="boson Hubbard"; Nmax = 2; U = 1.0; V = 0.05; mu = 0.5; T = 0.1;
SWEEPS=50000; THERMALIZATION=100000; SKIP=500;
{ t=0.07; }
On 12 Oct 2016, at 2:58 AM, Mateusz Łącki <mateusz.lacki@gmail.com mailto:mateusz.lacki@gmail.com> wrote:
Indeed it was a matter of old binaries. Anyway I get the segmentation fault even in the case of V=0 which is a BH model, and this used to work before. I will try the older versions.
The input that gives me a segmentation fault is just (version I have just downloaded from svn):
LATTICE="open chain lattice" L=30
MODEL="boson Hubbard" Nmax=5 N_total=5
t=.5 U=10 mu=0.2
THERMALIZATION=15000 SWEEPS=200000 SKIP=50
MEASURE[Local Density]=1 tof_phase=0
{ T=0.08 }
On 11 Oct 2016, at 17:59, Tama Ma <tamama@yotcopi.com mailto:tamama@yotcopi.com> wrote:
Hi Mateusz,
Extended BHM is supported in the later version of DWA.
Several checks:
- Can you download the latest version from trunk?
- Can you check whether +V is supported also?
Best regards, Tamama
Sent from my iPhone
On 11 Oct 2016, at 11:13 PM, Mateusz Łącki <mateusz.lacki@gmail.com mailto:mateusz.lacki@gmail.com> wrote:
Dear All, could I ask if the DWA code actually supports the extended BH model (as defined in “boson Hubbard” hamiltonian in a standard issue of models.xml)? the results I obtain seem not to depend at all on the value of the V parameter. With sparsediag I observe no such behaviour.
thebondterm contains “hopping” (proportional to t#) and interaction (proportional to V#). If I wanted to split (as the hopping is treated separately in worm-type algorithms I guess…) it into two bond-terms it seems that only the last bondterm is taken into account:
this results in t=0 result
<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"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM>
this in V=0 result:
<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="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="t#" default="0"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM>
Best, Mateusz Łącki
Comp-phys-alps-users Mailing List for the ALPS Project http://alps.comp-phys.org/ 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/ 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.
Hi Mateusz, (cc. Matthias)
With this seed, I have reproduced your segmentation fault problem. I need to understand why the random walk hits into the boundary error.
Meanwhile, please avoid using seeds that cause segmentation fault, before I come up with a proper fix for this.
Best regards, Tama MA
PARAM =======
LATTICE="open chain lattice" L=30
MODEL="boson Hubbard" Nmax=5
t=.5 U=10. mu=0.2
THERMALIZATION=15000 SWEEPS=200000 SKIP=50
SEED=1627085035
{ T=0.08 }
STDOUT ======= Thermalizing 14100 / 15000 Thermalizing 14150 / 15000 Thermalizing 14200 / 15000 Thermalizing 14250 / 15000 Thermalizing 14300 / 15000 Thermalizing 14350 / 15000 Thermalizing 14400 / 15000 Thermalizing 14450 / 15000 Thermalizing 14500 / 15000 Thermalizing 14550 / 15000 Thermalizing 14600 / 15000 Thermalizing 14650 / 15000 Thermalizing 14700 / 15000 Thermalizing 14750 / 15000 Thermalizing 14800 / 15000 Thermalizing 14850 / 15000 Thermalizing 14900 / 15000 Thermalizing 14950 / 15000 Thermalizing 15000 / 15000 Segmentation fault
On Oct 13, 2016, at 2:01 AM, Mateusz Łącki mateusz.lacki@gmail.com wrote:
I have changed something in the input file, then changed it back, and the segmentation fault has vanished. I will report it again if it reoccurs.
Thanks for help Regards, Mateusz
On 12 Oct 2016, at 05:43, Tama MA - Yotcopi <tamama@yotcopi.com mailto:tamama@yotcopi.com> wrote:
The following param worked well with me some months ago. Can you try this first? Let’s see if segmentation fault goes away...
LATTICE="square lattice"; L=4;
MODEL="boson Hubbard"; Nmax = 2; U = 1.0; V = 0.05; mu = 0.5; T = 0.1;
SWEEPS=50000; THERMALIZATION=100000; SKIP=500;
{ t=0.07; }
On 12 Oct 2016, at 2:58 AM, Mateusz Łącki <mateusz.lacki@gmail.com mailto:mateusz.lacki@gmail.com> wrote:
Indeed it was a matter of old binaries. Anyway I get the segmentation fault even in the case of V=0 which is a BH model, and this used to work before. I will try the older versions.
The input that gives me a segmentation fault is just (version I have just downloaded from svn):
LATTICE="open chain lattice" L=30
MODEL="boson Hubbard" Nmax=5 N_total=5
t=.5 U=10 mu=0.2
THERMALIZATION=15000 SWEEPS=200000 SKIP=50
MEASURE[Local Density]=1 tof_phase=0
{ T=0.08 }
On 11 Oct 2016, at 17:59, Tama Ma <tamama@yotcopi.com mailto:tamama@yotcopi.com> wrote:
Hi Mateusz,
Extended BHM is supported in the later version of DWA.
Several checks:
- Can you download the latest version from trunk?
- Can you check whether +V is supported also?
Best regards, Tamama
Sent from my iPhone
On 11 Oct 2016, at 11:13 PM, Mateusz Łącki <mateusz.lacki@gmail.com mailto:mateusz.lacki@gmail.com> wrote:
Dear All, could I ask if the DWA code actually supports the extended BH model (as defined in “boson Hubbard” hamiltonian in a standard issue of models.xml)? the results I obtain seem not to depend at all on the value of the V parameter. With sparsediag I observe no such behaviour.
thebondterm contains “hopping” (proportional to t#) and interaction (proportional to V#). If I wanted to split (as the hopping is treated separately in worm-type algorithms I guess…) it into two bond-terms it seems that only the last bondterm is taken into account:
this results in t=0 result
<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"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM>
this in V=0 result:
<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="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="t#" default="0"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM>
Best, Mateusz Łącki
Comp-phys-alps-users Mailing List for the ALPS Project http://alps.comp-phys.org/ http://alps.comp-phys.org/
List info: https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users Archive: https://lists.phys.ethz.ch//pipermail/comp-phys-alps-users 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 mailto:comp-phys-alps-users-leave@lists.phys.ethz.ch.
Comp-phys-alps-users Mailing List for the ALPS Project http://alps.comp-phys.org/ http://alps.comp-phys.org/
List info: https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users Archive: https://lists.phys.ethz.ch//pipermail/comp-phys-alps-users 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 mailto:comp-phys-alps-users-leave@lists.phys.ethz.ch.
Comp-phys-alps-users Mailing List for the ALPS Project http://alps.comp-phys.org/ 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.
Oh, yes, this is exactly the way it occured to me - rifht after last “Thermalizing”. Thanks.
Best, Mateusz
On 13 Oct 2016, at 08:21, Tama MA - Yotcopi tamama@yotcopi.com wrote:
Hi Mateusz, (cc. Matthias)
With this seed, I have reproduced your segmentation fault problem. I need to understand why the random walk hits into the boundary error.
Meanwhile, please avoid using seeds that cause segmentation fault, before I come up with a proper fix for this.
Best regards, Tama MA
PARAM
LATTICE="open chain lattice" L=30
MODEL="boson Hubbard" Nmax=5
t=.5 U=10. mu=0.2
THERMALIZATION=15000 SWEEPS=200000 SKIP=50
SEED=1627085035
{ T=0.08 }
STDOUT
Thermalizing 14100 / 15000 Thermalizing 14150 / 15000 Thermalizing 14200 / 15000 Thermalizing 14250 / 15000 Thermalizing 14300 / 15000 Thermalizing 14350 / 15000 Thermalizing 14400 / 15000 Thermalizing 14450 / 15000 Thermalizing 14500 / 15000 Thermalizing 14550 / 15000 Thermalizing 14600 / 15000 Thermalizing 14650 / 15000 Thermalizing 14700 / 15000 Thermalizing 14750 / 15000 Thermalizing 14800 / 15000 Thermalizing 14850 / 15000 Thermalizing 14900 / 15000 Thermalizing 14950 / 15000 Thermalizing 15000 / 15000 Segmentation fault
On Oct 13, 2016, at 2:01 AM, Mateusz Łącki <mateusz.lacki@gmail.com mailto:mateusz.lacki@gmail.com> wrote:
I have changed something in the input file, then changed it back, and the segmentation fault has vanished. I will report it again if it reoccurs.
Thanks for help Regards, Mateusz
On 12 Oct 2016, at 05:43, Tama MA - Yotcopi <tamama@yotcopi.com mailto:tamama@yotcopi.com> wrote:
The following param worked well with me some months ago. Can you try this first? Let’s see if segmentation fault goes away...
LATTICE="square lattice"; L=4;
MODEL="boson Hubbard"; Nmax = 2; U = 1.0; V = 0.05; mu = 0.5; T = 0.1;
SWEEPS=50000; THERMALIZATION=100000; SKIP=500;
{ t=0.07; }
On 12 Oct 2016, at 2:58 AM, Mateusz Łącki <mateusz.lacki@gmail.com mailto:mateusz.lacki@gmail.com> wrote:
Indeed it was a matter of old binaries. Anyway I get the segmentation fault even in the case of V=0 which is a BH model, and this used to work before. I will try the older versions.
The input that gives me a segmentation fault is just (version I have just downloaded from svn):
LATTICE="open chain lattice" L=30
MODEL="boson Hubbard" Nmax=5 N_total=5
t=.5 U=10 mu=0.2
THERMALIZATION=15000 SWEEPS=200000 SKIP=50
MEASURE[Local Density]=1 tof_phase=0
{ T=0.08 }
On 11 Oct 2016, at 17:59, Tama Ma <tamama@yotcopi.com mailto:tamama@yotcopi.com> wrote:
Hi Mateusz,
Extended BHM is supported in the later version of DWA.
Several checks:
- Can you download the latest version from trunk?
- Can you check whether +V is supported also?
Best regards, Tamama
Sent from my iPhone
On 11 Oct 2016, at 11:13 PM, Mateusz Łącki <mateusz.lacki@gmail.com mailto:mateusz.lacki@gmail.com> wrote:
Dear All, could I ask if the DWA code actually supports the extended BH model (as defined in “boson Hubbard” hamiltonian in a standard issue of models.xml)? the results I obtain seem not to depend at all on the value of the V parameter. With sparsediag I observe no such behaviour.
thebondterm contains “hopping” (proportional to t#) and interaction (proportional to V#). If I wanted to split (as the hopping is treated separately in worm-type algorithms I guess…) it into two bond-terms it seems that only the last bondterm is taken into account:
this results in t=0 result
<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"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM>
this in V=0 result:
<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="V#" default="0"/> -V#*(n(j)*n(i)) </BONDTERM> <BONDTERM source="i" target="j"> <PARAMETER name="t#" default="0"/> -t#*(bdag(i)*b(j)+bdag(j)*b(i)) </BONDTERM>
Best, Mateusz Łącki
Comp-phys-alps-users Mailing List for the ALPS Project http://alps.comp-phys.org/ http://alps.comp-phys.org/
List info: https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users Archive: https://lists.phys.ethz.ch//pipermail/comp-phys-alps-users 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 mailto:comp-phys-alps-users-leave@lists.phys.ethz.ch.
Comp-phys-alps-users Mailing List for the ALPS Project http://alps.comp-phys.org/ http://alps.comp-phys.org/
List info: https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users Archive: https://lists.phys.ethz.ch//pipermail/comp-phys-alps-users 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 mailto:comp-phys-alps-users-leave@lists.phys.ethz.ch.
Comp-phys-alps-users Mailing List for the ALPS Project http://alps.comp-phys.org/ http://alps.comp-phys.org/
List info: https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users https://lists.phys.ethz.ch//listinfo/comp-phys-alps-users Archive: https://lists.phys.ethz.ch//pipermail/comp-phys-alps-users 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 mailto:comp-phys-alps-users-leave@lists.phys.ethz.ch.
Comp-phys-alps-users Mailing List for the ALPS Project http://alps.comp-phys.org/ 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