Staggered problem dirichlet/neumann return convention
The following discussion from !2852 (merged) should be addressed:
I aggree and I also think that there should be some direct traits mechanics.
However, this issue might also exist for user-defined functions. I think the discrepancy here is between how we actually think of
PrimaryVariablesand how it is used in the test cases. So maybe using for both situations the name
PrimaryVariablesmight be confusing?
The staggered Navier-Stokes code expects full velocities fluxes (in all dimensions) from the problem. This makes it easier to set boundary conditions for when complex treatment due to the discretization is needed in the background.
The correct sizes are now statically asserted !2852 (merged). Still the problem uses the type names
NumEqVector but means different types than the corresponding types specified via properties and used in the assembly. This makes this error-prone and confusing. Moreover, it is currently necessary to overload all such functions inherited from the
FVProblem because the type information is not properly propagated into the base class.
One solution would be to overload the functions in the navierstokes problem and actually use different type names such as
MomentumFlux so that it's completely clear that these are different.
TODO: how does this generalize to more complex models? Is it always only the momentum model affected by this? How to treat the difference with the mass model since both are currently implemented in one class with template switches.
Also change numeq confusion in boundarytypes and modeltraits for the momentum problem -> !3037 (merged)