On 20 Dec 2011, at 23:44, Mateusz Łącki wrote:

Dear All, I would like to ask about performing QMC in the canonical ensemble. This is what I found in the documentation:

RESTRICT_MEASUREMENTS[N]: "if defined this restricts measurements to configurations where the quantum number N (particle number) has the value given as this parameter. Note that the simulation will still performed in the grand canonical ensemble and the chemical potential needs to be tuned to the right range, to actually sample configurations with the desired particle number."

If I understand correctly this means that sampling is done over larger set of configurations than necessary and if by chance the configuration wanders to the correct value the measurement takes place. More specifically: the average is calculated over the canonical ensemble, but sampling is over the grand canonical ensemble (and therefore it may be inefficient). If one sets the value of canonical potential to a value such that the desired occupation is close to the average occupation in the grand canonical ensemble then probability of wandering into the correct value of N is relatively high. Not optimal \mu means that although in "number of samples" ->infty limit the result is the same, the probability of wandering is impractically low (and therefore the calculation will last forever). All in all the averages are over the canonical ensemble.

Additionally: chemical potential is set automatically ? if I set the chemical potential manually, then this is considered an initial value?

It this right?

I found the following quotation in the Wdostep.C file:

if (canonical) { if (static_cast<int>(parms["NUMBER_OF_PARTICLES"])==get_particle_number()) measure(); } else measure();

It seems to support my interpretation of documentation.

Regards, Mateusz Łącki

yes, you interpret it correctly but the chemical potential is *not* set automatically, thus first find the appropriate chemical potential in the vicinity of the density you aim for before running the canonical measurements.

Matthias

Yes, still not to be used. We are working on a new worm code that will support this and more.

Matthias

On 20 Dec 2011, at 23:45, Mateusz Łącki wrote:

Appendx:

MEASURE_GREEN false flag that indicates whether the Green's function should be measured. Don't use - this is untested!

is it still untested?

Regards, Mateusz Łącki

Indeed your reasoning is correct. With that value of K you get a huge potential in the corners. Do you really want K=0.01 with L=100? Also the temperature is extremely low for the simulation of trapped bosonic atoms in optical lattices. The simplest solution is just reducing L. As you said that helps, and if a few sites all around the boundary are empty then the system size is large enough. If that does not help then I can look for a quick fix.

Matthias

On 28 Dec 2011, at 21:05, Mateusz Łącki wrote:

Dear All I would like to thanks Matthias for all the answers.

I have been playing with worm binary today. I have a question regarding the error message I am getting.

I have added harmonic trap to the BH hamiltonian (via adding additional parameter K as presented in the alps documentation - the one published as an article - I added K*n(i)*(L/2-x)*(L/2-x)).

But when the temperature is getting lower and lower the following error appears:

Exceeding std::numeric_limits<double>::max() in integrated weight

These are the parameters:

LATTICE="inhomogeneous open chain lattice"; L=100;

MODEL="trapped boson Hubbard"; NONLOCAL=0; U = 1.0; mu = 2.5; Nmax = 5;

T=0.01; t=0.05; K=0.01

MEASURE_LOCAL[Occupation] = "n"; THERMALIZATION=10000; SWEEPS=100000;

{ mu=2.5 }

This is the case when a few atoms are present in the middle of the trap, but the lattice is empty. If one changes K to 0.001 then sites near the boundary are filled and there is no error. The same is when one changes L to 50 - only a few sites near the boundary are empty. It seems as if much too large local energy causes the error (and the larger L the larger local energy of sites near the boundary, as well as if the trap's curvature is big). I would like to ask for a comment on my calculations and assumptions regarding the root cause for the error. I would like to ask for a possible solution to the problem: how to get rid of this error altogether (maybe using higher precision of floats could be forced by recompilation?)

Regards, Mateusz Łącki