Revamp type/simulation structure

[ffreyer]

Currently DQMC (and MC) is the root type for a simulation, meaning it holds a bunch stuff together while also representing the algorithm used. This leads to some problems of availability, i.e. in a couple of places we want to dispatch on the algorithm, but it's not available (we dispatch on Type{<: MonteCarloFlavor} instead) and in some others we need parameters that have not yet been generated.

I've thought about revamping things a bit in #107 and I wanted to collect some of those thoughts here.

Currently existing structures:

Lattice

The lattice is self contained and can be created with just a lattice size and lattice type. All good.

Model

The model currently holds the lattice but only uses it create some temporary storage. Maybe this could be moved into an init!() function and become self contained? Difficulty here is eltype.

Measurements

Measurements are kind of a mess right now. I want to avoid re-running time displaced greens iterators and duplicating lattice iterators which has made things quite complicated. Both however are constructed when the simulation is ran, so they should be fairly detached. What isn't detached is the recorder, i.e. LogBinner or FullBinner from BinningAnalysis, as those are created with a zero-element. Maybe we could add some functionality to BinningAnalysis to resize those at a later point, but that leaves an eltype problem.

LatticeIterator

Requires the lattice and sometimes the model to know the number of flavors.

Updates

Are fully detached at this point.

Update scheduler

Only requires updates on construction.

Configuration recorder

Requires type information of the compressed configuration.

(Unequal time) Stack

Requires a bunch of type information (for greens, hopping and interaction matrices) from model + algorithm. Needs number of sites, flavors, time slices and safe_mult on initialization. Conceptually part of the algorithm.

New or revamped structures

Algorithm / MonteCarloFlavor / Engine

I think it would be good to bundle up things that are specifically needed by the algorithm. For DQMC this would be the stack, unequal time stack, some parameters and some analysis variables.

(Monte Carlo) Simulation

This would be the outer most wrapper which brings everything together. It would contain:

• Some (or all?) parameters.
• The configuration as both MC and DQMC have it
• A configuration recorder
• Measurements
• the algorithm / Monte Carlo flavor / engine or whatever we may call it
• the model if we can detach it from the algorithm
• the update scheduler
• the lattice
• perhaps some more analysis tools

Parameters

Parameters are a bit weird, conceptually they should be attached to the types that need them but it might also be good to have them all in one place. Sorting the parameters we have to structs they belong to:

• Lattice: linear system size L (, number of sites N)
• Model: model parameters U, t, µ etc
• DQMC: performed checks (sign problem, propagation error), safe_mult, delta_tau, number of time slices
• Simulation: number of thermalization & measurement sweeps, measure rate, print rate, saving options (checkpoint, early save, filename, overwrite, rename)
• Recorder: recording rate (this should probably be detached from measure rate)
• Measurements (measure rate?)
• Scheduler: (types and order of updates, adaptive configuration)

It might also be interesting to make "Simulation recipes" where you can define parameters (+ some types like model, lattice, etc) in a Dict-like fashion and auto-complete missing ones. I could see something like this working well with what I messed around with in https://github.com/ffreyer/ParameterFiles.jl to generate a set of parallel simulations.

A useful concept perhaps is a deferred creation of structs. One could generate a Specification(constructor, args, kwargs) and later call constructor(extra_args, args...; kwargs...) to create the object.