-
Notifications
You must be signed in to change notification settings - Fork 191
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
More convenient BoundaryFunction functionality #699
Conversation
…r or velocity fields. Allows boundary function to have embedded parameters
Codecov Report
@@ Coverage Diff @@
## master #699 +/- ##
==========================================
+ Coverage 71.12% 78.55% +7.42%
==========================================
Files 122 122
Lines 2386 2485 +99
==========================================
+ Hits 1697 1952 +255
+ Misses 689 533 -156
Continue to review full report at Codecov.
|
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.
Definitely an improvement if users don't have to worry about specifying the field location, although I guess it comes at the expense of extra constructors.
A potential source of confusion (?) is that
UVelocityBoundaryCondition
is only needed for simple boundary functions. We could alleviate this with more verbosity; egUVelocityFunctionBoundaryCondition
or something silly like that. But I'm hesitant because we already seem to have a verbosity problem. We need better design, not more words...It only just occurs to me that perhaps what we want are types like
Tracer()
,U()
,V()
, andW()
. We might use these to classify boundary conditions and forcing functions... ?
Yeah I'm not sure right now what a good user interface would look like. Those types could help. Might be good to discuss user interface design for this in an issue?
I've also added a
parameters
field toBoundaryFunction
.
👍
Since this is a breaking change (?) do you want to bump to version 0.27.0 in this PR? |
Will do. |
Ready to merge. |
Ah, it isn't a breaking change btw (it just adds a wrapper around existing functionality) --- but it does add a new feature, so 0.27.0 could still be warranted. |
This PR makes it a bit easier to prescribe
BoundaryFunction
s by providing field-specific constructors. The field-specific constructors "know" about the locations of tracers and velocity fields and relieve the user of the (often confusing) task of specifying theBoundaryFunction
location.I also added a further wrapper around
BoundaryCondition
to permit patterns likeIt doesn't look perfect to me, but I do think it's progress over what the user had to do previously.
A potential source of confusion (?) is that
UVelocityBoundaryCondition
is only needed for simple boundary functions. We could alleviate this with more verbosity; egUVelocityFunctionBoundaryCondition
or something silly like that. But I'm hesitant because we already seem to have a verbosity problem. We need better design, not more words...I've also added a
parameters
field toBoundaryFunction
.(It only just occurs to me that perhaps what we want are types like
Tracer()
,U()
,V()
, andW()
. We might use these to classify boundary conditions and forcing functions... ?)