Hello,
From http://alps.comp-phys.org/mediawiki-1.9.3/index.php/Tutorials:ModelHOWTO
"Optionally, a type attribute can be set to bosonic (the default) or fermionic. It should be set to fermionic when the quantum number is a fermionic number operator. This information will be used when determining commutation relation between operators on different sites."
This is very imprecise. To be honest, I do not understand that at all.
First of all, good quantum numbers take numerical values, and numbers commute. Hence, the relations for quantum numbers are always *commutation* relations.
The anticommutation relations are for the creation and annihilation *operators*. Hence, whether or not it make sense to assign such a "type=" attribute to a degree of freedom (call it a QUANTUMNUMBER), the attribute applies to *operators*! Moreover, not all operators, but only those that are odd in the creation and annihilation operators. For example, the spin operator for a pair of spin-up, spin-down fermion states satisfies *commutation* relations.
Now please tell me why the code refuses to generate a matrix (probably for the hopping and exchange terms, but the error message does not state which terms pose a problem). Both terms are even in the creation and annihilation operators (capital S refers to a bosonic spin):
<SITEBASIS name="orbital"> <QUANTUMNUMBER name="Nup" min="0" max="1" type="fermionic"/> <QUANTUMNUMBER name="Ndown" min="0" max="1" type="fermionic"/> <OPERATOR name="a_up" matrixelement="1"> <CHANGE quantumnumber="Nup" change="-1"/> </OPERATOR> <OPERATOR name="adag_up" matrixelement="1"> <CHANGE quantumnumber="Nup" change="1"/> </OPERATOR> <OPERATOR name="a_down" matrixelement="1"> <CHANGE quantumnumber="Ndown" change="-1"/> </OPERATOR> <OPERATOR name="adag_down" matrixelement="1"> <CHANGE quantumnumber="Ndown" change="1"/> </OPERATOR> <OPERATOR name="splus" matrixelement="1/2"> <CHANGE quantumnumber="Nup" change="1"/> <CHANGE quantumnumber="Ndown" change="-1"/> </OPERATOR> <OPERATOR name="sminus" matrixelement="1/2"> <CHANGE quantumnumber="Nup" change="-1"/> <CHANGE quantumnumber="Ndown" change="1"/> </OPERATOR> <OPERATOR name="sz" matrixelement="(Nup-Ndown)/2"/> <OPERATOR name="n" matrixelement="Nup+Ndown"/> </SITEBASIS>
<BONDOPERATOR name="exchange_xy" source="x" target="y"> 1/2*(splus(x)*Sminus(y)+sminus(x)*Splus(y)) </BONDOPERATOR>
<BONDOPERATOR name="exchange_z" source="x" target="y"> sz(x)*Sz(y) </BONDOPERATOR>
<BONDOPERATOR name="hop" source="x" target="y">
adag_up(x)*a_up(y)+adag_up(y)*a_up(x)+adag_down(x)*a_down(y)+adag_down(y)*a_down(x) </BONDOPERATOR>
Regards, Cezary Sliwa
On Dec 19, 2008, at 11:58 PM, Cezary Sliwa wrote:
From http://alps.comp-phys.org/mediawiki-1.9.3/index.php/Tutorials:ModelHOWTO
"Optionally, a type attribute can be set to bosonic (the default) or fermionic. It should be set to fermionic when the quantum number is a fermionic number operator. This information will be used when determining commutation relation between operators on different sites."
This is very imprecise. To be honest, I do not understand that at all.
First of all, good quantum numbers take numerical values, and numbers commute. Hence, the relations for quantum numbers are always *commutation* relations.
The anticommutation relations are for the creation and annihilation *operators*. Hence, whether or not it make sense to assign such a "type=" attribute to a degree of freedom (call it a QUANTUMNUMBER), the attribute applies to *operators*! Moreover, not all operators, but only those that are odd in the creation and annihilation operators. For example, the spin operator for a pair of spin-up, spin-down fermion states satisfies *commutation* relations.
Indeed you are right. What we mean is that a "fermionic" quantum number is a quantum number describing the number of fermions on a site. Knowing that a quantum number counts the number of fermions allows us to automatically deduce which operators are "fermionic" in the sense that you mention: they change these fermion numbers by an odd number.
Now please tell me why the code refuses to generate a matrix (probably for the hopping and exchange terms, but the error message does not state which terms pose a problem). Both terms are even in the creation and annihilation operators (capital S refers to a bosonic spin):
What is the error message and what is the code?
Matthias
Matthias Troyer wrote:
Now please tell me why the code refuses to generate a matrix (probably for the hopping and exchange terms, but the error message does not state which terms pose a problem). Both terms are even in the creation and annihilation operators (capital S refers to a bosonic spin):
What is the error message and what is the code?
sliwa /var/tmp/alps/alps-applications-1.3.3/tutorial/quantum2$ dirloop_sse --Tmin 10 parm4ax.in.xml Quantum Monte simulations using the generalized directed loop algorithm v. 1.1 available from http://alps.comp-phys.org/ copyright (c) 2001-2005 by Fabien Alet alet@comp-phys.org, Synge Todo wistaria@comp-phys.org, and Matthias Troyer troyer@comp-phys.org see F. Alet, S. Wessel and M. Troyer, Phys. Rev. E 71, 036706 (2005) for details.
using the ALPS parallelizing scheduler copyright (c) 1994-2006 by Matthias Troyer troyer@comp-phys.org. see Lecture Notes in Computer Science, Vol. 1505, p. 191 (1998).
based on the ALPS libraries version 1.3.3 available from http://alps.comp-phys.org/ copyright (c) 1994-2008 by the ALPS collaboration. Consult the web page for license details. For details see the publication: A.F. Albuquerque et al., J. of Magn. and Magn. Materials 310, 1187 (2007).
parsing task files ... Cannot convert fermionic operator to a bosonic matrix
Thanks, Cezary Sliwa
Matthias
On Dec 22, 2008, at 5:20 PM, Cezary Sliwa wrote:
Matthias Troyer wrote:
Now please tell me why the code refuses to generate a matrix (probably for the hopping and exchange terms, but the error message does not state which terms pose a problem). Both terms are even in the creation and annihilation operators (capital S refers to a bosonic spin):
What is the error message and what is the code?
sliwa /var/tmp/alps/alps-applications-1.3.3/tutorial/quantum2$ dirloop_sse --Tmin 10 parm4ax.in.xml
parsing task files ... Cannot convert fermionic operator to a bosonic matrix
Thanks, Cezary Sliwa
The QMC codes do not work for fermions.
Matthias
On Sat, Dec 20, 2008 at 10:38:35AM +0800, Matthias Troyer wrote:
What is the error message and what is the code?
I defined a simple model, just one tight-binding orbital with nearest neighbors hops on a cubic lattice. With this model I still get the error message about fermionic operators.
If I do the opposite, i.e. remove from the Kondo lattice the hopping term with the corresponding bonds, the effect is:
node1 ~/smieci/alps/alps-applications-1.3.3/tutorial/quantum2$ dirloop_sse --Tmin 10 parm4ax.in.xml Quantum Monte simulations using the generalized directed loop algorithm v. 1.1 available from http://alps.comp-phys.org/ copyright (c) 2001-2005 by Fabien Alet alet@comp-phys.org, Synge Todo wistaria@comp-phys.org, and Matthias Troyer troyer@comp-phys.org see F. Alet, S. Wessel and M. Troyer, Phys. Rev. E 71, 036706 (2005) for details.
using the ALPS parallelizing scheduler copyright (c) 1994-2006 by Matthias Troyer troyer@comp-phys.org. see Lecture Notes in Computer Science, Vol. 1505, p. 191 (1998).
based on the ALPS libraries version 1.3.3 available from http://alps.comp-phys.org/ copyright (c) 1994-2008 by the ALPS collaboration. Consult the web page for license details. For details see the publication: A.F. Albuquerque et al., J. of Magn. and Magn. Materials 310, 1187 (2007).
parsing task files ... Cannot evaluate expression Sminus(i)
The lattice and model libraries are attached to this message.
Regards, Cezary Sliwa
PS. Obviously, the problem is that the error messages do not show which term/operator/etc is the source of the problem.
Matthias
On 23 Dec 2008, at 10:14, Cezary Sliwa wrote:
On Sat, Dec 20, 2008 at 10:38:35AM +0800, Matthias Troyer wrote:
What is the error message and what is the code?
I defined a simple model, just one tight-binding orbital with nearest neighbors hops on a cubic lattice. With this model I still get the error message about fermionic operators.
Indeed - the QMC codes cannot do fermions
Cannot evaluate expression Sminus(i)
You have not defined any operator Sminus
Matthias
Matthias Troyer wrote:
Indeed - the QMC codes cannot do fermions
OK, thanks.
Cannot evaluate expression Sminus(i)
You have not defined any operator Sminus
There is one defined. The Hamiltonian is "spin", the lattice is "spin lattice" (both from the libraries I attached previously).
Regards, Cezary Sliwa
Matthias
On Dec 29, 2008, at 10:45 AM, Cezary Sliwa wrote:
Matthias Troyer wrote:
Indeed - the QMC codes cannot do fermions
OK, thanks.
Cannot evaluate expression Sminus(i)
You have not defined any operator Sminus
There is one defined. The Hamiltonian is "spin", the lattice is "spin lattice" (both from the libraries I attached previously).
You need to define it for each basis set you define - you cannot mix operators from different basis sets.
Matthias Troyer
Matthias Troyer wrote:
Cannot evaluate expression Sminus(i)
You have not defined any operator Sminus
There is one defined. The Hamiltonian is "spin", the lattice is "spin lattice" (both from the libraries I attached previously).
You need to define it for each basis set you define - you cannot mix operators from different basis sets.
I am not sure, what you mean. I understand that operators are defined in SITEBASIS, then BASIS references SITEBASIS. Then Hamiltonian references BASIS, and the Hamiltonian terms can use the operators.
My input files are attached to this message. They are similar to the Kondo lattice model in the tutorial libraries.
Cezary Sliwa
LATTICE="test lattice" MODEL = "test hamiltonian" LATTICE_LIBRARY="test_lattice.xml" MODEL_LIBRARY="test_model.xml" Lx=1 Ly=1 Lz=1 J=1 T=0.08 THERMALIZATION=1000 SWEEPS=20000 {h=0;} {h=0.1;} {h=0.2;} {h=0.3;} {h=0.4;} {h=0.5;} {h=0.6;} {h=0.7;} {h=0.8;} {h=0.9;} {h=1.0;} SWEEPS=10000; {h=1.2;} {h=1.4;} {h=1.6;} {h=1.8;} {h=2.0;} {h=2.2;} {h=2.4;} {h=2.5;}
Matthias Troyer wrote:
Indeed - the QMC codes cannot do fermions
I lost my hope for a moment. But... The Hamiltonian is expressed in terms of spin operators, which are second order, i.e. bosonic. Hence, the fermionic nature of the site is internal only and completely irrelevant. Your check is simply too strict. Please let me know how to fix this problem.
Cezary Sliwa
On Tue, Dec 23, 2008 at 12:36:19PM +0100, Matthias Troyer wrote:
On 23 Dec 2008, at 10:14, Cezary Sliwa wrote:
On Sat, Dec 20, 2008 at 10:38:35AM +0800, Matthias Troyer wrote:
What is the error message and what is the code?
I defined a simple model, just one tight-binding orbital with nearest neighbors hops on a cubic lattice. With this model I still get the error message about fermionic operators.
Indeed - the QMC codes cannot do fermions
Sorry, what I have written in a previous message is not correct: the problem is with the hopping terms, which are first order in a fermionic operators for a given site. Only the exchange term is expressed in spins. But still, it is second order (a fermion is annihilated at one site and created at another), so that the relation for different bond operators are commutation relations.
Taking this into account, is the difficulty fundamental or just a limitation of your code?
Cezary Sliwa
Cannot evaluate expression Sminus(i)
You have not defined any operator Sminus
Matthias
On 9 Jan 2009, at 13:05, Cezary Sliwa wrote:
On Tue, Dec 23, 2008 at 12:36:19PM +0100, Matthias Troyer wrote:
On 23 Dec 2008, at 10:14, Cezary Sliwa wrote:
On Sat, Dec 20, 2008 at 10:38:35AM +0800, Matthias Troyer wrote:
What is the error message and what is the code?
I defined a simple model, just one tight-binding orbital with
nearest
neighbors hops on a cubic lattice. With this model I still get the error message about fermionic operators.
Indeed - the QMC codes cannot do fermions
Sorry, what I have written in a previous message is not correct: the problem is with the hopping terms, which are first order in a fermionic operators for a given site. Only the exchange term is expressed in spins. But still, it is second order (a fermion is annihilated at one site and created at another), so that the relation for different bond operators are commutation relations.
Taking this into account, is the difficulty fundamental or just a limitation of your code?
The difficulty is fundamental: there is no general solution for the fermion sign problem.
Matthias
comp-phys-alps-users@lists.phys.ethz.ch