As things are now, the field represents most of the interaction, with only the prefactor being held by the model. The model mainly produces the hopping matrix and contains the lattice. It may make sense to separate these components more, specifically the field as it is the main driver of complexity.
For example:
struct HubbardModel <: Model
lattice::AbstractLattice # maybe move this to DQMC struct?
hopping::GenericHoppings
interaction::HubbardInteraction
end
struct GenericHoppings
# use bond labels as key to this dict (with some default key fallback)
parameters::Dict{Symbol, Number}
end
struct HubbardInteraction
U::Float64
end
struct SomeHubbardField
interaction::HubbardInteraction
internals...
end
function field_constructor(parameters, interaction::HubbardInteraction)
...
end
This would add HubbardInteraction as a proxy for creating a field. Making a new model with a Hubbard interaction could just reuse that type and not deal with anything field related.
As things are now, the field represents most of the interaction, with only the prefactor being held by the model. The model mainly produces the hopping matrix and contains the lattice. It may make sense to separate these components more, specifically the field as it is the main driver of complexity.
For example:
This would add
HubbardInteraction
as a proxy for creating a field. Making a new model with a Hubbard interaction could just reuse that type and not deal with anything field related.