Merge branch 'master' into jps/daggerform

Author: ChrisRackauckas

.travis.yml

@@ -1,5 +1,8 @@
 # Documentation: http://docs.travis-ci.com/user/languages/julia/
 language: julia
+branches:
+  only:
+    - master
 os:
   - linux
 #  - osx

LICENSE.md

@@ -1,6 +1,6 @@
 The ModelingToolkit.jl package is licensed under the MIT "Expat" License:
 
-> Copyright (c) 2018: Christopher Rackauckas.
+> Copyright (c) 2018-20: Christopher Rackauckas, Julia Computing.
 >
 >
 > Permission is hereby granted, free of charge, to any person obtaining a copy

Project.toml

@@ -1,17 +1,19 @@
 name = "ModelingToolkit"
 uuid = "961ee093-0014-501f-94e3-6117800e7a78"
 authors = ["Chris Rackauckas <[email protected]>"]
-version = "3.3.0"
+version = "3.10.2"
 
 [deps]
 ArrayInterface = "4fba245c-0d91-5ea0-9b3e-6abc04ee57a9"
+DataStructures = "864edb3b-99cc-5e75-8d2d-829cb0a9cfe8"
 DiffEqBase = "2b5f629d-d688-5b77-993f-72d75c75574e"
 DiffEqJump = "c894b116-72e5-5b58-be3c-e6d8d4ac2b12"
 DiffRules = "b552c78f-8df3-52c6-915a-8e097449b14b"
 Distributed = "8ba89e20-285c-5b6f-9357-94700520ee1b"
 DocStringExtensions = "ffbed154-4ef7-542d-bbb7-c09d3a79fcae"
 GeneralizedGenerated = "6b9d7cbe-bcb9-11e9-073f-15a7a543e2eb"
 Latexify = "23fbe1c1-3f47-55db-b15f-69d7ec21a316"
+LightGraphs = "093fc24a-ae57-5d10-9952-331d41423f4d"
 LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"
 MacroTools = "1914dd2f-81c6-5fcd-8719-6d5c9610ff09"
 NaNMath = "77ba4419-2d1f-58cd-9bb1-8ffee604a2e3"
@@ -28,19 +30,21 @@ Unitful = "1986cc42-f94f-5a68-af5c-568840ba703d"
 
 [compat]
 ArrayInterface = "2.8"
-DiffEqBase = "6.28"
-DiffEqJump = "6.6.2"
+DataStructures = "0.17"
+DiffEqBase = "6.38"
+DiffEqJump = "6.7.5"
 DiffRules = "0.1, 1.0"
 DocStringExtensions = "0.7, 0.8"
 GeneralizedGenerated = "0.1.4, 0.2"
 Latexify = "0.11, 0.12, 0.13"
+LightGraphs = "1.3"
 MacroTools = "0.5"
 NaNMath = "0.3"
 RecursiveArrayTools = "2.3"
 SafeTestsets = "0.0.1"
 SpecialFunctions = "0.7, 0.8, 0.9, 0.10"
 StaticArrays = "0.10, 0.11, 0.12"
-SymbolicUtils = "0.3.2"
+SymbolicUtils = "0.4.1"
 TreeViews = "0.3"
 UnPack = "0.1, 1.0"
 Unitful = "1.1"
@@ -49,8 +53,9 @@ julia = "1.2"
 [extras]
 Dagger = "d58978e5-989f-55fb-8d15-ea34adc7bf54"
 OrdinaryDiffEq = "1dea7af3-3e70-54e6-95c3-0bf5283fa5ed"
+SteadyStateDiffEq = "9672c7b4-1e72-59bd-8a11-6ac3964bc41f"
 StochasticDiffEq = "789caeaf-c7a9-5a7d-9973-96adeb23e2a0"
 Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
 
 [targets]
-test = ["Dagger", "OrdinaryDiffEq", "Test", "StochasticDiffEq"]
+test = ["Dagger", "OrdinaryDiffEq", "SteadyStateDiffEq", "Test", "StochasticDiffEq"]

README.md

@@ -6,7 +6,7 @@
 [![Stable](https://img.shields.io/badge/docs-stable-blue.svg)](http://mtk.sciml.ai/stable/)
 [![Dev](https://img.shields.io/badge/docs-dev-blue.svg)](http://mtk.sciml.ai/dev/)
 
-ModelingToolkit.jl is a modeling framework for high performance symbolic-numeric computation 
+ModelingToolkit.jl is a modeling framework for high-performance symbolic-numeric computation
 in scientific computing  and scientific machine learning.
 It allows for users to give a high-level description of a model for
 symbolic preprocessing to analyze and enhance the model. ModelingToolkit can
@@ -18,11 +18,11 @@ to the model to make it easier for numerical solvers to handle.
 For information on using the package,
 [see the stable documentation](https://mtk.sciml.ai/stable/). Use the
 [in-development documentation](https://mtk.sciml.ai/dev/) for the version of
-the documentation which contains the un-released features.
+the documentation which contains the unreleased features.
 
-## High Level Examples
+## High-Level Examples
 
-First let's define a second order riff on the Lorenz equations, symbolically
+First, let's define a second order riff on the Lorenz equations, symbolically
 lower it to a first order system, symbolically generate the Jacobian function
 for the numerical integrator, and solve it.
 
@@ -59,8 +59,8 @@ using Plots; plot(sol,vars=(x,y))
 
 This automatically will have generated fast Jacobian functions, making
 it more optimized than directly building a function. In addition, we can then
-use ModelingToolkit to compose multiple ODE subsystems. Now let's define two
-interacting Lorenz equations and simulate the resulting Differential-Algebriac
+use ModelingToolkit to compose multiple ODE subsystems. Now, let's define two
+interacting Lorenz equations and simulate the resulting Differential-Algebraic
 Equation (DAE):
 
 ```julia

docs/make.jl

@@ -15,10 +15,12 @@ makedocs(
             "systems/AbstractSystem.md",
             "systems/ODESystem.md",
             "systems/SDESystem.md",
+            "systems/JumpSystem.md",
             "systems/NonlinearSystem.md",
             "systems/OptimizationSystem.md",
             "systems/ReactionSystem.md",
-            "systems/PDESystem.md"
+            "systems/PDESystem.md",
+            "systems/DependencyGraphs.md"
         ],
         "IR.md"
     ]

docs/src/IR.md

@@ -2,12 +2,12 @@
 
 ModelingToolkit IR, which falls under the `Expression` abstract type, mirrors
 the Julia AST but allows for easy mathematical manipulation by itself following
-mathematical semantics. The base of the IR is the `Variable` type which defines
+mathematical semantics. The base of the IR is the `Variable` type, which defines
 a symbolic variable. These variables are combined using `Operation`s, which are
 registered functions applied to the various variables. These `Operation`s then
 perform automatic tracing, so normal mathematical functions applied to an `Operation`
 generate a new `Operation`. For example, `op1 = x+y` is one `Operation` and
-`op2 = 2z` is another, and so `op1*op2` is another `Operation`. Then at the top,
+`op2 = 2z` is another, and so `op1*op2` is another `Operation`. Then, at the top,
 an `Equation`, normally written as `op1 ~ op2`, defines the symbolic equality
 between two operations.
 
@@ -24,7 +24,7 @@ Equation
 ### Function Registration
 
 The ModelingToolkit graph only allowed for registered Julia functions for the
-operations. All other functions are automatically traced down to registred
+operations. All other functions are automatically traced down to registered
 functions. By default, ModelingToolkit.jl pre-registers the common functions
 utilized in the AD package ruleset [DiffRules.jl](https://github.com/JuliaDiff/DiffRules.jl)
 and pre-defines their derivatives. However, the user can utilize the `@register`
@@ -36,8 +36,8 @@ macro to add their function to allowed functions of the computation graph.
 
 ### Derivatives and Differentials
 
-A `Differential(op)` is a partial derivative with respect to the operation `op`
-which can then be applied to some other operations. For example `D=Differential(t)`
+A `Differential(op)` is a partial derivative with respect to the operation `op`,
+which can then be applied to some other operations. For example, `D=Differential(t)`
 is what would commonly be referred to as `d/dt`, which can then be applied to
 other operations using its function call, so `D(x+y)` is `d(x+y)/dt`.
 
@@ -55,7 +55,7 @@ ModelingToolkit.jacobian
 ModelingToolkit.hessian
 ```
 
-Note that generation of sparse matrices simply follows from the Julian semantics
+Note that the generation of sparse matrices simply follows from the Julia semantics
 imbued on the IR, so `sparse(jac)` changes a dense Jacobian to a sparse Jacobian
 matrix.
 
@@ -64,7 +64,7 @@ matrix.
 There is a large amount of derivatives pre-defined by
 [DiffRules.jl](https://github.com/JuliaDiff/DiffRules.jl). Note that `Expression`
 types are defined as `<:Real`, and thus any functions which allow the use of real
-numbers can automatically be traced by the derivative mechanism. Thus for example:
+numbers can automatically be traced by the derivative mechanism. Thus, for example:
 
 ```julia
 f(x,y,z) = x^2 + sin(x+y) - z
@@ -86,7 +86,7 @@ ModelingToolkit.derivative(::typeof(my_function), args::NTuple{N,Any}, ::Val{i})
 ```
 
 where `i` means that it's the derivative of the `i`th argument. `args` is the
-array of arguments, so for example if your function is `f(x,t)` then `args = [x,t]`.
+array of arguments, so, for example, if your function is `f(x,t)`, then `args = [x,t]`.
 You should return an `Operation` for the derivative of your function.
 
 For example, `sin(t)`'s derivative (by `t`) is given by the following:
@@ -102,7 +102,7 @@ types. Most of the functionality comes by the `Expression` type obeying the
 standard mathematical semantics. For example, if one has `A` a matrix of
 `Expression`, then `A^2` calculates the `Expression`s for the squared matrix.
 In that sense, it is encouraged that one uses standard Julia for performing a
-lot of the manipulation on the IR, as for example calculating the sparse form
+lot of the manipulation on the IR, as, for example, calculating the sparse form
 of the matrix via `sparse(A)` is valid, legible, and easily understandable
 to all Julia programmers.
 
@@ -124,7 +124,7 @@ like those for differential equation solvers and optimization libraries.
 
 Additionally, the core compilation process of ModelingToolkit IR is `build_function`.
 `build_function` takes an operation or an `AbstractArray` of operations and
-generates a compile-able version of the model for numerical solvers.
+generates a compilable version of the model for numerical solvers.
 
 ```@docs
 build_function

docs/src/highlevel.md

@@ -1,17 +1,17 @@
 # High Level API
 
-The high level API allows modelers to interactively build models in a symbolic
+The high-level API allows modelers to interactively build models in a symbolic
 manner. It is designed as a semi-DSL for easily building large complex models
-and manipulating the models to generate optimal forms for utilizing in numerical
+and manipulating the models to generate optimal forms to be used in numerical
 methods.
 
 ## Examples
 
 ### Example 1: Symbolically Building an ODEProblem for DifferentialEquations.jl
 
-Let's build an ODE. First we define some variables. In a differential equation
+Let's build an ODE. First, we define some variables. In a differential equation
 system, we need to differentiate between our (dependent) variables
-and parameters. Therefore we label them as follows:
+and parameters. Therefore, we label them as follows:
 
 ```julia
 using ModelingToolkit
@@ -73,7 +73,7 @@ connections = [0 ~ lorenz1.x + lorenz2.y + sin(α*γ)]
 connected = ODESystem(connections,[α],[γ],systems=[lorenz1,lorenz2])
 ```
 
-which is now a differential-algebraic equation (DAE) of 7 variables which has
+which is now a differential-algebraic equation (DAE) of 7 variables, which has
 two independent Lorenz systems and an algebraic equation that determines `α`
 such that an implicit constraint holds. We can then define the resulting
 `ODEProblem` and send it over to DifferentialEquations.jl.
@@ -169,7 +169,7 @@ which gives:
       end)
 ```
 
-Now we can call `nlsolve` by enclosing our parameters into the functions:
+Now, we can call `nlsolve` by enclosing our parameters into the functions:
 
 ```julia
 using NLsolve
@@ -184,9 +184,9 @@ generate the function, i.e.:
 nlsys_func = generate_function(ns, [x,y,z], [σ,ρ,β], expression=Val{false})[2]
 ```
 
-which uses GeneralizedGenerated.jl to build a same world-age function on the fly without eval.
+which uses GeneralizedGenerated.jl to build the same world-age function on the fly without eval.
 
-## High Level API Documentation
+## High-Level API Documentation
 
 ```@docs
 @parameters
@@ -195,14 +195,14 @@ which uses GeneralizedGenerated.jl to build a same world-age function on the fly
 Base.:~(::Expression, ::Expression)
 ```
 
-## Additional High Level Explanations and Tips
+## Additional High-Level Explanations and Tips
 
 ### The Auto-Detecting System Constructors
 
-For the high level interface, the system constructors such as `ODESystem` have
-high level constructors which just take in the required equations and automatically
+For the high-level interface, the system constructors, such as `ODESystem`, have
+high-level constructors, which just take in the required equations and automatically
 parse the expressions to figure out the states and parameters of the system.
-The following high level constructors exist:
+The following high-level constructors exist:
 
 ```julia
 ODESystem(eqs)
@@ -211,7 +211,7 @@ NonlinearSystem(eqs)
 
 ### Direct Tracing
 
-Because the ModelingToolkit `Expression` types obey Julia-semantics, one can
+Because the ModelingToolkit `Expression` types obey Julia semantics, one can
 directly transform existing Julia functions into ModelingToolkit symbolic
 representations of the function by simply inputting the symbolic values into
 the function and using what is returned. For example, let's take the following
@@ -282,7 +282,7 @@ multithreadedjac = eval(ModelingToolkit.build_function(vec(jac),u,multithread=tr
 ### modelingtoolkitize
 
 For some `DEProblem` types, automatic tracing functionality is already included
-via the `modelingtoolkitize` function. Take for example the Robertson ODE
+via the `modelingtoolkitize` function. Take, for example, the Robertson ODE
 defined as an `ODEProblem` for DifferentialEquations.jl:
 
 ```julia
@@ -299,7 +299,7 @@ prob = ODEProblem(rober,[1.0,0.0,0.0],(0.0,1e5),(0.04,3e7,1e4))
 ```
 
 If we want to get a symbolic representation, we can simply call `modelingtoolkitize`
-on the `prob` which will return an `ODESystem`:
+on the `prob`, which will return an `ODESystem`:
 
 ```julia
 sys = modelingtoolkitize(prob)

docs/src/index.md

@@ -1,7 +1,7 @@
 # ModelingToolkit.jl
 
-ModelingToolkit.jl is a modeling language for high performance 
-symbolic-numeric computation in scientific computing  and scientific machine learning.
+ModelingToolkit.jl is a modeling language for high-performance
+symbolic-numeric computation in scientific computing and scientific machine learning.
 It allows for users to give a high-level description of a model for
 symbolic preprocessing to analyze and enhance the model. ModelingToolkit can
 automatically generate fast functions for model components like Jacobians
@@ -20,10 +20,10 @@ ModelingToolkit has 3 layers:
    ModelingToolkit models directly from Julia code.
 2. The `AbstractSystem` level. This is the level where content-dependent functionality
    is added, where models such an ordinary differential equation are represented.
-   At the system level there are *transformations* which take one system to
+   At the system level, there are *transformations* which take one system to
    another, and *targets* which output code for numerical solvers.
 3. The IR level, also referred to as the direct level. At this level, one
-   directly acts on arrays of `Equation`, `Operation` and `Variable` types to
+   directly acts on arrays of `Equation`, `Operation`, and `Variable` types to
    generate functions.
 
 Each level above is built on the level below, giving more context to allow for

docs/src/systems/AbstractSystem.md

@@ -13,7 +13,7 @@ Each `AbstractSystem` has lists of variables in context, such as distinguishing
 parameters vs states. In addition, an `AbstractSystem` also can hold other
 `AbstractSystem` types. Direct accessing of the values, such as `sys.states`,
 gives the immediate list, while the accessor functions `states(sys)` gives the
-total set which includes that of all systems held inside.
+total set, which includes that of all systems held inside.
 
 The values which are common to all `AbstractSystem`s are:
 
@@ -25,9 +25,9 @@ The values which are common to all `AbstractSystem`s are:
 ## Transformations
 
 Transformations are functions which send a valid `AbstractSystem` definition to
-another `AbstractSystem`. These are passes like optimizations (ex: Block-Lower
-Triangle transformations) or changes to the representation which allow for
-alternative numerical methods to be utilized on the model (ex: DAE index reduction).
+another `AbstractSystem`. These are passes, like optimizations (e.g., Block-Lower
+Triangle transformations), or changes to the representation, which allow for
+alternative numerical methods to be utilized on the model (e.g., DAE index reduction).
 
 ## Function Calculation and Generation
 
@@ -36,8 +36,8 @@ quantities to enhance the numerical methods applied to the resulting system.
 The calculations, like `calculate_jacobian`, generate ModelingToolkit IR for
 the Jacobian of the system, while the generations, like `generate_jacobian`,
 generate compiled output for the numerical solvers by applying `build_function`
-to the generated code. Additionally, many systems have function type outputs
-which cobble together the generation functionality for a system, for example
+to the generated code. Additionally, many systems have function-type outputs,
+which cobble together the generation functionality for a system, for example,
 `ODEFunction` can be used to generate a DifferentialEquations-based `ODEFunction`
 with compiled version of the ODE itself, the Jacobian, the mass matrix, etc.
 
@@ -63,6 +63,6 @@ which allow for directly generating the problem types required for numerical
 methods. The first argument is always the `AbstractSystem`, and the proceeding
 arguments match the argument order of their original constructors. Whenever an
 array would normally be provided, such as `u0` the initial condition of an
-`ODEProblem`, it is instead replaced with a variable map, i.e. an array of
-pairs `var=>value` which allows the user to designate the values without having
+`ODEProblem`, it is instead replaced with a variable map, i.e., an array of
+pairs `var=>value`, which allows the user to designate the values without having
 to know the order that ModelingToolkit is internally using.

docs/src/systems/DependencyGraphs.md

@@ -0,0 +1,21 @@
+# Dependency Graphs
+
+# Types
+```@docs
+BipartiteGraph
+```
+
+# Utility functions for `BiPartiteGraph`s
+```@docs
+Base.isequal
+```
+
+# Functions for calculating dependency graphs
+```@docs
+equation_dependencies
+asgraph
+variable_dependencies
+asdigraph
+eqeq_dependencies
+varvar_dependencies
+```