Open edbennett opened 3 years ago
Two more things that I have checked:
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.beta / NG
, which as far as I can see isn't done in Grid. Removing this factor further exacerbates the discrepancy.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:
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:
MinimumNorm2
(calledO2MN_multistep
in HiRep)Grid/qcd/action/pseudofermion/OneFlavourEvenOddRational.h
to this effect but no obvious change in acceptance (or time to trajectory)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.