I know people like bikeshedding syntax
https://github.com/JuliaDiffEq/ParameterizedFunctions.jl/issues/17
1 Like
Maybe a good place to start is to do an audit of existing packages. How about a side by side comparison of solving KdV?
$$u_t + u_xu +u_{xxx} = 0$$
In spectral methods I know of Chebfun (MATLAB) and Dedalus (Python):
Chebfun
dom = [0 20]; x = chebfun('x',dom);
tmax = 0.0156;
S = spinop(dom,[0 tmax]);
S.lin = @(u) - diff(u,3);
S.nonlin = @(u) -diff(u).*u; % spin cannot parse "u.*diff(u)"
S.init = 3*A^2*sech(.5*A*(x-3)).^2 + 3*B^2*sech(.5*B*(x-4)).^2;
N = 800; % numer of grid points
dt = 5e-6; % time-step
u = spin(S,N,dt,'plot','off')
Dedalus
# Bases and domain
x_basis = de.Fourier('x', 1024, interval=(-8, 8), dealias=3/2)
domain = de.Domain([x_basis], np.float64)
# Problem
problem = de.IVP(domain, variables=['u', 'ux', 'uxx'])
problem.add_equation("dt(u) - dx(ux) - dx(uxx) = -u*ux")
problem.add_equation("ux - dx(u) = 0")
problem.add_equation("uxx - dx(ux) = 0")
# Build solver
solver = problem.build_solver(de.timesteppers.SBDF2)
solver.stop_wall_time = 60
solver.stop_iteration = 5000
# Initial conditions
x = domain.grid(0)
u = solver.state['u']
ux = solver.state['ux']
#uxx = solver.state['uxx']
n = 20
u['g'] = np.log(1 + np.cosh(n)**2/np.cosh(n*x)**2) / (2*n)
u.differentiate(0, out=ux)
ux.differentiate(0, out=uxx)
# Store data for final plot
# Main loop
dt = 2e-3
while solver.ok:
solver.step(dt)
Others know the FEM packages.
Note both packages split into linear and nonlinear parts. In Dedalus, everything to the right of = is considered the nonlinear part, which is stepped explicitly.
In theory, this code could work at some point in ApproxFun, though it is using a global Newton iteration rather than time stepping:
u0 = Fun(θ->exp(-10θ^2),Fourier())
newton((u,t,x) -> [u(0,:) - u0; # initial condition
differentiate(u,[1,0]) + differentiate(u,[0,1])*u + differentiate(u,[0,3])],
Chebyshev(0..T) * Fourier())
The equation is linearized around an initial guess using automatic differentiation (DualFun).
Yes, I hope to plug into ApproxFun for some things. This would happen by building a problem type from the macros return type. One place I want to go with this is ApproxFun for BVPs.
https://github.com/JuliaDiffEq/ParameterizedFunctions.jl/issues/6
If the syntax covers a large set of diffeqs then this is possible.
One place I took inspiration from was xppaut.
How do you feel about unicode? Maybe something like this could be made to work for KdV:
(u,t,x) -> ∂(u)/∂(t) + u*∂(u)/∂(x) + ∂^3(u)/∂(x)^3
Cf. https://github.com/JuliaApproximation/ApproxFun.jl/issues/152 for some old discussion on making sense of this notation (that is, if you can do ∂(u)/∂(x), can you also do ∂(u)/∂(x^2) and what would it mean?)
1 Like
I would like to avoid requiring Unicode, but allow it as a pretty fallback
Without unicode, it would probably be something like
(u,t,x) -> Differential(u)/Differential(t) + u*Differential(u)/Differential(x) + Differential^3(u)/Differential(x)^3
where some fancy overrides could make Differential^3 possible.
The other option is to use integers to denote the variable being differentiated:
(u,t,x) -> differentiate(u,[1,0]) + u*differentiate(u,[0,1]) + differentiate(u,[0,3])
which could have the pretty syntax
(u,t,x) -> ∂(u,[1,0]) + u*∂(u,[0,1]) + ∂(u,[0,3])
Another option is Newton syntax:
(u,t,x) -> u̇ + u*u' + u'''
dlfivefifty:
Another option is Newton syntax:
(u,t,x) -> u̇ + u*u’ + u’‘’
Actually, this won’t work because u̇ is not an operator. So it would be something like ̇(u), which is not so nice
what’s wrong with the _x syntax? Should probably take this to the Github issue.
Nothing, but I thought you wanted to bikeshed…
Though I think it’s better to avoid making meta-languages using macros
Well, there’s always a full setup with generic Julia functions one can use. The DSL is made to be
a) Easy to read
to take care of “most equations”.
. I am looking to update the syntax for the macros in DifferentialEquations.jl (ParameterizedFunctions.jl) for “easily defining diffeqs”. I am looking for a syntax that can capture a lot of different types of diffeqs, looks natural (i.e. looks like a math or science paper), but also must be easy to parse. I opened an issue here to write down what my proposal is and start working it into something that’s doable (I’m not sure the current proposal is easy to parse):