urbach / su2

A MCMC sampling package for lattice gauge theories

This package implements Metropolis Monte Carlo and Hybrid Monte Carlo for SU(2) and U(1) gauge theories in d=2,3,4 dimensions. The library supports also the measurements of several observables, e.g.:

• topological charge
• Wilson loops
• gradient flow
• glueball correlators

Software dependencies

• Boost
• yaml-cpp
• xtl
• xtensor

Installation instrucitons

This project is compiled using cmake. The installation process produces 2 directories, corresponding to the debug and release cmake build types.

In the following we assume that the source code is placed in ${HOME}/code/.

1. Create a build directory in a custom location, e.g.: ${HOME}/build/su2/
2. Copy the content of the directory doc/installation_scripts/ in that directory.
3. Change the fields of do_cmake.sh such that they match your choice.
4. Run

   bash do_cmake.sh
   bash do_make.sh

Done. You'll find the debug and executables in the debug/bin/ and release/bin/ subdirectories of the installation directory.

su2's Issues

possibly wrong factor in $S_G$

I'm not convinced by the factor 6 in https://github.com/urbach/su2/blob/4053c09ae54a7a2828c0e3930a2b864e7e132680/gaugemonomial.hh#L20 and https://github.com/urbach/su2/blob/4053c09ae54a7a2828c0e3930a2b864e7e132680/gaugemonomial.hh#L24.
The gauge action is :
$$S = (\beta/N_c) \sum_x \sum_{\mu < \nu} Re( Tr( 1 - U_{\mu\nu}(x) ) )$$
The 1st contribution is $(\beta/N_c) \sum_x \sum_{\mu < \nu} Re( Tr( 1) )$ , which is $6 \beta V$ only in $d=4$ dimensions because
$$ \sum_{\nu=0}^{3} \sum_{\mu<\nu} 1 =0+1+2+3=6$$.
In $d=2+1$ dimensions however the latter is $0+1+2=3$. In general:
$$\sum_{\nu=0}^{d-1} \sum_{\mu&lt;\nu} 1 = \frac{d(d-1)}{2}$$.

pi evaluation

su2/random_element.hh

Line 7 in 4053c09

constexpr double pi() { return std::atan(1)*4; }

Why do we evaluate $\pi$? Can't we use the global variable M_PI from <math.h>?

anisotropy ineffective

Issue on the master branch

The anisotropy options don't have any effect, the output stays the same. Try for instance the following script switching them on or off:

../u1-hmc \
  -X 8 -Y 8 -Z 8 -T 16 --ndims 3 \
  --nsave 1 --nmeas 5 --counter 0 \
  -b 1.9 \
  --seed 2964211 \
  --heat 1 \
  --nrev 5 \
  --nsteps 100 \
  --tau 2.0 \
  --integrator 0 \
  --xi 0.7 \
  --anisotropic 1 \

Todo list

The following things need to be implemented

• a YAML based input file
• a type for spinor fields
• the Wilson (twisted?) Dirac operator in d=2,3,4
• a CG solver for the normal equations
• a det monomial including heatbath, accept, and derivative functionality

traceless anti-hermitean part of SU(2) matrix

Why here

su2/include/su2.hh

Line 84 in 7d4a9bf

return(_su2(0.5*(x.geta()-std::conj(x.geta())), x.getb()));

we don't have

const std::complex<double> a1 = 0.5 * (x.geta() - std::conj(x.geta()));
const std::complex<double> b1 = 0.5 * (x.getb() - std::conj(x.getb()));
return (_su2(a1, b1));

?

Extra memory for `adjointfield`

The values of the adjoint field are stored in the data attribute. In the constructor, this is resized to volume*4

su2/include/adjointfield.hh

Line 107 in 7d4a9bf

data.resize(volume * 4);

but it should be volume*ndims. This didn't cause issues on previous runs because all loops have limits deduced by other methods of the class, so the extra entries of the array are simply unused when ndims < 4

wilson loop evaluated only for 2 spatial distances

Why do we call this function here?

su2/measure-u1.cc

Line 95 in 919188c

compute_spacial_loops(U, os.str());

compute_spacial_loops() does it for just 2 distances: r=2,8, which are not all and may not be acceptable (e.g. if 8>Lx. Please see 34f55af

Non reversible integrators

The integrators lp_leapfrog and lp_omf4 are not reversible.

Possible bug in get_deriv for adjointsu2 objects

Please see https://github.com/urbach/su2/blob/4053c09ae54a7a2828c0e3930a2b864e7e132680/adjointfield.hh#L66

If I understand correctly, adjointsu2 is a class containing 3 numbers (a, b, c) which represent the object as a member of the adjoint representation of su2:
$$ M = a*\sigma_x + b*\sigma_y + c*\sigma_z $$

get_deriv should give back (as in eq. 5 of HMC and QCD
$$ Q = Im(a)\sigma_x + Im(b)\sigma_y + Im(c)*\sigma_z $$

so I think the function should be implemented as follows:

template<typename Float=double> inline adjointsu2<Float> get_deriv(su2 & A) {
  const Complex a = A.geta(), b = A.getb(), c = A.getc();
  return adjointsu2<Float>(2.*std::imag(b), 2.*std::real(b), 2.*std::imag(c));
}

Qtop computed only in $d=2,4$

The topological charge is not computed for $d=3$. The reason is that in tensors.hh is not implemented the Levi-Civita tensor in $3$ dimensions

inconsistent start of numbering of gauge configs

For U(1), the hmc and the offline measurements don't match the first config:

• The u1-hmc prints gauge configurations starting from i=1:
  https://github.com/urbach/su2/blob/bb34244e7c1290a7d85f199ebc746071447a86d1/hmc-u1.cc#L174

• The u1-measure reads them starting from an index specified by --counter arg (=0). If not explicitly passed, its default value always makes the first read to fail, because the starting configuration hasn't been printed out.
  https://github.com/urbach/su2/blob/bb34244e7c1290a7d85f199ebc746071447a86d1/measure-u1.cc#L66

Considering the low cost of evaluating the observables for the 0th configuration, I'd suggest to remove the condition i>0 in the u1-hmc code.

command line parameters in the offline measures

su2/measure-u1.cc

Line 52 in bb34244

("nsteps", po::value<size_t>(&n_steps)->default_value(1000), "n_steps")

Do we really need the last 4 arguments for the measure program?

Function needs more parameters for calculating spatial-spatial plaquette

su2/program-u1.hpp

Line 166 in 7cb05b0

double gauge_energy(const gp::physics &pparams, const gaugeconfig<Group> &U) {

this should be fixed the same way as in #30 (comment).