Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very low acceptance for SU(2) 1 adjoint flavour RHMC #374

Open
edbennett opened this issue Nov 4, 2021 · 2 comments
Open

Very low acceptance for SU(2) 1 adjoint flavour RHMC #374

edbennett opened this issue Nov 4, 2021 · 2 comments

Comments

@edbennett
Copy link
Contributor

I'm seeing very low acceptance rates when running the RHMC for SU(2) with one adjoint flavour when compared to what I believe are exactly the same run parameters for HiRep. With HiRep this is around 90%, while with the same parameters in Grid it is very close to 0%.

What I've checked:

  • Same fermion and gauge action (Wilson in both cases)
  • Same value for beta and bare fermion mass
  • Same lattice volume
  • The integrator in both cases is MinimumNorm2 (called O2MN_multistep in HiRep)
  • MD trajectory length is the same
  • Same number of MD time steps
  • Two levels of integration, with 1 multiplier at the top (fermionic) level and 5 multiplier at the bottom (gauge) layer
  • Same numerical precision (double precision throughout)
  • Even-odd preconditioning is used in both cases
  • Boundary conditions are the same
  • Initial conditions are the same (hot start)
  • We previously found that using 2/4 as the exponent gives better performance than 1/2; I have tried adjusting Grid/qcd/action/pseudofermion/OneFlavourEvenOddRational.h to this effect but no obvious change in acceptance (or time to trajectory)
  • I've also tried adjusting the parameters to the rational approximation to increase the order and precision, but this doesn't noticeably affect the acceptance, and does make the update take longer.
  • The code appears to be simulating the correct theory, as a scan of the phase diagram on a 4^4 lattice very closely reproduces the plot of arXiv:1412.5994

I've tested CPU and GPU builds (with and without MPI for the latter) and see the same issue in both.

Increasing the number of MD steps per trajectory increases the acceptance, but makes each trajectory take correspondingly longer.

Does anyone have any idea what might be going on, and how I could fix it, please?

If it's useful, I've attached an example grid.configure.summary, the program I'm running, an example submit script to see the parameters being used, and the equivalent input file used with HiRep.

Many thanks in advance for any advice.

@edbennett
Copy link
Contributor Author

Two more things that I have checked:

  • @LupoA pointed out that there is a normalisation factor of HMC_MOMENTUM_DENOMINATOR that is by default set to 2, while in HiRep this factor is not included. Setting this to 1 (via removing the #define CPS_MD_TIME in Grid/qcd/action/gauge/GaugeImplTypes.h and Grid/qcd/action/scalar/ScalarImpl.h) does not remove the discrepancy.
  • HiRep multiplies the step size by beta / NG, which as far as I can see isn't done in Grid. Removing this factor further exacerbates the discrepancy.

@edbennett
Copy link
Contributor Author

Some more testing shows that with a thermalised configuration (the same one for both codes), and controlling for all the factors above, the acceptances match much more closely between HiRep and Grid. Additionally, setting --Thermalizations to a number larger than zero (I've been using 20) will immediately overcome this initial barrier and allow the acceptance to stabilise at the same parameters as work for HiRep (which does not do this thermalisation step, as far as I am aware). This raises three possibilities that I can see:

  • HiRep does some thermalisation that I'm not aware of (although I have searched and haven't found evidence of this)
  • Grid's integrator behaves differently on very far-from-equilibrium configurations
  • Grid initialises a hot start differently from HiRep

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant