You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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::HubbardInteractionendstruct GenericHoppings
# use bond labels as key to this dict (with some default key fallback)
parameters::Dict{Symbol, Number}endstruct HubbardInteraction
U::Float64endstruct SomeHubbardField
interaction::HubbardInteraction
internals...endfunctionfield_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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: