Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
BridgingBot
@GitterIRCbot
[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
[slack] <yingbo_ma> use_fast_broadcast is not safe, so setting it to true by the developer manually would be good.
[slack] <yingbo_ma> I don’t think we should do opt-in
[slack] <chrisrackauckas> what about relying on the fast_scalar_indexing trait?
BridgingBot
@GitterIRCbot

[slack] <yingbo_ma> ```julia> a = rand(5); b = @views a[1:2:end];

julia> ArrayInterface.fast_scalar_indexing(b)
true```

[slack] <yingbo_ma> Not really.
[slack] <yingbo_ma> Also, we don’t know if the broadcast has fast scalar index
[slack] <yingbo_ma> I am not sure if there’s a good proxy for use_fast_broadcast . This decision should be done by the developer of the package.
BridgingBot
@GitterIRCbot
[slack] <yingbo_ma> Also, broadcast is very customizable, and FastBroadcast is very rigid. We should not just override custom broadcasting behavior in @..