RobinBC order

[valentinsulzer]

I am trying to fix the automatic discretization of the RobinBC and have pinpointed the error.
Currently MOL_discretization.get_bcs assumes a form a*u + b*Dx(u), but it seems that the bc expressions are now getting automatically shuffled around:

a*u + b*Dx(u) # --> b * Dx(u) + a* u
b*Dx(u) + u # --> u + b * Dx(u)

This means there are more cases to consider when unpacking a RobinBC.

Firstly, is this a reasonable thing to try to fix or are there plans to do a big rewrite?
Secondly, should the fix be to somehow avoid the reshuffling (I guess in a different package) or to consider all the possible combinations for a RobinBC here in DiffEqOperators?

[emmanuellujan]

Hi!, there are plans to rewrite the code, the current version is a prototype. Nonetheless, I am not sure if BC unpacking should be rewritten, but extended. I think that this function is reasonably decoupled from the rest of the code. Regarding avoiding reshuffling vs considering all the possible combinations, because the next steps are not clear, I would choose the path that minimizes your energy. @ChrisRackauckas , some thoughts?

[valentinsulzer]

I'll just do second way, it is straightforward

[ChrisRackauckas]

The plan is to target ODESystem and keep it completely implicit. It turns out that step is equivalent to tearing, so it doesn't need to be transformed since structural_simplify will do that step if it's linear. If it's nonlinear, then it's just an implicit DAE term. So it handles both cases, and optimally.

[valentinsulzer]

So no need to fix the existing implementation?

[ChrisRackauckas]

Yeah it's going to get almost completely replaced because that'll make it easier to parse to optimality.