UndefVarError when solving MethodOfLines generated ODE

[aditya-sengupta]

I'm implementing a MOL discretization largely following the Brusselator PDE tutorial, and just after generating a discretized ODE, the call to solve results in an UndefVarError: v not defined with a long stack trace. The only thing I can think of that might cause this from the script is if I didn't add v(x,t) instead of just v anywhere in the equations/BCs, but I think I've done that. The stack trace involves a lot of RuntimeGeneratedFunctions that presumably come from this package, so it's hard to parse where the missing variable may be, but I think it's within the discretization.

Script: https://pastebin.com/ZfHxPmE8
Traceback: https://pastebin.com/wksJe5MM

[xtalax]

I've seen this elsewhere, I think this is caused by a recently introduced bug in symbolics though I was not able to reproduce it in an MWE.

It seems to be caused by the cardinalisation of the equations, where we move all terms to the lhs. Unfortunately, this is required for correctness with our upwind scheme, and I have not yet included an option to disable it.

I'm sorry, but I have not found a workaround for this.

I can confirm that this error was not present with this package list (look under julia-buildpkg), though I expect the relevent versions to hard install will be:

 Installed Symbolics ──────────────────────── v4.10.4
 Installed ModelingToolkit ────────────────── v8.22.1
 Installed SymbolicUtils ──────────────────── v0.19.11

So you could try with these versions and see if you have more success.

You can force a package to a version with julia>]add MyPackage@x.y.z.

By the way, it looks like you have an advection dominated problem. You will want to use an implicit solver like FBDF(), QBDF() or ImplicitEuler() for best stability. You may also want to try the keyword argument to the discretization advection_scheme = WENOScheme() if you find the default upwind scheme too numerically dispersive or unstable, though you will need to supply more boundary conditions (try supplying a dirichlet and neumann per edge of the domain per variable, and remove in stages to see what you can get away with) to avoid this being singular, due to a current problem.

[aditya-sengupta]

Thank you, that works for me! Do you have a sense for what kinds of problems usually cause this? Trying to chase this down here/in Symbolics might help give me a better idea for the internals.

…

On Mon, 7 Nov 2022, 05:47 Alex Jones, ***@***.***> wrote: I've seen this elsewhere, I think this is caused by a recently introduced bug in symbolics though I was not able to reproduce it in an MWE. It seems to be caused by the cardinalisation of the equations, where we move all terms to the lhs. Unfortunately, this is required for correctness with our upwind scheme, and I have not yet included an option to disable it. I'm sorry, but I have not found a workaround for this. I can confirm that this error was not present with this <https://github.com/SciML/MethodOfLines.jl/actions/runs/3074256657/jobs/4966919119> package list (look under julia-buildpkg), though I expect the relevent versions to hard install will be: Installed Symbolics ──────────────────────── v4.10.4 Installed ModelingToolkit ────────────────── v8.22.1 Installed SymbolicUtils ──────────────────── v0.19.11 So you could try with these versions and see if you have more success. You can force a package to a version with julia>]add ***@***.*** By the way, it looks like you have an advection dominated problem. You will want to use an implicit solver like FBDF(), QBDF() or ImplicitEuler() for best stability. You may also want to try the keyword argument advection_scheme = WENOScheme() if you find the default upwind scheme too numerically dispersive or unstable, though you will need to supply more boundary conditions (try supplying a dirichlet and neumann per edge of the domain per variable, and remove in stages to see what you can get away with) to avoid this being singular, due to a current problem. — Reply to this email directly, view it on GitHub <#189 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIK476VWYVL2AF7OO5T4LLLWHEB7DANCNFSM6AAAAAARYJ7UEQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[xtalax]

I haven't seen anything like this one before, it seems like an error caused by dodgy a dodgy macro call (given the error occurs in a macro), it will probably take isolating which of these 3 packages has introduced the error and then scrubbing through the diff to see which introduced it. I will be working on isolating this when I have time, but in the meantime I wish you best of luck and keen insight in your digging if you want to solve this - let me know if you find anything - we can work together on this.

[aditya-sengupta]

I've tried the older versions of each package individually, and I've found it's sufficient to just downgrade ModelingToolkit and keep Symbolics the same. I'm not sure what I should run to find the diff, though - is there a recommended debugging workflow for things like this? The default debugger hasn't been too helpful.

[xtalax]

Thank you! I think narrowing down which version of MTK introduced the bug would be the best fist step - we know it's somewhere between 8.22.1 and 8.29.1, that would probably be enough for @YingboMa to isolate what introduced it.

[aditya-sengupta]

I've tried each version in that range, and the change 8.27.0 -> 8.27.1 is where it breaks.

[YingboMa]

See SciML/ModelingToolkit.jl#1948