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.

Sign up for GitHub

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

Jump to bottom

Having to send a time into the function for constraints is a design failure. #207

Closed
KristofferC opened this issue May 8, 2018 · 8 comments · Fixed by #459
Closed

Having to send a time into the function for constraints is a design failure. #207

KristofferC opened this issue May 8, 2018 · 8 comments · Fixed by #459

Comments

@KristofferC
Copy link
Collaborator

This should just be handled by sending in a closure f(x) = f(x, t, ...).
@fredrikekre
Copy link
Member

So t should be a global variable then?

@KristofferC
Copy link
Collaborator Author

No, t can be a local variable and you send in the closure x -> f(x, t). Just like always when you need to pass parameters.

@fredrikekre
Copy link
Member

But we give the function only once, when creating the condition.

@KristofferC
Copy link
Collaborator Author

Yeah but you can change t afterward. Perhaps that's what you meant.

@fredrikekre
Copy link
Member

TIL

@fredrikekre
Copy link
Member

Another proposal: Let user define f(x, args...; kwargs...) -> value and then call update!(ch, args...; kwargs...) as appropriate. update! would then splice in the x as f(x, args...; kwargs...).

fredrikekre added a commit that referenced this issue May 14, 2018
@fredrikekre
call update with arbitrary arguments, fix #207
b91a365
fredrikekre added a commit that referenced this issue May 14, 2018
@fredrikekre
call update with arbitrary arguments, fix #207
bfeead4
@fredrikekre
Copy link
Member

Maybe a NamedTuple is appropriate? User defines f(x, nt) -> value and call update!(ch, nt).

@KristofferC
Copy link
Collaborator Author

Maybe, but I wonder if not just propagating args...; kwargs... (like you have in the PR I think) is easier in that case.

fredrikekre added a commit that referenced this issue Mar 7, 2022
@fredrikekre
ConstraintHandler: More flexible update! for runtime parameters
5f53a79 
This allows functions for Dirichlet boundary conditions to accept a
third argument with parameters that are not available when defining
the constraint (e.g. data that are computed/updated/changed during the
simulation). `update!` can now be called with a third argument which
is passed along to the constraint function `f`, for example
`update!(ch, t, p)` will call `f(x, t, p)`.

Fixes #207, closes #213.
@fredrikekre fredrikekre mentioned this issue Mar 7, 2022
Closed
@fredrikekre fredrikekre mentioned this issue Dec 21, 2022
Merged
fredrikekre added a commit that referenced this issue Dec 21, 2022
@fredrikekre
Implicitly call update!(ch) in close!(ch) and allow f(x).
0bc5e29 
This patch adds an implicit call to update! when closing the
ConstraintHandler. This step is easy to forget, in particular if your
problem doesn't depend on time at all. In addition, it is now possible
to specify constraint functions of the form f(x) directly.

Fixes #207, closes #213, closes #435.
fredrikekre added a commit that referenced this issue Dec 22, 2022
@fredrikekre
Implicitly call update!(ch) in close!(ch) and allow f(x). (#459)
70f69dd 
This patch adds an implicit call to update! when closing the
ConstraintHandler. This step is easy to forget, in particular if your
problem doesn't depend on time at all. In addition, it is now possible
to specify constraint functions of the form f(x) directly.

Fixes #207, closes #213, closes #435.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
2 participants
@KristofferC @fredrikekre