Finalize upwinding in MOLFiniteDifference about methodoflines.jl

[akashkgarg]

This snippet is failing to compile with the inclusion of JuliaSymbolics/SymbolicUtils.jl#275. Diving in to see what's going on.

[akashkgarg]

@ChrisRackauckas with slight modification to your snippet above, the following does seem to work:

        forward_weights(i,j) = DiffEqOperators.calculate_weights(discretization.upwind_order, 0.0, [space[j][i[j]],space[j][i[j]+1]])
        reverse_weights(i,j) = DiffEqOperators.calculate_weights(discretization.upwind_order, 0.0, [space[j][i[j]-1],space[j][i[j]]])
        upwinding_rules = [@rule(*(~~a,(Differential(s))(u),~~b) => IfElse.ifelse(*(~~a..., ~~b...,)>0,
                                *(~~a..., ~~b..., dot(reverse_weights(i,j),depvars[k][central_neighbor_idxs(i,j)[1:2]])),
                                *(~~a..., ~~b..., dot(forward_weights(i,j),depvars[k][central_neighbor_idxs(i,j)[2:3]]))))
                                for (j,s) in enumerate(nottime), (k,u) in enumerate(pdesys.depvars)]

[ChrisRackauckas]

cool, open a PR with a test?

[akashkgarg]

I actually wanted to find out from you what your plans were for implementing upwinding. Although the rules are computed here, they aren't used anywhere; so I had figured the commented snippet was some WIP that was going on. I also see one test MOL_1D_Linear_Convection.jl that tests upwinding but it looks like its commented out and fails to compile when run.

[ChrisRackauckas]

I hope to get MOL_1D_Linear_Convection.jl uncommented and working, and then try and do a 2D diffusion-advection example. I think want to build up towards nonlinear reaction-advection-diffusion problems "just working" with all of this.

[emmanuellujan]

If you uncomment the code and test the parser against a simple case analogous to the first test of MOL_1D_Linear_Convection.jl, an error is thrown (ERROR: LoadError: UndefVarError: u not defined). The new version does not throw errors. However, when you evaluate the eq.rhs (-Dx(u(t,x))) with the upwinding_rules: Chain(upwinding_rules)(eq.rhs), the result is the same as the input (-Differentia(x)l(u(t,x))).

[emmanuellujan]

I think the following code may help.

using ModelingToolkit
using SymbolicUtils.Rewriters
@parameters t x y
@variables u(..)
Dt = Differential(t)
Dx = Differential(x)
Dy = Differential(y)
eq = Dt(u(t, x, y)) ~ y^2*Dx(u(t, x, y)) + u(t, x, y)*x*Dy(u(t, x, y))
spacevars = [x, y]
depvars = [u(t, x, y)]
r = RestartedChain([@acrule +(*(~~a, $(Differential(sv))(dv), ~~b), ~~c) => +(*(~~a..., ~~b...), ~~c...)
                    for sv in spacevars for dv in depvars])
r(eq.rhs)

[shashi]

@Suavesito-Olimpiada

[akashkgarg]

@ChrisRackauckas @emmanuellujan
Okay, I think I've finally narrowed down the issues that are breaking MOL_1D_Linear_Convection.jl in MOL_discretization.jl. The first issue is this line:

        stencil(j) = CartesianIndices(Tuple(map(x -> -x:x, (1:nspace.==j) * (order÷2))))

when order = 1 the divide by 2, results in zero, which creates an empty set of cartesian coordinates for the fornberg finite difference algorithm. I fixed this by forcing order to be even like so:

        order = discretization.centered_order % 2 == 0 ? discretization.centered_order : discretization.centered_order + 1

The second issue is that central difference rules seem to be hard-coded to only use 2nd-order derivatives:

        central_weights(II,j) = DiffEqOperators.calculate_weights(2, space[j][II[j]], central_neighbor_space(II,j))

Do we want to support central-difference weights with order other than 2? One simple fix, is to pass in an extra parameter into central_weights that determines the derivative order into fornberg.jl and also add a rule for 1st order equations, something like this:

        central_weights(d_order, II,j) = DiffEqOperators.calculate_weights(d_order, space[j][II[j]], central_neighbor_space(II,j))
        central_deriv(d_order,II,j,k) = dot(central_weights(d_order,II,j),depvars[k][central_neighbor_idxs(II,j)])

        central_deriv2_rules = [(Differential(s)^2)(u) => central_deriv(2, II,j,k) for (j,s) in enumerate(nottime), (k,u) in enumerate(pdesys.depvars)]
        central_deriv_rules = [(Differential(s))(u) => central_deriv(1, II,j,k) for (j,s) in enumerate(nottime), (k,u) in enumerate(pdesys.depvars)]

Then we can combine these rules and use substitution like before:

        rules = vcat(vec(central_deriv_rules), vec(central_deriv2_rules), valrules)
        substitute(eq.lhs,rules) ~ substitute(eq.rhs,rules)

I know that we want to handle convection type equations with upwinding, so I guess the question is do we want to support these types of equations with central difference as well? The tests as written seem to indicate the answer is yes, but I wanted to check with folks here. Maybe there are better more general ways to handle these cases than to write out rules for each Nth-order equation we want to support.

It also seems there is a related ticket for this: SciML/DiffEqOperators.jl#353

[ChrisRackauckas]

Yes, we definitely want the higher order central difference and that's SciML/DiffEqOperators.jl#353 . And that order choice for the upwinding seems like a good default.

[valentinsulzer]

Shouldn't we check that the user always supplies an even value for discretization.centered_order?

[ChrisRackauckas]

Yes, we definitely should. I think it might fail if it's odd? But it would be good to fail with a nice error.

[akashkgarg]

I can add the error when centered_order is not even. Is there an easy way to determine the order of the PDE? I'm trying to figure out how to handle this case in SciML/DiffEqOperators.jl#353 generically, without having to enumerate a bunch of N-order PDE rules to match against. My current thinking is that one can look at the Symbolics tree generated by the equations, and count the number of operations on rhs that are of type Differential as one traverses the tree. Is there a better way to do this?

[ChrisRackauckas]

Is there an easy way to determine the order of the PDE? I'm trying to figure out how to handle this case in SciML/DiffEqOperators.jl#353 generically, without having to enumerate a bunch of N-order PDE rules to match against. My current thinking is that one can look at the Symbolics tree generated by the equations, and count the number of operations on rhs that are of type Differential as one traverses the tree. Is there a better way to do this?

@shashi might have an idea.

[xtalax]

I'm working on this now, trying to ensure that upwind differences are only using the correct boundary conditions. The problem is that depending on the winding direction different BCs will be used. I can capture this with IfElse, true including an interior equation and false including the BC, but this raises an issue if there are higher order derivative terms which might need the boundary equation.

How do I ensure that the system is not overdetermined? One solution might be to substitute in boundary equations where needed by solving for the ghost node premptively, but this limits boundary conditions to being linear as this is all Symbolics.solve_for can handle.

An alternative might be to reduce the size of the interior, as mentioned here: SciML/DiffEqOperators.jl#382 (comment)

[xtalax]

This turned out to be a non issue, Upwinding now works at first order but there is still instability at higher order