Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split Models and Fields more #177

Open
ffreyer opened this issue Apr 28, 2023 · 0 comments
Open

Split Models and Fields more #177

ffreyer opened this issue Apr 28, 2023 · 0 comments

Comments

@ffreyer
Copy link
Collaborator

ffreyer commented Apr 28, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant