Is your feature request related to a problem? Please describe.
Currently, the mimetic operators (divergence and gradient) carry a legacy interface from their first implementations that did not consider periodic boundary conditions. For MOLE 2.0, we need to revisit the Octave/MATLAB and C++ APIs that is also driving the development of Python and Julia. We should start implementing these changes for MOLE 2.0 with the Octave/MATLAB. These changes are essential to complete the Octave/MATLAB to C++ parity work for at least for the gradient and divergence operators in uniform spaces, as well as for nonuniform discretizations.
As illustrated in the figure above;
For 1D, a call to grad with only three arguments calls the (1) grandNonPeriodic functional implementation (legacy call)
The newer grad function takes 5 arguments, where the user can declare whether Neumann (nc) or Dirichlet (dc) boundary conditions are present. If nc and dc are equal to 0, the (4) grandPeriodic functional implementation is called, else (1) grandNonPeriodic is called.
Similarly logic applies for 2D and 3D.
In addition, the functions marked in red, (2) and (3), can be replaced by 2 calls to gradNonPeriodic or 3 calls to gradNonPeriodic for the 2D, and 3D cases, respectively.
Describe the solution you'd like
The proposed solution is described in this second figure:
We propose to reduce the number of functions (for both gradient and divergence), following the schematic in the second figure. We could also consider to eliminate the calls to grad with 3 arguments, to grad2D with only 5 arguments, and to grad3D with 7 arguments, which may avoid conflicts with legacy code by requiring the user to always include the boundary information.
Either solution would help resolve the current API inconsistency.
Describe alternatives you've considered
See above
Additional context
This was already discussed in issue #303
Is your feature request related to a problem? Please describe.
Currently, the mimetic operators (divergence and gradient) carry a legacy interface from their first implementations that did not consider periodic boundary conditions. For MOLE 2.0, we need to revisit the Octave/MATLAB and C++ APIs that is also driving the development of Python and Julia. We should start implementing these changes for MOLE 2.0 with the Octave/MATLAB. These changes are essential to complete the Octave/MATLAB to C++ parity work for at least for the gradient and divergence operators in uniform spaces, as well as for nonuniform discretizations.
As illustrated in the figure above;
For 1D, a call to grad with only three arguments calls the (1) grandNonPeriodic functional implementation (legacy call)
The newer grad function takes 5 arguments, where the user can declare whether Neumann (nc) or Dirichlet (dc) boundary conditions are present. If nc and dc are equal to 0, the (4) grandPeriodic functional implementation is called, else (1) grandNonPeriodic is called.
Similarly logic applies for 2D and 3D.
In addition, the functions marked in red, (2) and (3), can be replaced by 2 calls to gradNonPeriodic or 3 calls to gradNonPeriodic for the 2D, and 3D cases, respectively.
Describe the solution you'd like
The proposed solution is described in this second figure:
We propose to reduce the number of functions (for both gradient and divergence), following the schematic in the second figure. We could also consider to eliminate the calls to grad with 3 arguments, to grad2D with only 5 arguments, and to grad3D with 7 arguments, which may avoid conflicts with legacy code by requiring the user to always include the boundary information.
Either solution would help resolve the current API inconsistency.
Describe alternatives you've considered
See above
Additional context
This was already discussed in issue #303