Closed ffreyer closed 2 years ago
Perhaps it would make sense to store iteration information with the lattice have LatticeIterator's be a slim interface to that information. That way the iterator would often just be an empty struct, and the necessary data would be initialized in measurements are grouped in generate_groups
.
I implemented a LatticeIteratorCache
attached to DQMC
in #137 which holds almost all the necessary data. So lattice iterators are now essentially free in terms of memory and we don't need to make them unique anymore. I also implemented template versions which are probably unnecessary.
For greens iterators it's not a memory problem. The iterators themselves are tiny. Instead it's a performance problem - we don't want to iterate through the same greens iterator multiple times. And if we group measurements based on their greens iterators we naturally reduce that to just one.
I want lattice and greens iterators to be created just once since they can be rather large. In the case of
CombinedGreensIterator
it's also very worth it to group measurements that use it.The current implementation achieves this by saving types instead of objects in measurements and later resolving those to types. This works but is kind of awkward and complicated. With the addition of wrapper types for lattice iterators this has become even more awkward. Some of those wrappers require data from user input, leading to half-constructed types.
The alternative would be to use a global lookup array or perhaps dictionary. Conceptually we would want something like
lookup = Dict(hash(dqmc, lattice_iterator_type) => lattice_iterator)
, thoughhash(dqmc)
would change as measurements are added.