Closed ffreyer closed 3 years ago
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?
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
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).
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:
Operator
type (i.e. a symbolicc_{i}
)A[i, j]
)a * (b + c)
toa * b + a * c
, flatteningtestsintegration with measurementsOther Changes
GreensMatrix
to keep track of time slice indicesdagger(::GreensMatrix)
to simplify working withc^\dagger c
DQMCMeasurement
to allow passing greens iterators by typeCombinedGreensIterator
to have a variable starting and ending index and defer iterator creation to keep struct light