-
Notifications
You must be signed in to change notification settings - Fork 195
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
Major refactor of FieldBoundaryConditions
#1843
Conversation
Ok, this definitely needs bumping up a minor release |
Great job. I’ll try to help out cleaning up the rest. |
Co-authored-by: Navid C. Constantinou <[email protected]>
…ananigans.jl into glw/refactor-field-bcs
@glwagner, regarding the ERROR: LoadError: UndefVarError: bc not defined in the Docs, is it related to |
I believe it should be OK now. Commit e39c509 was the crucial fix 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.
I approve.
I applaud the tests/jldoctests.
I'm a bit skeptical whether I have the expertise to be as critical.
Nice find! |
I'm going to clean up the validation experiments for the new syntax and then this is ready. |
The main point of approval here is whether we think the API change is positive. I think you are one of the best people anywhere to judge this change. The other change, which is adding a field Note that it's possible to implement a field |
We should wait for this to be merged before we move on with #1847, right? |
When we merge this we will have to update the example in #1847 but otherwise this is just an aesthetics change and has no impact on output, so we don't need to wait for it. |
This PR introduces a major refactor of
FieldBoundaryConditions
and changes the user API.The
grid
and field location are no longer necessary to buildFieldBoundaryConditions
. This means that the constructorsTracerBoundaryConditions
,UVelocityBoundaryConditions
, etc, are gone. Instead we have onlyFieldBoundaryConditions
, which is used likeThere's also a new constructor
AuxiliaryFieldBoundaryConditions
which takes the place ofComputedFieldBoundaryConditions
and is now the default forField
andComputedField
. The difference is thatAuxiliaryFieldBoundaryConditions
havenothing
instead of anImpenetrableBoundaryCondition
inBounded
directions when they're located on faces.Under the hood the
FieldBoundaryConditions
struct is "flattened" so there's no moreCoordinateBoundaryConditions
. In addition, a new fieldimmersed
is added toFieldBoundaryConditions
in addition toeast
,west
, etc. This will be used to support boundary conditions on immersed boundaries in the future.There's still quite a few validation experiments to clean up and probably some lingering issues with tests, but I was able to get the examples to run so I thought it was the right time to open the PR.
On the API changes: it seemed like a positive change that we don't need
grid
in the boundary conditions constructor, and that we only have one nameFieldBoundaryConditions
rather than 4. However, if others feel they liked the old API, we can add convenience functionsTracerBoundaryConditions
, etc back to the source.