github-actions[bot] on new_version
CompatHelper: bump compat for C… (compare)
Hi SciMLCon attendees, This is to quickly recap the gameplan for today at SciMLCon 22! The conference will take place on YouTube + Discord/Slack from 9 AM to 6 PM EDT on March 23rd 2022. If you have not registered yet, please sign up for the free ticket here at EventBrite. All talks will be livestreamed on YouTube, on the Julia programming language channel at the following link https://www.youtube.com/watch?v=NSIAfccnq-0. Attendees are encouraged to join the conference chat platform Discord to interact with other attendees and ask questions after each talk. To join the server, click on the following URL: https://discord.gg/PRqc3NehEr. Make sure to find the #scimlcon channel. We have also created #scimlcon on the Julia Slack where you can find attendees and ask questions too. Speakers, check your emails for the calendar invite for when you should join the Streamyard platform. If there are any questions on anything else, join the chats and ask away! Have a great conference! Best, The SciMLCon 22 Organizing Committee
diffeqpy.WienerProcess(1,1)but it seems that this does not work
ContinuousCallbackin event handling section. How can I implement them. I did not understand from the official site. My problem is I have some particles that hit a screen at an unknown time and position. I want to save the position and time of hitting. I construct the callback and everything is very good. But I thought maybe from performance point of view, it is more appropriate that turn on the call back at later times not at t=0. because there is much time for the particle to reach the screen. I'll be thankful if you can help me with that.
@GitterIRCbot Hello, I have one question about the CVode solver. In my current code, I have used Cvode(cvode_mem, tout, y0, &t, CV_NORMAL) to solve my ODE function, f, but it seems like the solver has been trapped in a cycle. It always calls the ODE function, f, (I defined one "hello" output in function f if the function is called), but the solver does not get the solution. Does it mean the solver is trapped in the internal step? What is the solver doing in the cycle, does it updates the step size?
To check whether the solver is trapped in the internal step, I tried to artificially terminate the cycle by using CVodeSetMaxNumSteps(cvode_mem, mxsteps=3), but it still doesn't work, the solver still calls the ODE function, f, multiple times. So now I am a little bit confusing, if the solver is trapped in the internal step, why after I define the max step =3, does it still go inside the ODE function multiple times? Thank you for your answers.
Hi all, I'm using
Catalyst.jl to programatically generate reaction networks which I'm then attempting to solve with
DifferentialEquations.jl. I'm attempting to use some of the stiff ODE solvers to overcome some timescale separation issues, but keep getting the following error upon calling
julia: /buildworker/worker/package_linux64/build/src/ccall.cpp:875: jl_cgval_t emit_llvmcall(jl_codectx_t&, jl_value_t**, size_t): Assertion `f->getReturnType() == rettype' failed.
A long traceback follows. This ONLY occurs for stiff ODE solvers (I've tried a range of them, all with the same result), while all the non-stiff solvers I've tried seem to work fine (they become unstable and intentionally stop, which is expected behaviour for the timescale-separated problems I'm giving them). Has anyone experienced this behaviour before? (Catalyst v10.8.0, DifferentialEquations v7.1.0, also separately tried using OrdinaryDiffEq 6.10.0 with same results)