sciml / datadrivendiffeq.jl Goto Github PK

Hello,
I am going through a tutorial on SInDy from it's documentation page (using Julia 1.4.2) and have following error.

``using DataDrivenDiffEq, ModelingToolkit, OrdinaryDiffEq, LinearAlgebra, Plots
gr()
function pendulum(u, p, t)
x = u[2]
y = -9.81sin(u[1]) - 0.1u[2]
return [x;y]
end
u0 = [0.4π; 1.0]
tspan = (0.0, 20.0)
problem = ODEProblem(pendulum, u0, tspan)
solution = solve(problem, Tsit5(), atol = 1e-8, rtol = 1e-8, saveat = 0.001)
X = Array(solution)
DX = solution(solution.t, Val{1})
@variables u[1:2]
h = Operation[u; u.^2; u.^3; sin.(u); cos.(u); 1]
basis = Basis(h, u)
opt = SR3(3e-1, 1.0)
Ψ = SInDy(X[:, 1:1000], DX[:, 1:1000], basis, opt, maxiter = 10000, normalize = true)

**MethodError: no method matching SInDy(::Array{Float64,2}, ::Array{Float64,2}, ::Basis{Array{Expression,1},Array{Operation,1},Array{Operation,1},Operation}, ::SR3{Float64,UnionAll}; maxiter=10000, normalize=true)** Closest candidates are: SInDy(::AbstractArray{S,2}, ::AbstractArray{S,2}, ::Basis; p, t, maxiter, opt, denoise, normalize, convergence_error) where S<:Number at

The current implementation does not catch all variables safely.

Need to work on this.

function sindy_experiment(system, u0, p, basis, t, nsamples)
    tspan = (0.0,t)
    saveat = t/nsamples
    prob = ODEProblem(system,u0,tspan,p)
    sol = solve(prob, saveat=saveat)
    # Create the differential data
    DX = similar(sol[:,:])
    for (i, xi) in enumerate(eachcol(sol[:,:]))
        if DifferentialEquations.isinplace(prob)
            system(@view(DX[:,i]), xi, p, t/nsamples * i)
        else
            DX[:,i] = system(xi, p, t/nsamples * i)
        end
    end
    # Get the reduced basis via the sparse regression
    Ψ = SInDy(sol[:,:], DX, basis, ϵ = 1e-10)
    # Transform into ODE System
    sys = ODESystem(Ψ)
    # Simulate
    estimator = ODEProblem(dynamics(Ψ), u0, tspan)
    sol_ = solve(estimator, saveat = sol.t)
    plot(sol, vars=(1,2), linewidth=3)
    plot!(sol_, vars=(1,2), linewidth=2)
end

@variables hh[1:4]

hhbasis = Basis([poly_library(hh, 2); hh[1]^0], hh)
sindy_experiment(Systems.henonheiles().f, [0.,0.,1/4,.6], [], basis, 10, 300)

Profiling shows close to 100% of the time is in https://github.com/JuliaDiffEq/DataDrivenDiffEq.jl/blob/f6fb2e062c6ca98908b44514b5fdf8af00f5a125/src/sindy.jl#L57

It would be nice to get an ODESystem since then we would get things like Latexify support for free, i.e. data -> ModelingToolkit -> LaTeX 💥

Hello,
It would be great if someone points me to any ideas on creating Basis vector in SInDy , say using polynomial terms of multiple variables of higher degrees in more efficient manner in Julia. For eg.
Basis = [1, x, y, x^2, y^2, xy, x^3, y^3, xyz, y x^2 ,x y^2]

This would be great tool and increase usability of SInDy, for eg.. pySINDY library at https://pysindy.readthedocs.io/en/latest/examples/3_original_paper.html#cubic-2d-ode
enables one to create features/basis simply by
stating as follows

import pysindy as ps feature_library=ps.PolynomialLibrary(degree=poly_order)

Somehow around 8% of the time the first test of ADMM fails. Maybe due to the random data, but this should be handled.

I am i seeing it correctly DataDrivenDiffEq only supports building Koopmann operators along one trajectory at a time?
(In non-linear systems it might not be possible to capture all the dynamics with one initial condition)

if i had to propose a change the Koopmann could be directly "trained" to match f(u,p,t) over some collection of u,p,t.

that might could be achieved via an Optimal DMD.

The function "similar" in basis.jl appears to apply the finite difference method which is appropriate for smooth data.
Perhaps there should be an option in "similar" as well as in ModelingToolkit for non-smooth and noisy data like Total variation regularized derivative (see R. Chartrand, Numerical Differentiation of Noisy, Nonsmooth Data, ISRN Applied Mathematics, 2011).

https://www.tandfonline.com/doi/pdf/10.1080/10618600.2018.1473777?casa_token=8SCQpMoB_A0AAAAA:AEgp9_aqLA0N0YAg57VQaYUcfsCVO4MjT2dpgcHbkeeuTJ0VdffGg4vBvWn1zX2jXeDuHtJtqGs

Right now, this works ( very slow )

using DiffEqFlux, OrdinaryDiffEq, Flux, Optim, Plots
using DataDrivenDiffEq, ModelingToolkit
using Zygote

u0 = Float32[2.; 0.]
datasize = 30
tspan = (0.0f0,1.5f0)

function trueODEfunc(du,u,p,t)
    true_A = [-0.1 2.0; -2.0 -0.1]
    du .= ((u.^3)'true_A)'
end
t = range(tspan[1],tspan[2],length=datasize)
prob = ODEProblem(trueODEfunc,u0,tspan)
ode_data = Array(solve(prob,Tsit5(),saveat=t))

@variables x[1:2]
# Lots of polynomials
polys = Operation[1]
for i ∈ 1:5
    push!(polys, x.^i...)
    for j ∈ 1:i-1
        push!(polys, x[1]^i*x[2]^j)
    end
end

# And some other stuff
h = [cos(x[1]); sin(x[1]); x[1]*x[2]; x[1]*sin(x[2]); x[2]*cos(x[2]); polys...]


basis = Basis(h, x)
gradient(x->sum(dudt2(x)), u0)

dudt2 = Chain(x->basis(x),Dense(length(basis), 2)) |> f32

n_ode = NeuralODE(dudt2,tspan,Tsit5(),saveat=t)

function predict_n_ode(p)
  n_ode(u0,p)
end

function loss_n_ode(p)
    pred = predict_n_ode(p)
    loss = sum(abs2,ode_data .- pred)
    loss,pred
end

loss_n_ode(n_ode.p) # n_ode.p stores the initial parameters of the neural ODE

cb = function (p,l,pred;doplot=false) #callback function to observe training
  display(l)
  # plot current prediction against data
  if doplot
    pl = scatter(t,ode_data[1,:],label="data")
    scatter!(pl,t,pred[1,:],label="prediction")
    display(plot(pl))
  end
  return false
end

# Display the ODE with the initial parameter values.
cb(n_ode.p,loss_n_ode(n_ode.p)...)

res1 = DiffEqFlux.sciml_train(loss_n_ode, n_ode.p, ADAM(0.01), cb = cb, maxiters = 100)
cb(res1.minimizer,loss_n_ode(res1.minimizer)...;doplot=true)

But fails for the optimizers from Optim.

They cracked the double pendulum :)

https://arxiv.org/pdf/2004.02322.pdf

And the corresponding code in

https://github.com/dynamicslab/SINDy-PI

Basis switches the ordering of variables, which is a problem for stuff like

@variables x[1:3] u

h0 = Operation[x...;u ; sin(x[1])...; x.^2...]
b = Basis(h0, [x..., u])

Because internally the function is

function = (u, p;) -> begin
    begin
        if (ModelingToolkit).isa(u, (ModelingToolkit).Array) || (ModelingToolkit).:!((ModelingToolkit).typeof(u) <: (ModelingToolkit).StaticArray) && false
            return begin
                    $(Expr(:inbounds, true))
                    local var"#834#val" = begin
                                let (u, x₁, x₂, x₃) = (u[1], u[2], u[3], u[4])
                                    [(ModelingToolkit).:*(1, x₁), (ModelingToolkit).:*(1, x₂), (ModelingToolkit).:*(1, x₃), (ModelingToolkit).:*(1, u), (ModelingToolkit).sin(x₁), (ModelingToolkit).:^(x₁, 2), (ModelingToolkit).:^(x₂, 2), (ModelingToolkit).:^(x₃, 2)]
                                end
                            end
                    $(Expr(:inbounds, :((ModelingToolkit).pop)))
                    var"#834#val"
                end
        else

...

Should be a quickfix by remove the sort! in the constructor.

https://sites.engineering.ucsb.edu/~harbabi/research/M112523.pdf

Is it possible to have just time(t) as a basis along with u1(t), u2(t) etc..?

In the examples, the move from DifferentialEquations to OrdinaryDiffEq creates an error most likely connected to DiscreteProblem

using OrdinaryDiffEq
u0 = [10.0; -2.0]
tspan = (0.0, 10.0)
prob = DiscreteProblem(linear_discrete, u0, tspan)
sol = solve(prob)

out:

MethodError: no method matching __solve(::DiscreteProblem{Array{Float64,1},Tuple{Float64,Float64},true,DiffEqBase.NullParameters,DiscreteFunction{true,typeof(linear_discrete),Nothing,Nothing},Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}})
Closest candidates are:
__solve(::Union{DiffEqBase.AbstractDAEProblem, DiffEqBase.AbstractODEProblem}, !Matched::Union{OrdinaryDiffEqAlgorithm, OrdinaryDiffEq.DAEAlgorithm}, !Matched::Any...; kwargs...) at C:\Users\Denis.julia\packages\OrdinaryDiffEq\bZk7h\src\solve.jl:4
__solve(!Matched::DiffEqBase.AbstractEnsembleProblem, !Matched::Union{Nothing, DiffEqBase.DEAlgorithm}; kwargs...) at C:\Users\Denis.julia\packages\DiffEqBase\E16PL\src\ensemble\basic_ensemble_solve.jl:46
__solve(!Matched::DiffEqBase.AbstractEnsembleProblem, !Matched::Union{Nothing, DiffEqBase.DEAlgorithm}, !Matched::DiffEqBase.BasicEnsembleAlgorithm; trajectories, batch_size, pmap_batch_size, kwargs...) at C:\Users\Denis.julia\packages\DiffEqBase\E16PL\src\ensemble\basic_ensemble_solve.jl:80

Stacktrace:
[1] #solve_call#442(::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::typeof(DiffEqBase.solve_call), ::DiscreteProblem{Array{Float64,1},Tuple{Float64,Float64},true,DiffEqBase.NullParameters,DiscreteFunction{true,typeof(linear_discrete),Nothing,Nothing},Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}}) at C:\Users\Denis.julia\packages\DiffEqBase\E16PL\src\solve.jl:0
[2] solve_call(::DiscreteProblem{Array{Float64,1},Tuple{Float64,Float64},true,DiffEqBase.NullParameters,DiscreteFunction{true,typeof(linear_discrete),Nothing,Nothing},Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}}) at C:\Users\Denis.julia\packages\DiffEqBase\E16PL\src\solve.jl:37
[3] #solve#443(::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::typeof(solve), ::DiscreteProblem{Array{Float64,1},Tuple{Float64,Float64},true,DiffEqBase.NullParameters,DiscreteFunction{true,typeof(linear_discrete),Nothing,Nothing},Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}}) at C:\Users\Denis.julia\packages\DiffEqBase\E16PL\src\solve.jl:61
[4] solve(::DiscreteProblem{Array{Float64,1},Tuple{Float64,Float64},true,DiffEqBase.NullParameters,DiscreteFunction{true,typeof(linear_discrete),Nothing,Nothing},Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}}) at C:\Users\Denis.julia\packages\DiffEqBase\E16PL\src\solve.jl:45
[5] top-level scope at In[4]:4

For now, I can run the examples using DifferentialEquations as before.

When I run this line

julia> basis = Basis(h, u, parameters = p, iv = t)
ERROR: AssertionError: Please provide independent variables for basis.
Stacktrace:
 [1] Basis(::Array{Operation,1}, ::Array{Operation,1}; parameters::Array{Operation,0}, iv::Operation, eval_expression::Bool) at /home/fredrikb/.julia/packages/DataDrivenDiffEq/AhQqO/src/basis.jl:70
 [2] top-level scope at none:1

I was under the impression that iv=t is how you provide the independent variable for the basis?

The following docstring example also throws an error

https://arxiv.org/pdf/1909.03634.pdf

Would it be possible to instead allow for an array t of times for the observations? Having this be Δt seems restricting, and it's not clear to me this is required by the method.

https://arxiv.org/abs/1707.00225

@AlCap23 This paper https://cs.nyu.edu/~pogudin/global.pdf is relevant to DataDrivenDiffEq. It comes with the corresponding app https://github.com/pogudingleb/Global_Identifiability/blob/master/GlobalIdentifiability.mpl in Maple that proves to be particularly efficient. @ChrisRackauckas Note Example 2.13 on the Lotka-Volterra ODE system and why some parameters are difficult to identify.

See https://royalsocietypublishing.org/doi/pdf/10.1098/rspa.2017.0009

The hint is to adopt right away the Lorenz example for evaluation of DMD, EDMD and SInDy. This will allow of comparison in accuracy with the Matlab published papers and in speed with Julia.

A model selection function centered on AIC/BIC would then be an important extension to DataDrivenDiffEq.

@ChrisRackauckas Reminder of our conversation from two minutes ago.

Since ac1e898 the build seems to fail.

https://iopscience.iop.org/article/10.1088/2515-7639/ab291e/pdf

In the print equations and parameters, three improvements are needed:

1. The parameter set should be shrunk to eliminate all duplicates (ill-conditioning of Hessian), as is also the case in Basis (ill-conditioning of regression). In the Lorenz example, the initial guess of 7 parameters can be shrunk to the final three parameters by observing that the absolute values of P1 and P2 are identical to double or even quadruple precision; P4, P5 and P7 are also identical. This leaves P1, P3 and P4 as the true parameters discovered by the reconstruction.

2. The parameters should be presented with their standard errors to nail the point that the reconstruction method is extremely robust. Also print them with just 2 or 3 significant decimals.

3. The AIC, AICC and BIC statistics should be printed out with the corresponding pass/fail statistical values or send the user to the docstring.

At least SInDy_Examples2.jl and ISInDy_Examples.jl are not finding the correct equations any more. I'm not sure why.

In SInDy_Examples2.jl the Savitzy-Golay filter still seems to still work well (isapprox(DX_sg, DX, rtol=1e-2) # true ) but SInDy is not getting the right eqs, not even with SR3 and varying its sparsity threshold.

In the case of ISInDy, it was even more unexpected since a test almost identical to that example is included in runtest.jl and it is passing. I noticed that when using u0 = randn(3)*5.0 (as in the example), instead of the fixed u0 = [2.37; 1.58; -3.10], the test also fails.

Has a very poor performance on bigger datasets due to naiive implementation. It's not a big issue, since SR3 performs well enough at the moment, but would be nice.

I recently needed to extract the underlying system from a gEDMD call to use in some other code and as a sanity check I wanted to compare a numerical ODE solve to C*exp(At) for the resulting EDMD solution. These are not matching and I believe that they should. However, I may be miss understanding what NonlinearKoopman structs are meant to represent. It looks to me that NonlinearKoopman represents the a finite linear approximation of the Koopman Operator on the lifted spaced defined by the basis given. However, you define the ODE as

function (k::NonlinearKoopman)(u,  p::AbstractArray = [], t = nothing)
    return k.output*k.operator*k.basis(u, p, t)
end

This is in general a non-linear system of equations due to k.basis(u,p,t). This is effectively enforcing consistency between the original states and the observables during evolution. This has practical benefits, but seems to no longer treat Koopman in a linear setting. Am I missing something here?

Thanks

Here is a MWE:

using DataDrivenDiffEq
using ModelingToolkit
using OrdinaryDiffEq
using LinearAlgebra
using Plots; gr()

# Define variables and basis functions
@variables u[1:2]
h = [u[1], u[2], sin(u[1]), cos(u[1]), sin(u[2]), cos(u[2]), sin(u[1])^3*cos(u[2]), sin(u[2])^3*cos(u[1]), cos(u[1])^3*sin(u[2]),cos(u[2])^3*sin(u[1])]

# Create internal basis representation
basis = Basis(h, u)

# Define System of interest
function vanderpol(du,u,p,t)
    μ = p[1]
    du[1] = u[2]
    du[2] = μ*(1.0-u[1]^2)*u[2] - u[1]
end

# Define simulation setup for Extended DMD
params = [0.5,]
u0 = [3.0, 2.0]
tspan = (0.0, 10.0)

# Setup and solve diffEQ
prob = ODEProblem(vanderpol, u0, tspan, params)
sol = solve(prob, Tsit5())

# Extract state and derivative information from simulation
X = sol[:,:]
DX = sol(sol.t, Val{1})[:,:]

# Run Extended DMD to approximate Linear operator on the basis given.
λ = 0.0 
approximator = gEDMD(X, DX, basis, alg = DMDSVD(λ))

# Simulate high dimensional ?linear? system
prob_approx = ODEProblem(approximator, u0, tspan)
sol_approx = solve(prob_approx, Tsit5())

# Solve as C*exp(At)
A = approximator.operator
C = approximator.output
lifted = basis(u0)

t_disc = range(tspan[1], tspan[2]*.5, length=100)
sol_expA = [C*exp(A*t_)*lifted for t_ ∈ t_disc]

begin
    plot(sol, vars = (1,2), label = "truth")
    plot!(sol_approx, vars = (1,2), label="linear")
    plot!(getindex.(sol_expA,1), getindex.(sol_expA,2), label="exp(At)")
end

As @gabrevaya said to me on slack, SInDy does not always converge on numerical derivatives provided by dierkx ( and possible others ).

This needs to be checked with the original examples.

Rename SInDy to SINDy.

https://arxiv.org/abs/1902.06547 to discreminate between six different algorithms.

As briefly discussed in #53 , we need to create DDE systems from basis objects to deploy HAVOK ( and HankelDMD I guess ) as useable systems.

Currently Basis removes duplicate observables, however, it does not remove observables that are linear combinations, which may also lead to problems downstream. The big question would be what observable to remove.

using DataDrivenDiffEq, ModelingToolkit
@variables x y

basis = Basis([x,x,y,2*x,x+y],[x,y])
println(basis)

In [12] # Reiterate for the reduced approximator with few measurements
reduced_approximator = ExtendedDMD(sol[:,1:4], reduced_basis)

returns the following error:

AssertionError: Provide consistent dimensions for data

Stacktrace:
[1] #ExactDMD#46(::Float64, ::Type{ExactDMD}, ::Array{Float64,2}, ::Array{Float64,2}) at C:\Users\Denis.julia\packages\DataDrivenDiffEq\koV7t\src\exact_dmd.jl:21
[2] ExactDMD(::Array{Float64,2}, ::Array{Float64,2}) at C:\Users\Denis.julia\packages\DataDrivenDiffEq\koV7t\src\exact_dmd.jl:19
[3] #ExtendedDMD#53(::Array{Any,1}, ::Array{Any,2}, ::Float64, ::Type{ExtendedDMD}, ::Array{Float64,2}, ::Array{Float64,2}, ::Basis{Array{Operation,1},Array{Operation,1},Array{Any,1}}) at C:\Users\Denis.julia\packages\DataDrivenDiffEq\koV7t\src\extended_dmd.jl:32
[4] Type at .\none:0 [inlined]
[5] #ExtendedDMD#52(::Array{Any,1}, ::Array{Any,2}, ::Float64, ::Type{ExtendedDMD}, ::Array{Float64,2}, ::Basis{Array{Operation,1},Array{Operation,1},Array{Any,1}}) at C:\Users\Denis.julia\packages\DataDrivenDiffEq\koV7t\src\extended_dmd.jl:16
[6] ExtendedDMD(::Array{Float64,2}, ::Basis{Array{Operation,1},Array{Operation,1},Array{Any,1}}) at C:\Users\Denis.julia\packages\DataDrivenDiffEq\koV7t\src\extended_dmd.jl:16
[7] top-level scope at In[12]:1

Before registering, I think we should make sure the name is settled. I do like the name DataDrivenDiffEq. It's doing a few different things, since Koopman methods are in some sense solving an estimation problem of a linear operator, while SInDy is doing system identification. StructuralEstimationDiffEq.jl sounds bad, and StructuralEstimation.jl is non-informative. So maybe DataDrivenDiffEq.jl is the best choice, the docs page on it should still be named "Structural Estimation"? Seems like it works, but I wanted to bounce this around before finalizing the process.

Hi,

I was hoping someone could point me to an example that integrates Neural ODEs and SInDy together on just the unknown flux in an ODE. The Neural ODE example could be something like:

ann = FastChain(FastDense(2, 32, tanh),FastDense(32, 32, tanh), FastDense(32, 1))
p = initial_params(ann)
function NeoODE(du, u, p, t)
    z = ann(u, p)
    du[1] = -z[1]
    du[2] = z[1] - 10*u[2]
end

You can see that we only want to optimize the z flux here with a neural network. How would we adapt the code to run SInDy just on that flux?

Perhaps a naive side question: Does the sign in front of the neural network matter (be it + or - to match the direction of the flux)?

Thanks,
Ahmed.

Use dimensional analysis (DA) narrow down valid models. The units of variables and parameters could be specified to eliminate invalid combinations of units.

Note: This may have applications well beyond DataDrivenDiffEq.jl and may better belong in ModelingToolkit.jl. First analyzing equations (not just DiffEq) with DA can help reduce the number of variables and parameters. Occasionally, DA can turn a PDE into an ODE. DA is also a powerful in designing experiments and extrapolating results (the parachute for the Mars rover was designed with DA).

Often the choice of dimensionless numbers (π groups) is not unique. In many cases, the modeler may want to control which dimensionless parameters are chosen (e.g. Mach or Reynolds number if modeling fluid dynamics).

Resources:

• Scaling of Differential Equations
• Dimensional Analysis
• Multivariate Design of Experiments for Engineering Dimensional Analysis - (Mars Rover example)
• Self-Similar Solutions by Dimensional Analysis - (PDE to ODE example)

Instead of using ModelingToolkit directly, one could also use it indirectly for creating a basis, since we need a real function for evaluating.

Also, the basis object could be used with SInDy.

We need separate tests for the optimisers.

This link no longer works:
http://docs.juliadiffeq.org/dev/analysis/structural_estimation.html

https://arxiv.org/abs/2002.12388

@JuliaRegistrator register()

@ChrisRackauckas It should be possible to readily extend the current SINDy to predictive control as in:
https://royalsocietypublishing.org/doi/pdf/10.1098/rspa.2018.0335 including writing out the discovered optimal control solution with ModelingToolkit (OptimalControlSystem).

Just attempting to update, I get this error message that blocks all uses of SciML packages.

            _

_ _ ()_ | Documentation: https://docs.julialang.org
() | () () |
_ _ | | __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ ` | |
| | || | | | (| | | Version 1.5.0 (2020-08-01)
/ |_'|||_'_| | Official https://julialang.org/ release
|__/ |

(@v1.5) pkg> st
Status C:\Users\Denis\.julia\environments\v1.5\Project.toml
[be33ccc6] CUDAnative v3.2.0
[8f4d0f93] Conda v1.4.1
[3a865a2d] CuArrays v2.2.2
[2445eb08] DataDrivenDiffEq v0.3.3
[39dd38d3] Dierckx v0.4.2
[587475ba] Flux v0.10.4
[56d4f2e9] Gridap v0.13.4
[7073ff75] IJulia v1.21.3
[961ee093] ModelingToolkit v3.17.0
[8faf48c0] NeuralNetDiffEq v1.6.0
[315f7962] NeuralPDE v2.0.0
[1dea7af3] OrdinaryDiffEq v5.42.3
[91a5bcdd] Plots v1.6.0
[30cb0354] SciMLTutorials v0.8.0 https://github.com/SciML/SciMLTutorials.jl#master
[789caeaf] StochasticDiffEq v6.25.0
[44d3d7a6] Weave v0.10.3

(@v1.5) pkg> up
Updating git-repo https://github.com/SciML/SciMLTutorials.jl
ERROR: Unsatisfiable requirements detected for package DataDrivenDiffEq [2445eb08]:
DataDrivenDiffEq [2445eb08] log:
├─DataDrivenDiffEq [2445eb08] has no known versions!
└─restricted to versions * by an explicit requirement — no versions left

(@v1.5) pkg>

The example of the Michaelis-Menten Kinetics is currently not working.

All other tests and examples are running though. Needs investigation.

Hi guys,

I have been working with DMD and its different flavors for the past ten years or so now, primarily with Python, and start to move on to Julia.

As far as I understand the source code, it seems to me that you are currently storing the whole n x n DMD approximation of the Koopman operator once fitted. Note that this may be quite inconvenient if one applies such analysis to high-dimensional systems (e.g. fluid dynamics in my case). Explicitly storing this potentially extremely large may put a heavy burden on the memory.

Since the whole point of DMD-like techniques is to obtain a low-rank approximation of this Koopman operator, wouldn't it be better to store it in a factorized way, i.e. store only the low-rank bases for the input and output spaces as well as the corresponding eigenvalues (or r x r matrix representing the projection of the Koopman operator onto these bases) and redefine the multiplication to make use of this factorization ? I believe it would require only relatively little modifications to the current code and might enable the use of this package to effectively analyze much larger systems.

Right now ODESystem works great for making ODE system and then an ODEProblem from the basis coming out of the SINDy sparse regression, but with HAVOK, one of the variables in the regression is either used as forcing or is estimated via some sort of convolution. Right now ODESystem does not seem to be able to create these sort of systems and it seems like the only way to construct an appropriate ODE system for a HAVOK model is to manually extract the matrix and from the SINDy basis and fit a spline to the forcing mode and create your own ODE function from that. It is possible there is something I am missing since the docs currenty 404.

My 2 main questions are

1. Is there anyway to generate ODE functions for HAVOK models useing ODESystem by a different specification of the SINDy problem or something else?

2. Is there a better way of extracting the matrix from the SINDy output basis regressed on a linear basis?

Using Hyperopt.jl would allow for generic use within the loop and seems like an easy task to do.

Also makes DataDriven a little more lightweight and possibly robust.

https://arxiv.org/pdf/1411.2260.pdf

It would be nice to have a mechanism to impose stability of an estimated Koopman operator. One such mechanism which is commaonly employed for subspace-based identification is
https://www.researchgate.net/publication/3891703_Imposing_stability_in_subspace_identification_by_regularization
for which there is an implementation here

https://advances.sciencemag.org/content/advances/suppl/2017/04/24/3.4.e1602614.DC1/1602614_SM.pdf

All the elementary functions being in place, this is a natural extension of DataDrivenDiffEq