Imaginary Mu branch

[clarkedavida]

Jishnu implemented in the old code some support for configurations at pure imaginary chemical potential. We should bring it over.

[clarkedavida]

Well the smearing test and force test are working. Some things that are left to do:

• [x] Check the DSlashTest.
• [x] Right now these tests are implemented as separate main_. We should just incorporate them into already existing tests with a flag that turns on/off chemical potential.
• [x] There seem to be redundant if statements? Should eliminate these.
• [x] Once everything is passing, we should compare timing with the ParallelGPUCode. If it's a bit slower, we might get some speedup by implementing imaginary mu as a template parameter. If it's about the same speed, I would not bother, since this can slow down compile time.

[clarkedavida]

• [ ] Also we need to make multiGPU tests eventually. It's not super important at the moment, since all the runs in the foreseeable future can accommodated by one GPU.

[clarkedavida]

Well imaginary chemical potential is merged into the main branch. As it stands, the timing is quite good, resulting in a slowdown of O(0.03%), so we don't need to bother with template parameters.

We should still eliminate redundant if statements, it is just strange/confusing coding, and will also give us a negligible performance boost. Once this is done I will close the issue.

I don't want to bother with combining the tests. These are all run automatically by the test script anyhow.

[clarkedavida]

I have also checked the ForceProfiling on an 8^3x4 lattice, and found a slowdown of less than 0.3%. Next I will check the time for a small amount of RHMC using the test, which is a 10^4 lattice.

[clarkedavida]

rhmc with 10 steps

after changes: 1m 54s before changes: 1m 52s

So yeah there is essentially no difference in time. With these three tests, we can safely conclude the performance was negligibly impacted.

[clarkedavida]

The imaginary mu tests need to be much more stringent.

[clarkedavida]

With the fix in 2daa2c953b4a9ea0af39fb14c196e20482a3b3e0, after removing the if(mu0!=0) statements, I find that SIMULATeQCD RHMC with mu0=0 agrees with SIMULATeQCD RHC with if(mu0!=0) statements agrees with parallelGPUCode standard RHMC.

I am still not sure what is going on with parallelGPUCode imaginary mu module...

[clarkedavida]

parallelGPUCode mu=0.4 does not agree with SIMULATeQCD mu=0.4, which I guess makes sense given everything else we've discovered so far. SIMULATeQCD version passes RHMC test with 90% acceptance and passes a detailed reversibility test.

i will try to implement the more detailed reversibility test in parallelgpucode and see how that goes

[clarkedavida]

parallelgpu code with imaginary mu passes the more detailed reversibility test as well as the RHMC with 87% acceptance...

[clarkedavida]

It appears to be an issue of precision. In particular in the parallelgpucode normal RHMC and in SIMULATeQCD, there are some hard-coded doubles in integrator.cu. Whereas in the parallelgpucode imaginary mu RHMC these are rather floatT, which then evaluate to float when the tests are run.

[clarkedavida]

• [x] Don't forget documentation

[clarkedavida]

I don't really have any interest in getting the imaginary mu to work for multiGPU at the moment, since we will not need it for quite a long time. When I'm done merging in my branch I am going to close this issue.

[lukas-mazur]

Isn't this just an extension of the rhmc? I would expect this to work already for multiGPU ?

[clarkedavida]

I would also expect it to pass, but now that you mention it, the rhmc is not tested for multiGPU in the current testing script.

[clarkedavida]

Imaginary mu stuff is now merged in.