Round beta / delta_tau to get number of slices in DQMC

[MasonProtter]

I'm working on making a DQMC version of https://github.com/crstnbr/MonteCarlo.jl/blob/master/example/Ising2D.jl. Currently, the documented interface for DQMC says that I specify beta and delta_tau and then it calculates slices from their quotient and slices must be an integer. It's annoying that one has to fine tune delta_tau so that beta / delta_tau is an integer. I propose that this should just be rounded, especially because due to floating point error, choosing delta_tau = beta / 500 does not always mean beta / delta_tau can be converted to an integer.

[carstenbauer]

Thanks for bringing this up. This should be discussed and handled in one way or another. In my private dqmc code I can either specify beta or the number of slices, to avoid rounding error situations.

[carstenbauer]

I'm wondering whether we should at least produce a warning when rounding. After all round does more than just correcting floating point numerical errors.

Example: beta/delta_tau = 3.321/0.1. Arguably not very realistic but technically allowed. It is not clear to me what the users wants in this case. An error/warning would probably be appropriate. Just setting slices to 33 with no warning/error could potentially be misleading.

Maybe we should even look at the difference beta/delta_tau - round(beta/delta_tau) and check that it is "floating point error small". If yes, round, otherwise, warn/error.

Any thoughts?

[MasonProtter]

I'm wondering whether we should at least produce a warning when rounding. After all round does more than just correcting floating point numerical errors.

Yeah, this branch is actually just a local change I made so that a script I'm testing could run. There's definitely a lot more we can do to make it clear to a user what is going on.

Putting your above comments together, it seems that a nice solution would be to have three separate methods concerning beta, delta_tau and slices.

• User specifies beta and slices. We then compute delta_tau.
• User specifies delta_tau and slices. We then compute beta.
• User specifies beta and delta_tau. We then compute slices. With this method, we could do something like @assert beta/delta_tau ≈ round(beta/delta_tau), or we could emit a warning, or we could ask that the user also provide their own rounding function. That way they can choose between say floor, ceil and round or make a function like myround(x) = x ≈ round(x) ? round(x) : error(" ... ")

[codecov]

Codecov Report

Merging #47 into master will increase coverage by <.01%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master      #47      +/-   ##
==========================================
+ Coverage   74.61%   74.61%   +<.01%     
==========================================
  Files          25       25              
  Lines         969      981      +12     
==========================================
+ Hits          723      732       +9     
- Misses        246      249       +3

Impacted Files	Coverage Δ
src/flavors/DQMC/DQMC.jl	73.55% <75%> (+0.15%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b7144bc...8069c90. Read the comment docs.

[MasonProtter]

Okay, so it took some really ugly conditionals and whatnot since we can't dispatch on keyword arguments, but I got everything working. The interface I went with for now is

• User specifies beta and slices. We then compute delta_tau.
• User specifies delta_tau and slices. We then compute beta.
• User specifies beta and delta_tau. We then compute slices with round(beta/delta_tau), and emit a warning if !(round(beta/delta_tau) !≈ beta/delta_tau).

Thoughts / comments?

[carstenbauer]

Looks good to me!

[MasonProtter]

Not sure why the Travis CI isn't running.

[carstenbauer]

Gazillions of github CI jobs :)

(They will probably fail)

[carstenbauer]

Can you fix the tests? It would also be good to have a few tests for the different keyword options.

[MasonProtter]

These tests pass locally on my machine (2017 MacBook Pro i5 on MacOS Catalina). Not sure what's wrong. Possibly related to BLAS / LAPACK non-determinism.

[carstenbauer]

Yeah, probably something like that. This exact test has also errored for one of the master test runs and magically worked again in the following run. Can you open a separate issue so that we don't forget to fix this?

I'll ignore the test failure here and merge.

[carstenbauer]

I opened an issue myself: #50