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

Rework the BoundaryCondition interface #35

Closed
Tracked by #37
DanielVandH opened this issue Jun 3, 2023 · 0 comments · Fixed by #44
Closed
Tracked by #37

Rework the BoundaryCondition interface #35

DanielVandH opened this issue Jun 3, 2023 · 0 comments · Fixed by #44

Comments

@DanielVandH
Copy link
Member

It doesn't really make sense to try and support so many different ways of giving e.g. a Neumann boundary condition - is_neumann_type(type) = type ∈ (:Neumann, :N, :neumann, "Neumann", "N", "neumann") - bit much! I should just define e.g.

abstract type AbstractBoundaryCondition end 
struct Dirichlet <: AbstractBoundaryCondition end 
struct Neumann <: AbstractBoundaryCondition end 
struct DirichletDudt <: AbstractBoundaryCondition end 
# define is_dirichlet, etc. 

and simply go from there. It might even make more sense to force users to instead provide vectors of BoundaryCondition types, e.g. maybe instead of providing functions, types, and params separately, we extend the above so that

abstract type AbstractBoundaryCondition{F, P} end 
struct Dirichlet{F, P} <: AbstractBoundaryCondition{F, P}
     f::F
     parameters::P 
end
struct Neumann{F, P} <: AbstractBoundaryCondition{F, P}
     f::F
     parameters::P 
end
struct DirichletDudt{F, P} <: AbstractBoundaryCondition{F, P}
     f::F
     parameters::P 
end

I don't know if this better for the user experience, though. Maybe the former suggestion is fine.

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