Measurement tweaks & Auto Wicks experiments

[ffreyer]

Automatic Wicks theorem

The current measurement situation is that you apply Wicks theorem yourself to an observable you want to measure and add a function implementing the result. These functions aren't saved, but assumed to exist in the correct form when measurements are loaded.

I'm hoping that I can figure out a less risky way to save these kernels by messing around with Symbolic math. And while I'm at it, I also want to try generating kernels from an operator expression - i.e. expanding an operator expression, applying Wicks theorem, replacing expectation values with greens elements and lowering that to a function. I hope that also brings some more confidence to the Wicks-expanded formulas. It's easy to mess them up on paper, but they follow strict rules a computer can easily follow.

TODO:

• [x] Operator type (i.e. a symbolic c_{i})
• [x] figure out spacial indices vs spin indices vs time indices
• [x] Literals (i.e. numbers)
• [x] ArrayElement (i.e. a symbolic A[i, j])
• [x] ExpectationValue (mostly as a marker)
• [x] expanding a * (b + c) to a * b + a * c, flattening
• [x] Wicks theorem
• [x] transformation to Greens function elements
• [x] transformation to Julia function
• [x] replacements (e.g. G[up, down] -> 0)
• tests
• integration with measurements
• [ ] Fix 1.5 tests?

Other Changes

• add GreensMatrix to keep track of time slice indices
• add dagger(::GreensMatrix) to simplify working with c^\dagger c
• adjust DQMCMeasurement to allow passing greens iterators by type
• adjust CombinedGreensIterator to have a variable starting and ending index and defer iterator creation to keep struct light

[ffreyer]

I think I'll just adjust DQMC measurements to carry around an expression version of their kernel for saving. (I.e. quote ... end the kernel function) That way it can be saved and loaded I assume, making measurements more consistent.

The automatic conversion stuff works, but I think it's hard to make that optimal. I'll probably leave it in as an experimental tool.

Also wtf is going on with 1.5 tests?

[ffreyer]

I'm not so sure if carrying around kernels as expressions is a good idea. If you want to evaluate them as anonymous functions you need to use invokelatest or you will run into world age errors. That however comes with performance cost, which I don't want to pay on a functions that's at the bottom of a call stack.

Alternatively you can eval in the global scope, which I'm doing atm. This will update the world age so you don't need invokelatest. However you have to be careful with function names. I think I will automatically generate unique names to avoid accidental and failed replacements.

Also while I'm at it I should probably adjust measurements < a b > to < a b > - < a > < b > since that seems to be what people actually use

[ffreyer]

Also while I'm at it I should probably adjust measurements < a b > to < a b > - < a > < b > since that seems to be what people actually use

DQMC has a fermionic expectation value and a Monte Carlo average. Writing the term as << a b > - < a > < b >>, i.e. applying the above to fermionic expectation values and applying the Monte Carlo average afterwards does not match up with ED. Applying the change as << a b >> - << a >>< < b >> should be in line with ED and should already be possible (using the relevant magnetization or occupation values).