-
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
Storing boundary conditions inside fields #606
Comments
Copy pasting a comment by @glwagner from #601 so it doesn't get lost in a closed PR:
|
Both the grid specification and the boundary condition API will change when we have the grid topology, because there won't be a need for monstrosities like I agree we should probably keep the The We will also need a function that does new_field = with_boundary_conditions(old_field, new_field_boundary_conditions) that creates a new The correct implementation of |
Another change that we may want to wrap into the changes discussed in this issue (because it also affects We need to change this definition so that all halo points are located outside the domain for face-centered fields. In other words, parent arrays need to have This change is necessary for the correct evaluation of the pressure Poisson equation in bounded domains and for general equations / boundary conditions. There will also need to be concomitant changes in |
Just a quick thought: mathematically it sometimes makes sense to use boundary conditions to reduce the size of the function space a variable can live in, i.e. considering a certain field to be in the space of functions that have zero value (or zero normal derivative) at a boundary. Physically, though, I'm not sure this is so useful, since many systems have non-trivial boundary conditions, including nonlinear conditions and conditions involving multiple fields. Then the notion of a certain BC even "belonging" to a certain field is a little less clear... you may just have a set of fields that need to collectively satisfy a set of conditions on the boundary. E.g. thermal radiation conditions (heat flux depends nonlinearly on temperature) |
The issue of whether fields should store their boundary conditions was brought up in #601. We've discussed this idea before but I'm opening this issue to see if this is something we want to pursue.
Note: Moving boundary conditions to fields should happen alongside or after the introduce of grid topologies (#489) which would decouple the grid topology from the boundary conditions (although some boundary conditions will be determined by the grid topology).
I think it's a good idea that will pay off in code clarity and ease of use.
fill_halo_regions!
will simplify as we no longer need to pass in both a field and boundary conditions, just the field itself.complete_pressure_correction_step!
.ModelBoundaryConditions
can only grow in complexity.Another reason to consider having fields carry their boundary conditions around is to avoid having to build more boundary condition machinery, i.e. more solution_and_model_boundary_conditions.jl when new fields are added or new models are added (e.g. #605).
User API may have to change as well, although I don't think we should get rid of the current
boundary_conditions
Model kwarg unless we have a better interface.The text was updated successfully, but these errors were encountered: