-
Notifications
You must be signed in to change notification settings - Fork 3
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
Store the boundary conditions as a property of a cell variable #36
Comments
Thinking about the inclusion of the information on boundary conditions inside the This would lead to a more logical workflow, where first the cell variable is created, followed by definition of the boundary conditions if required (only solution variables need boundary conditions). I think that such a solution may even be implemented without breaking the existing infrastructure. |
Concerning |
Indeed, it is the case. In the development sprint, I replaced some of the old functions with more +at least in my head+ logical ones. This is one of those cases.
I totally agree. I cannot remember any use cases that a boundary exist without a |
I am in favor of ghost cells. |
So am I. |
What I prefer to do is to initialize the BC = {
"left": {"type": "Dirichlet", "value": 0.0},
"right": {"type": "Neumann", "value": 0.0},
} |
I agree. I have a relatively simple plan for embedding the boundary condition structure in the This could later be embellished in more pythonic ways, as you suggest. |
Love the idea! Simple and elegant. |
In the discussion accompanying PR #34, the suggestion was made to include (a reference to) the boundary conditions (subclass of
BoundaryConditionsBase
) as a property of theCellVariable
to which these boundary conditions apply. At present, the definition of the boundary conditions is made separately from the cell variable, and applied explicitly in the user code, which requires recalling the specific boundary conditions object every time.User code may become more simple, readable and perhaps also more robust, if the boundary conditions were included in the cell variable. This might simply be achieved by including something like
self.BC = BC
inCellVariable.__init__()
[1], followed by adapting any other code where BCs are now specified explicitly such that it uses the stored BC where relevant.This should also be the opportunity to review and revise
CellVariable.bc_to_ghost()
andBC2GhostCells()
whose functioning is not very clear. AFAICS, these two methods are not used anywhere in the entire PyFVTool code base. Also, I find it strange that their name is a reference to boundary conditions (BCs), but no explicit boundary conditions are used by their code. These methods calculate the new value for the ghost cells (= boundary cells?) [2] by taking the average of that ghost cell with neighbouring inner cell and then storing that new value in the ghost cell. Perhaps, we can simply remove these methods, since they are not used?[1] Actually:
self.BC = arg[0]
/self.BC = None
, depending on how it is called. TheCellVariable.__init__()
code requires some further cleaning up I think...[2] Should we use consistent naming: use either the term 'boundary cells', or the term 'ghost cells' exclusively? Perhaps I am missing a subtlety here? Boundary cell is perhaps ambiguous: it may refer to the ghost cell or to the outermost inner cell?
The text was updated successfully, but these errors were encountered: