-
Notifications
You must be signed in to change notification settings - Fork 9
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
Fix boundary conditions #98
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for tackling this, it's long been a major annoyance. However, I tried out your change elsewhere (in test_stokes.py
) and find that that is somehow broken. I expected stage value formulation to fail in that test since we haven't done similar updates to how that handles BC, but the classic stage-derivative form you attempted to fix is failing here. Please take a look.
f40e1a9
to
3f618be
Compare
3f618be
to
52d56ef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is very very clean. Except we have a technical corner case about no longer being able to do bounds-constrained projections for discrete boundary conditions.
gdats_cur[i] = gblah_cur[i][0] | ||
Vbigi = stage2spaces4bc(bc, V, Vbig, i) | ||
gcur = replace(bcarg, {t: t+C[i]*dt}) | ||
gcur = gcur - Vander_col[i] * bcarg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modulo answers to @rckirby 's questions about the bounds-constrained case, this all makes sense to me. Seems much cleaner than what we were doing, and resolves a few things as well! Many thanks!
Right now, our only use cases are constant upper and/or lower bounds. I
think we should not make the perfect the enemy of the good. For now, if
you have a `Function` in the upper or lower bound and update it before the
solver is called, the new bounds will be in place. We don't have a
mechanism for `bounds` being an expression, but that's not an issue because
1) FD's bounds mechanism is the same and 2) you'd need a bounds-constrained
projection to pull it off..
…On Sun, Oct 20, 2024 at 7:57 AM ScottMacLachlan ***@***.***> wrote:
***@***.**** commented on this pull request.
Modulo answers to @rckirby <https://github.com/rckirby> 's questions
about the bounds-constrained case, this all makes sense to me. Seems much
cleaner than what we were doing, and resolves a few things as well! Many
thanks!
—
Reply to this email directly, view it on GitHub
<#98 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4XUL4TIQNOBDIGBIJITDDZ4OSCRAVCNFSM6AAAAABP5J26U6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGOBQGQ2DENRXG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
To allow
DirichletBC(V, 0, ...)
, the special case requires no computation for stage boundary condition, everything should be zero