Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
BridgingBot
@GitterIRCbot
[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...
BridgingBot
@GitterIRCbot

[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
BridgingBot
@GitterIRCbot
[slack] <Brian Groenke> SciML/ModelingToolkit.jl#1009
BridgingBot
@GitterIRCbot
[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).
BridgingBot
@GitterIRCbot
[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.
BridgingBot
@GitterIRCbot
[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?
BridgingBot
@GitterIRCbot
[slack] <frankschae> If you use it as in your code above, I think StochasticDiffEq will default to
WienerProcess!(..)
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.
BridgingBot
@GitterIRCbot
[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?
BridgingBot
@GitterIRCbot
[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
[slack] <Simon Welker> cheers, I'll try that soon. I was so far only looking at @btime
[slack] <Simon Welker> I guess even if it isn't worth it for my problem, generally allowing for this preallocation (e.g. via SArrays) could be useful for other problems?
[slack] <Simon Welker> (ah it's from 18337 -- I'm only on lecture 7 so far :D)
BridgingBot
@GitterIRCbot
[slack] <chrisrackauckas> you can pre-allocate by passing in more arguments, but it's undocumented because I want to change and improve that interface.
BridgingBot
@GitterIRCbot
[slack] <Jonnie> LabelledArrays and ComponentArrays have some performance regressions for some of my test problems after the DiffEqBC->FastBroadcast switch. Writing a method for FastBroadcast.use_fast_broadcast fixes it, though. Is this something I should be opting into for ComponentArrays? Or is this going to be handled on the DifferentialEquations side?
BridgingBot
@GitterIRCbot
[slack] <chrisrackauckas> @yingbo_ma @elrodc how do we recover the opt-ins that were in
[slack] <chrisrackauckas> DiffEqBase?
[slack] <chrisrackauckas> and ComponentArrays had one