claudiopica / hirep Goto Github PK

When quaternions are enabled, the Wilson Flow rapidly blows up—within a step of 0.1 with the RK3 integrator, the observables are all nans. (Reducing the step size to 0.01 allows observation of the observables growing by orders of magnitude per step.) The same configuration analysed with quaternions disabled gives a sensible flow.

In the Include/Core/gpu_complex.h makes use of Class Template Argument Deduction, a C++17 feature.

Whether -std=c++17 is specified by default to nvcc is OS-dependent, so on some machines HiRep fails to build for GPU, giving the error argument list for class template "hr_complex_t" is missing.

Could the -std=c++17 flag please be automatically added to the GPUFLAGS to avoid this, please?

test project

HiRep includes and directly links against Martin Lüscher's RANLUX, which is licensed under GPLv2. In principle this should mean that HiRep is also GPLv2 licensed, and is required to state as much in the distribution.

Should a COPYING or LICENSE file be added to the root of the repository (in all branches) containing a copy of the GPL v2?

When compiling hmc with MACRO += -DMEASURE_FORCE defined in MkFlags, the compiler gives the following error:

Compiling [%/LibHR/Update/force0.o]...force0.c:80:17: error: use of undeclared identifier 'beta'
  forcestat0 *= beta / ((4. * NG) * GLB_VOLUME);
                ^
force0.c:81:17: error: use of undeclared identifier 'beta'
  forcestat1 *= beta / ((double)(NG));
                ^
2 errors generated.
  FAIL

The centralised implementation of read_cmdline() (seemingly introduced in 7ffaeea) doesn't work with the spectroscopy and other measurement codes. Initially these fail to compile because setup_process() is now declared static. After adjusting this to be not static, the programs compile, but one is required to use -c or -l to specify a configuration or list file—however, this argument is then rejected by the central read_cmdline(), which only expects -i and -o. Similarly, converter fails because it expects the parameter passed to -i to be a configuration rather than a text input file.

I can see three ways of approaching a fix:

1. Revert the changes that caused this to break, moving read_cmdline() back to hmc
2. Add a flag to setup_process() that controls whether read_cmdline() is called there or if it is skipped and left to the individual application to handle this.
3. Modify setup_process() and read_cmdline to take a struct of settings for the command line, and incorporate all of the setup currently done in the individual applications into process_init.c.

Which of these (if any) would be preferable? Thanks!