With #37 we have three distinct subroutines carrying out similar work, sum_yintox, sum_zintox, and vecadd. Just like we did in reorder subroutine we can combine all these into one interface with a switch statement.
backend%add(u, u_, SUM_Y2X)
we can make the switch statement optional so that if nothing is passed two arrays are summed without doing any reordering, resulting in the current vecadd.
The only thing is, we need this add to be able to scale u_ at least so that it can be used in the time integrator and also at the very end in the pressure correction step. I don't think we need this scaling option when we're adding a y or z oriented array into x. Given this is the case, is it better to have 2 interfaces, one combines sum_yintox and sum_zintox, and the other just deals with vecadd including scaling the input/output fields? Any thoughts?
With #37 we have three distinct subroutines carrying out similar work,
sum_yintox
,sum_zintox
, andvecadd
. Just like we did in reorder subroutine we can combine all these into one interface with a switch statement.backend%add(u, u_, SUM_Y2X)
we can make the switch statement optional so that if nothing is passed two arrays are summed without doing any reordering, resulting in the current vecadd.
The only thing is, we need this add to be able to scale
u_
at least so that it can be used in the time integrator and also at the very end in the pressure correction step. I don't think we need this scaling option when we're adding ay
orz
oriented array intox
. Given this is the case, is it better to have 2 interfaces, one combinessum_yintox
andsum_zintox
, and the other just deals with vecadd including scaling the input/output fields? Any thoughts?