Breaking changes (new lattice, measurement fixes, more)

[ffreyer]

Main Goals of this pr are now:

• [x] update to BinningAnalysis 0.6 (closes #130 and #166)
• [x] fix time integrals for susceptibilities
• [x] rework the lattice interface
  • add unit cell information
  • streamline the loading/saving (i.e. avoid the number-by-number saving/loading that LatPhysLattice currently has)
  • probably go for more or less feature data parity with LatticePhysics (maybe allowing direct conversion back and forth?)
• [x] rework/update lattice iterators to include unit cells
  • move cache into lattice
  • change iterator cache keys to enum, symbols or strings for type stability and startup performance
  • maybe add caching for positions, directions, neighbors, reciprocal discretization
  • [x] cleanup/small things
  • superfluid density
  • hopping_directions maybe not worth optimizing
  • directions(iter, lattice) should maybe exist
  • Fourier transform for measurements expensive during simulation, moved elsewhere post simulation
• [x] optimize measurements/minor measurement rework
  • add flavor iterators to make it possible to move sums over flavors from an inner loop to an outer loop (which is more cache friendly since flavors generate large jumps in indices)
  • add kernel methods specialized on the Greens function type to avoid custom indexing
  • reduce number of hopping matrix lookups in current current correlation kernel (using T Hermitian)
  • performance annotations (inline, propagate_inbounds, fastmath, inbounds)
  • add EachBondPairByBravaisDistance for better measure performance (?) and faster analysis of CCS
• [x] Move post simulation analysis tools into separate package https://github.com/ffreyer/MonteCarloAnalysis
  • Fourier transforms
  • superfluid density computation
  • Makie helpers
  • DataFrame constructor
  • loading from (multiple) paths

And since the lattice changes will most likely be breaking I'll get some other breaking stuff done.

• [x] remove dependency on MonteCarloObservable (closes #76)
• [x] remove JLD support

General changes/TODO:

• [x] Add Git tag to save files
• [x] Fixed some types. (type promotions, type instability)
• [x] Improved performance of EachLocalQuadByDistance a bit
• [x] Now skipping for the global updates check when none are present
• [x] maybe take a closer look at errors (test and potentially fix error consistency vs ED (still ~$2\Delta\tau^2$), maybe use jackknife)
• [ ] fix problems/inconsistencies in ALF crosscheck
• [x] remove cases of saving a custom type - it just ends up making things difficult (saving update types is the latest problem, holding back #158)
• Use StableRNGs for tests (or use random seeds where applicable) This doesn't really work for us because most of our random's happen inside the library
• [x] Reduce reliance on Random.seed! in tests (remove DQMC checks vs hardcoded values, allow larger errors, don't check random confs)
• [x] test JLD2.load() at the start instead of loading data piece by piece
• remove flv and model from kernel functions. Since mc is passed this information is available and usually doesn't do much but bloat the call signature doesn't need to happen here
• [x] update docs
• [x] optimize measurements
• [x] switch to CodecLz4 for faster compression (but larger file size)
• [x] optimize nearest_neighbor_count and hopping_directions
• [x] optimize directions
• [x] add ED check with Honeycomb lattice to test lattice with basis

[ffreyer]

JLD2.load seems to be about 30% faster than loading things on demand for a 4MB file.

[ffreyer]

Maybe I should add serialize to BinningAnalysis

[ffreyer]

The last two commits are performance tweaks for measurements/EachLocalQuadByDistance. For a 4x4 lattice with 4 sites per unit cell the sweep timing stayed consistent at ~0.013s. During measurements the timings with every measurement are:

• before pr: ~1.5s/sweep
• before last two commits: ~2.5s/sweep
• current: 0.4s/sweep

This leaves the time per iteration of the lattice iterator for pairing susceptibilities at around 7ns if I'm not mistaken. Explicitly optimizing loop order for a given kernel can still give better performance here, but I'm not sure if that's worth it.