Store the boundary conditions as a property of a cell variable about pyfvtool HOT 8 CLOSED

Thinking about the inclusion of the information on boundary conditions inside the CellVariable object, I realized that it may be an idea to have the boundary conditions fully handled by the CellVariable object: creation of BoundaryConditions object stored inside the CellVariable structure, definition of the a, b, c etc., pre-calculation/updating of the BoundaryConditionsTerm matrix + RHS etc. etc.

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.

from pyfvtool.

Concerning CellVariable.bc_to_ghost() and CellVariable.BC2GhostCells() (cell.py), these have perhaps been superseded by cellValuesWithBoundaries (boundary.py)? It seems to serve a similar function, and does indeed take into account the defined boundary conditions when assigning values to the ghost cells.

from pyfvtool.

Concerning CellVariable.bc_to_ghost() and CellVariable.BC2GhostCells() (cell.py), these have perhaps been superseded by cellValuesWithBoundaries (boundary.py)? It seems to serve a similar function, and does indeed take into account the defined boundary conditions when assigning values to the ghost cells.

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.

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 totally agree. I cannot remember any use cases that a boundary exist without a CellVariable (well, for steady-state problems we have the BC before having the CellVariable but later the solution will be a cell variable).

from pyfvtool.

[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?

I am in favor of ghost cells.

from pyfvtool.

[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?

I am in favor of ghost cells.

So am I.

from pyfvtool.

The CellVariable.init() code requires some further cleaning up I think

What I prefer to do is to initialize the CellVariable with a boundary condition (Neumann) and later adjust the values of the -infamous- a, b, c. It is the workflow that we have more or less in all examples. We can at some point write some utility functions to do the adjustment in more pythonic ways, e.g. by accepting dictionaries; for example:

BC = {
    "left": {"type": "Dirichlet", "value": 0.0},
    "right": {"type": "Neumann", "value": 0.0},
}

from pyfvtool.

I agree.

I have a relatively simple plan for embedding the boundary condition structure in the CellVariable, creating it if it is not supplied externally. It will be initialized with default "no flux" (Neumann) values. Then, it can be fine-tuned via the usual left right etc. a, b, c mechanism. Finally, we call a method which we may name apply_BCs that re-calculates the ghost cell values (via cellValuesWithBoundaries) and even pre-calculates the BoundaryConditionsTerms M and RHS.

This could later be embellished in more pythonic ways, as you suggest.

from pyfvtool.

I agree.

I have a relatively simple plan for embedding the boundary condition structure in the CellVariable, creating it if it is not supplied externally. It will be initialized with default "no flux" (Neumann) values. Then, it can be fine-tuned via the usual left right etc. a, b, c mechanism. Finally, we call a method which we may name apply_BCs that re-calculates the ghost cell values (via cellValuesWithBoundaries) and even pre-calculates the BoundaryConditionsTerms M and RHS.

This could later be embellished in more pythonic ways, as you suggest.

Love the idea! Simple and elegant.

from pyfvtool.