Closed taladjidi closed 1 year ago
Yeah, this won't work in the current design, but there's a new version hopefully coming soon.
Hi,
I just ran into the same issue here: I'm trying to generate a lot of trajectories, with the start of integration t0 randomly distributed over a timespan [tstart, tstop]. And to avoid aliasing in space, I need to integrate the trajectories with saveat
at points tsample + k*Δt. with k in [0...n] and tsample random in [t0, t0 + dt]. (i.e.: the integration time points are evenly separated by dt, but the first sample is randomly offset after launch. And launch is random over the full timespan I want to study)
Any update on this issue ?
Thanks
The new version should go online by the end of April and it's like 100x faster.
Great news ! Thanks for the amazing work :)
I'm glad to hear this as I'm also trying to integrate with varying time spans! In my case, each trajectory's time-span is uniquely determined by the prob_func and there can be large variation between them. Looking forward to the new version:)
Hi, I just saw that the new version came up a few days ago. Unfortunately the problem still persists ... The random time spans do not work. Do you see any change in the forseeable future ? Thanks !
The new solver exists and this feature is possible with it, but it's just not exposed to the front end right now. We're working on optimizing it more and callback support first.
Great news, do you have any idea of the time frame when it will be release ? This will actually orient a lot my research. In any case thanks again for the great work !
"Soon"ish, but we have another paper due this week so that takes priority before we come back to this π
@utkarsh530 can you address this with EnsembleGPUKernel?
Hi Chris, I just saw your message, I will try a EnsembleGPUKernel implementation during my lunch break, and post the results here (I hope it can help !).
Using EnsembleGPUKernel yields the same error. I guess I would have more to win to fix the same tspan for all my problems (the biggest one) and put everything on the GPU rather than trying to gain by tailoring the tspan for all problems. While I understand my use case might be too specific, maybe would it be possible to just add a warning in the documentation that all problems need to share the same tspan ? In any case, many thanks again for the help and devotion !
EnsembleGPUKernel doesn't do this yet π . But in theory it could get added, so I tagged @utkarsh530 about it. Not ready to close, but probably close.
I think itβs a bit tricky to add this feature, because of different sized arrays for each solve, which might not be good with CuMatrix
which has all ts,us
stored in it. However, I can see it will work with save_everystep == false && saveat === nothing
or having constant size of ts
(where the solution is being saved).
Hi, for my application I would like to simulate a large number of trajectories (1000 to 20000) of the same system with different parameters but also with different time spans for a Monte Carlo simulation. However when attempting this, I get an error from DiffEqGPU.jl `ERROR: LoadError: AssertionError: all((p->begin
= /home/tangui/.julia/packages/DiffEqGPU/Ibo20/src/DiffEqGPU.jl:278 =
I understand that the function checks if all problems have the same tspan, but why is that ? I guess this has to do with some of the way the problem is broadcasted to the GPU under some fixed array shape. I think I could greatly benefit from switching to computing on GPU, especially for the reduced precision performance so DiffEqGPU seemed to be a good fit. Many thanks ! Here is the code to reproduce the error :