SciML / DiffEqDSL.jl

A domain-specific language for specifying various differential equations
Other
4 stars 5 forks source link

Roadmap #1

Open ChrisRackauckas opened 7 years ago

ChrisRackauckas commented 7 years ago

The roadmap for this project is essentially https://github.com/JuliaDiffEq/ParameterizedFunctions.jl/issues/17 . https://github.com/JuliaDiffEq/ParameterizedFunctions.jl/issues/17#issuecomment-293933799 Declares that ParameterizedFunctions.jl and its @ode_def macro should be made stable for DifferentialEquations.jl 2.0. Essentially, the reason for this is that to actually implement all of what we want there, we will need to re-write the entire underlying engine, and at that point it's a new project. Since that will take some time, we might as well not break what we have, hence the decision to start fresh.

The goals are https://github.com/JuliaDiffEq/ParameterizedFunctions.jl/issues/17. This includes:

1) https://github.com/JuliaDiffEq/ParameterizedFunctions.jl/issues/5 2) https://github.com/JuliaDiffEq/ParameterizedFunctions.jl/issues/6 3) Making a DSL which people outside of JuliaDiffEq can use.

It should just be a way to make a really informative type which represents a large class of DEs (including PDEs and stochasticity), so that way symbolic performance enhancements and translations (i.e. translate 4th order ODE to 1st order to solve, or translate complex to real) can be automated.

The way this could work is by building a type for each of the underlying objects. Types for derivatives and integrals, etc. A lot like the suggestion on the Discourse which would make the programming easy but the DSL hard to read. A macro would just parse a nicer syntax to build these types, and then symbolic math can be performed on these types. This gives the best of both worlds. An equation type would hold all of the elements of an equation, and would be used to classify the equation and do transformations on it. Then it should be simple to output this to functions with JuliaDiffEq can use (or add some dispatches to the problems so this is done automatically).

I think in the end it should look something like JuMP, so that way it can be built dynamically and you can "string together components". We can continue the open-ended discussion here.

i2000s commented 7 years ago

@ChrisRackauckas I haven't read your doc carefully, but I wonder is it possible to use operators (matrices) and vector states to define stochastic equations and then solve them using the toolboxes? I come from a quantum information community (see: http://juliaquantum.github.io) and would like to see more references so that we may be able to work together to grow the ecosystem. Thanks!

Qi

ChrisRackauckas commented 7 years ago

Hi @i2000s, Yes, you can define arbitrary functions on vectors of state variables for a stochastic differential equation (in physics, often referred to as the Langevin equation). For how to define a vector of equations, you can see the syntax from the ODE tutorial:

http://docs.juliadiffeq.org/latest/tutorials/ode_example.html#In-Place-Updates-1

For an introduction to the SDE parts, see the SDE tutorial:

http://docs.juliadiffeq.org/latest/tutorials/sde_example.html

You can see here that we have a bunch of solvers for SDEs:

http://docs.juliadiffeq.org/latest/solvers/sde_solve.html

There's a lot more waiting in a private repository for a paper to be published, so let me know if you have any specific needs (or if you have a good test problem!).

i2000s commented 7 years ago

@ChrisRackauckas Thank you for the pointers, I will definitely follow up when I get a chance to test out some examples. Stochastic master equations are commonly used in quantum measurement and control. We hope to see some efficient algorithms and implementations along this line. Keep up the good work!

tpdsantos commented 6 years ago

@ChrisRackauckas that seems really nice. That type of syntax, despite longer and not that user-friendly, would help a lot in creating connected models, and using something like @DV x[1:10] ; @DV y[1:10] ; @DV z[1:10] instead of u[1:30] and then separate u inside the model would be much better and would allow much more flexibility. Since this was published last year, is this already implemented?

Thanks, Tiago

ChrisRackauckas commented 6 years ago

@tpdsantos yes this is being continued in ModelingToolkit.jl.

https://github.com/JuliaDiffEq/ModelingToolkit.jl