carstenbauer/dqmc

Determinant quantum Monte Carlo code for simulating an antiferromagnetic quantum critical metal

     o.OOOo.    .oOOOo.   Oo      oO  .oOOOo.  
     O    `o  .O     o.  O O    o o .O     o  
     o      O o       O  o  o  O  O o              Determinant quantum Monte Carlo code
     O      o O       o  O   Oo   O o              for simulating quantum critical metals!
     o      O o       O  O        o o           
     O      o O    Oo o  o        O O              (In pure Julia!)
     o    .O' `o     O'  o        O `o     .o   
     OooOO'    `OoooO Oo O        o  `OoooO'  

Build Status	License

Determinant quantum Monte Carlo (DQMC) code for simulating a quantum critical metal, a Fermi sea coupled to antiferromagnetic bosonic fluctuations, in two spatial dimensions.

A version of this code has been used to produce (most of) the results in the following paper:

Hierarchy of energy scales in an O(3) symmetric antiferromagnetic quantum critical metal: a Monte Carlo study
Carsten Bauer, Yoni Schattner, Simon Trebst, Erez Berg

Performance comparison

The figure below shows a comparison of three different DQMC codes written in C++, Fortran, and Julia. Specifically, it shows the time it takes to perform one sweep of local updates in space and imaginary time for a spin-fermion model (studied in the paper linked above). All kinds of special features, such as a small magnetic flux to improve finite size effects, are turned off.

Codes:

• C++ code by Max Gerlach (repository, used in this paper).
• Private Fortran code by Yoni Schattner (used in this paper).
• Julia DQMC implementation in this repository.

Settings

Environmental variables:

• LATTICES: folder with ALPS XML lattice files (mandatory unless you're me)
• WALLTIME: Set a walltime limit for the algorithm. (optional)
• JULIA_DQMC: path to the root of this repo (optional, currently only used in live.jl/ipynb and test_live.ipynb to activate the environment)

Modes

Special modes as indicated by fields in dqmc.in.xml:

• EDRUN: if set to true, temporal gradients and quartic term in bosonic action are turned off.
• TIMING: stop after thermalization phase and report speed and allocations of all major functions.

dqmc's Issues

Replace `rem_eff_zeros!` by `droptol!`

SparseArrays provides a function droptol! which does exactly what we need. However, only for sparse arrays. Replace custom function if possible.

potential performance updates

I'll update this whenever I find something.

• In local_updates, rather than calculating log(exp_delta_S_boson) the action difference could be saved to a variable and the log could be dropped.
• eVop1, eVop2 and eVop1eVop2 are only actively used in calc_detratio as far as I can tell. Having just interaction_matrix_exp_op!(mc, new_op - p.hsfield[:,i,s.current_slice], +1., s.eVop1eVop2) should be enough.
• Mtmp, Mtmp2 are only used in detratio. Mtmp2 could be removed if mul!(s.Mtmp2, s.delta_i, s.Mtmp) becomes lmul!(s.delta_i, s.Mtmp). M should also be fine to use instead of Mtmp.

Move `Gt0` and `G0t` to `mc.s.meas`

Also, get rid of BBetastack stuff in stack.jl as it doesn't seem to be used.

Make tests less strict

A couple of tests "failed" on cheops because of tiny deviations from the expected results. Maybe we shouldn't use the default settings of isapprox but maybe a higher reltol.

Bad TDGF for safe_mult != 1

DQMC in.xml file

<?xml version="1.0" encoding="utf-8"?>
<SIMULATION>
  <PARAMETERS>
    <PARAMETER name="SAFE_MULT">10</PARAMETER>
    <PARAMETER name="C">3.0</PARAMETER>
    <PARAMETER name="SLICES">100</PARAMETER>
    <PARAMETER name="L">8</PARAMETER>
    <PARAMETER name="MU1">-0.5</PARAMETER>
    <PARAMETER name="SWEEPS">20000</PARAMETER>
    <PARAMETER name="WRITE_EVERY_NTH">10</PARAMETER>
    <PARAMETER name="GLOBAL_RATE">5</PARAMETER>
    <PARAMETER name="DELTA_TAU">0.1</PARAMETER>
    <PARAMETER name="SEED">4729339882041979125</PARAMETER>
    <PARAMETER name="WARMUP">1000</PARAMETER>
    <PARAMETER name="GIT_COMMIT">ded27567d0537da42f7e175324b92c2925a69e6f</PARAMETER>
    <PARAMETER name="MU2">0.5</PARAMETER>
    <PARAMETER name="HOPPINGS">1.0,0.5,-0.5,-1.0</PARAMETER>
    <PARAMETER name="GLOBAL_UPDATES">TRUE</PARAMETER>
    <PARAMETER name="OPDIM">3</PARAMETER>
    <PARAMETER name="U">1.0</PARAMETER>
    <PARAMETER name="BFIELD">true</PARAMETER>
    <PARAMETER name="CHECKERBOARD">true</PARAMETER>
    <PARAMETER name="R">3.864</PARAMETER>
    <PARAMETER name="LAMBDA">2.0</PARAMETER>
  </PARAMETERS>
</SIMULATION>

There are issues for safe_mult > 1:

For comparison, safe_mult = 1:

Revisit `fermion_measurements.jl`

Method definitions contain lots of redundancies.

Also, we probably want to separate the stuff integrated into the DQMC from stuff that works on any arbitrary configuration in a postprocessing way.

Lattice generation needs to be updated for v1.0+

At least gen_square_lattice.xml.jl is not compatible.

F.Q instead of Matrix(F.Q)

This speeds up (and reduces allocations of) decompose_udt! a lot.

However, is F.Q. fine in our application. This will probably introduce type instabilities....

Try in a different branch.

using QMC in tests

using QMC in tests instead of include("setup_dqmc.jl").

More tests

• Fermion measurements
  • ETGF
  • ETPC and ZFPC
  • ETCDC and ZFCDC
  • permute_greens
  • fft_greens
• Boson measurements
  • chi_dyn
  • chi_static
  • binder
  • get_frequencies_and_momenta
• LinAlg
  • inv_one_plus_two_udts! etc.

O(2) / O(1) tests

• get core files like interactions.jl, lattice.jl etc. to ~100%

NNhoppings tests

• start with lattice.jl

Generic checkerboard tests

`write_every_nth` sweeps instead of ud-sweeps

Currently, write_every_nth is in terms of up-down-sweeps not sweeps. We should change this.

Add tests dependencies to Project.toml

For example, BenchmarkTools is used in tests_linalg.jl.

Set up Travis and Co

Get rid of `inv(X)` everywhere

Replace it by \, /, or ldiv!(out, lu!(l), r).

In particular, in calculate_greens.

Suppress linalag warnings in runtests

Consider dumping reduced `Gk` instead of `G` in DQMC

Real-space G is much larger than Gk. Typically, we don't use G at all (exceptions being machine learning etc). For ETPC we don't need G, right?

Superfluid density

Now that we have ZFCCCs, let's calculate the superfluid density.

Parametrize on model

Along the lines of

• create folder models with SDW.jl, Hubbard.jl, HubbardAttractive.jl....
• disentangle interactions and action part etc. from main code into these files

Try replacing `A / B` by `rdiv!` in `inv_sum_udts_scalettar!`

There currently is no rdiv! for matrices. However, it has been discussed here:

https://discourse.julialang.org/t/non-allocating-a-b-where-a-and-b-are-matrices/21532/6

Maybe this way we can decrease the number of allocations in calc_tdgfs!.

overwrite=true leads to endless loop

If in-steps run doesn't finish, intermediate results will be overwritten after resubmission.

That means that currently overwrite only works for in-one-go runs.

Calculate ETGF on the fly if necessary

In the spirit of #15, if there are no etgfs in dqmc outfile, calculate etgfs on the fly.

Make dqmc resumable without greens in .out.h5.running

Related to #15. We are "wasting" TB of space!

Replace `eye_full` and `eye_flv` by UniformScaling `I`

Check `calc_tdgfs!` with interactions

(and with Bfield/Checkerboard)

Use UDT from StableDQMC.jl

Think about this.

Optimize `calc_all_greens_explicit`

This is also code orga because current calc_all_greens uses dqmc stack and logic (e.g. calculate_greens etc.)

Optimize `calc_tdgfs!`

Preallocate stacks like BT0Inv_u_stack etc.?

Resume dqmc tests

Automate arch/resume_test.

Enable TDGF measurement in measure.jl

Tests for measure script related stuff

Unify `measure_greens` and e.g. `etpc!`

• measure_greens gives actual ETGF
• etpc! gives ETPC
• calc_tdgfs! gives actual TDGFs

Unify this mess.

Disadvantage: All jupyter notebooks and scripts use this currently.

Set up documentation

By this I mean a documentation a la Documenter.jl.