Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
  • 07:11
    killah-t-cell commented #412
  • 06:34
    LibinXu commented #810
  • 00:39

    ChrisRackauckas on gh-pages

    build based on af23065 (compare)

  • 00:26
    ChrisRackauckas closed #507
  • 00:26

    ChrisRackauckas on master

    Update financial.md Changed th… Update financial.md Changed th… Merge pull request #507 from Zi… (compare)

  • Oct 23 22:05
  • Oct 23 20:55
    tawfik741 starred SciML/DiffEqPhysics.jl
  • Oct 23 17:02
    Zitzeronion opened #507
  • Oct 23 15:03
    yewalenikhil65 reopened #439
  • Oct 23 15:03
    yewalenikhil65 closed #439
  • Oct 23 15:03
    yewalenikhil65 commented #439
  • Oct 23 15:01
    yewalenikhil65 opened #439
  • Oct 23 12:40
    ChrisRackauckas commented #1509
  • Oct 23 07:05
    killah-t-cell commented #409
  • Oct 23 06:54
    killah-t-cell commented #418
  • Oct 23 06:50
    killah-t-cell commented #418
  • Oct 23 05:59
  • Oct 23 02:10
  • Oct 23 02:10
    zhujj09 starred SciML/SciMLTutorials.jl
[slack] <Brian Groenke> > okay, if the graph compilation is done then it should be pretty good (sans the graph compile time)
Yes, with tape compilation it's not so slow, but still I don't understand why the gradients don't match. There's no theoretical reason why that should be the case, afaik.
[slack] <chrisrackauckas> yes as u0
[slack] <chrisrackauckas> since Vector{StaticArray} is equivalent to a Matrix
[slack] <Simon Welker> TIL 😄
[slack] <Simon Welker> will do, thanks a lot!
[slack] <chrisrackauckas> are there branches in your rhs?
[slack] <chrisrackauckas> np
[slack] <Brian Groenke> I don't think so....? There's IfElse uses.
[slack] <chrisrackauckas> yeah they are bitwise the same because static arrays store inline, so you can reinterpret and change the representation between them without changing the memory. So if you push static arrays into a sizehint! ed vector of staticarrays then it's the same as just filling a matrix.
[slack] <Brian Groenke> for piecewise functions
[slack] <chrisrackauckas> Yeah that would do it
[slack] <chrisrackauckas> ReverseDiff won't recognize IfElse
[slack] <chrisrackauckas> I think that would kill it
[slack] <chrisrackauckas> we need MTK-side VJPs 🤷
[slack] <Simon Welker> and DiffEq's implementation for saving does the sizehint!ing for me?
[slack] <chrisrackauckas> it has a sizehint in there, yes./
[slack] <Simon Welker> cool 🙂
[slack] <chrisrackauckas> Julia also naturally does 2^n growing so that it's amortized O(1)
[slack] <Brian Groenke> so I should just stick to forward diff, then
[slack] <chrisrackauckas> IfElse is a branch, MTK has special handling for it, ReverseDiff does not.
[slack] <Brian Groenke> I mean, that's fine for now
[slack] <Brian Groenke> oh I need to check if modelingtoolkitize works now, I dumped DEDataArray so maybe...

[slack] <Simon Welker> either I did something wrong or DiffEqNoiseProcess doesn't like StaticArrays:

ERROR: setindex!(::SVector{4, Float64}, value, ::Int) is not defined. Stacktrace: [1] setindex!(a::SVector{4, Float64}, value::Float64, i::Int64) @ StaticArrays ~/.julia/packages/StaticArrays/WCSXd/src/indexing.jl:3 [2] macro expansion @ ~/.julia/packages/StaticArrays/WCSXd/src/arraymath.jl:105 [inlined] [3] _fill! @ ~/.julia/packages/StaticArrays/WCSXd/src/arraymath.jl:100 [inlined] [4] fill! @ ~/.julia/packages/StaticArrays/WCSXd/src/arraymath.jl:99 [inlined] [5] setup_next_step! @ ~/.julia/packages/DiffEqNoiseProcess/5nMSA/src/noise_interfaces/noise_process_interface.jl:62 [inlined] [6] setup_next_step! @ ~/.julia/packages/StochasticDiffEq/qg3yM/src/integrators/integrator_utils.jl:2 [inlined] [7] __init(_prob::SciMLBase.SDEProblem{SVector{4, Float64}, Tuple{Float64, Float64}, true, Tuple{Main.CMInject.var"#1#2"{Float64, Main.CMInject.RegularGrid{2, 3, Float64, LinearAlgebra.Adjoint{Float64, Matrix{Float64}}}, Vector{Float64}}, Int64, Float64, Float64, Float64, Float64}, Nothing, SciMLBase.SDEFunction{true, typeof(Main.CMInject.stokesdirect!), typeof(Main.CMInject.ahmadidirect!), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing}, typeof(Main.CMInject.ahmadidirect!), Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, Nothing}, alg::StochasticDiffEq.EulerHeun, timeseries_init::Vector{Any}, ts_init::Vector{Any}, ks_init::Type, recompile::Type{Val{true}}; saveat::Tuple{}, tstops::Tuple{}, d_discontinuities::Tuple{}, save_idxs::Nothing, save_everystep::Bool, save_noise::Bool, save_on::Bool, save_start::Bool, save_end::Nothing, callback::Nothing, dense::Bool, calck::Bool, dt::Float64, adaptive::Bool, gamma::Int64, abstol::Nothing, reltol::Nothing, qmax::Int64, qmin::Int64, qoldinit::Int64, fullnormalize::Bool, failfactor::Int64, beta2::Int64, beta1::Int64, delta::Rational{Int64}, maxiters::Int64, dtmax::Float64, dtmin::Float64, internalnorm::typeof(DiffEqBase.ODE_DEFAULT_NORM), isoutofdomain::typeof(DiffEqBase.ODE_DEFAULT_ISOUTOFDOMAIN), unstable_check::Main.CMInject.var"#14#15", verbose::Bool, force_dtmin::Bool, timeseries_errors::Bool, dense_errors::Bool, advance_to_tstop::Bool, stop_at_next_tstop::Bool, initialize_save::Bool, progress::Bool, progress_steps::Int64, progress_name::String, progress_message::typeof(DiffEqBase.ODE_DEFAULT_PROG_MESSAGE), userdata::Nothing, initialize_integrator::Bool, seed::UInt64, alias_u0::Bool, alias_jumps::Bool, kwargs::Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}) @ StochasticDiffEq ~/.julia/packages/StochasticDiffEq/qg3yM/src/solve.jl:571 [8] #__solve#100 @ ~/.julia/packages/StochasticDiffEq/qg3yM/src/solve.jl:6 [inlined] [9] #solve_call#56 @ ~/.julia/packages/DiffEqBase/GmecW/src/solve.jl:61 [inlined] [10] #solve_up#58 @ ~/.julia/packages/DiffEqBase/GmecW/src/solve.jl:82 [inlined] [11] #solve#57 @ ~/.julia/packages/DiffEqBase/GmecW/src/solve.jl:70 [inlined] [12] example_solve() @ Main.CMInject ~/Documents/CMInject/src/CMInject.jl:200 [13] top-level scope

[slack] <Brian Groenke> Nope... modelingtoolkitize still doesn't work with ComponentArray .
[slack] <chrisrackauckas> you can't use setindex with static arrays
[slack] <chrisrackauckas> yeah, never worked on that one
[slack] <chrisrackauckas> open an issue?
[slack] <chrisrackauckas> that would be good to fix.
[slack] <Brian Groenke> on ComponentArrays?
[slack] <Simon Welker> I didn't, at least not explicitly -- DiffEqNoiseProcess seems to want to setindex! in setup_next_step!
[slack] <Brian Groenke> jonniedie/ComponentArrays.jl#16
[slack] <Simon Welker> I just swapped out my u0 by a equivalent SVector
[slack] <chrisrackauckas> I think we need integration on the MTK side
[slack] <Brian Groenke> Ok, I'll make an MTK issue.
[slack] <chrisrackauckas> @frankschae do we have tests on this?
[slack] <Brian Groenke> Is there a reason why ODESystem uses the Vector type specifically and not something more generic?
[slack] <chrisrackauckas> It doesn't need to use something more generic because it's generating the code
[slack] <chrisrackauckas> so it uses something that is compatible with most linear algebra routines.
[slack] <chrisrackauckas> modelingtoolkitize could be made more generic though
[slack] <Brian Groenke> SciML/ModelingToolkit.jl#1009
[slack] <frankschae> @Simon Welker Did you rewrite f and g to the oop form? I guess we could have some more tests.. There is https://github.com/SciML/StochasticDiffEq.jl/blob/fec328e1bff42dd2faea226a2a7e4fc910756b9b/test/static_array_tests.jl#L23. Maybe actually @isaacsas knows better (There was this issue SciML/StochasticDiffEq.jl#365 with a fix merged on static arrays in DiffEqNoiseProcess).
[slack] <isaacsas> No idea on that error. There was still something funny going on though since there seemed (to me) to be too many allocations even with that fix (though it helped a lot). Somewhere regular arrays were being allocated each step I think even with StaticArrays.
[slack] <Simon Welker> @frankschae no I haven't rewritten it as oop, should I? I can do that tomorrow if it's useful for testing purposes. But doing that will overall make for the same number of allocations, just in another part of the program, right?
[slack] <frankschae> If you use it as in your code above, I think StochasticDiffEq will default to
as the noise process, which uses then inplace functions. Do I get it then correctly that you'd like to use static arrays for the noise but normal arrays for the states?
[slack] <chrisrackauckas> the other thing is that, StochasticDiffEq had a regression show up in the latest benchmarks and this might be an indicator of that.
[slack] <krishnab> Oh I see, so this kind of issue is the real deal. It is nice to see the places where there is work to be done 🙂. Thanks for the extended technical discussion @Brian Groenke and @chrisrackauckas. I can see the challenge of trying to adjust the solver to stiffness in both the time and spatial domains. I hope you find someone good who can work on it.
[slack] <Simon Welker> @frankschae My overall goal is just avoiding allocations wherever I can (and wherever it's useful). There's no particular need for me to use static arrays for noise (=return values of g?) while using normal arrays for the states (=return values of f?). I'm currently just trying to use static arrays as u0 so the solution matrix can be preallocated (so I'd save the nsteps allocations, replacing them by one larger allocation).
[slack] <chrisrackauckas> are the allocations effecting the time here?
[slack] <Simon Welker> hmm, I'm not sure. I'd assume so esp. since I want to run this as a large ensemble simulation (10k+). Is there a way for me to tell, without running code for a fully nonallocating version?
[slack] <chrisrackauckas> Profile it