Hello Andrei, I think you could use the driver and let it handle step size control. You can check the usage examples here: http://www.gnu.org/software/gsl/doc/html/ode-initval.html#examples If you want to see more examples, there are some functions in the test.c file: https://git.savannah.gnu.org/cgit/gsl.git/tree/ode-initval2/test.c
The idea of the driver level is to hide the low-level objects from the users who don't need to have manual control over solution process. You can access them via the driver struct if needed. The driver level is documented here: http://www.gnu.org/software/gsl/doc/html/ode-initval.html#driver BR, Tuomo On Tue, Mar 30, 2021 at 4:59 PM Andrei Kramer <andre...@kth.se> wrote: > Hello, > I have a question regarding ODE steppers. I would like to integrate a > stiff system, and obtain output which is fine grained where needed and > has bold time steps where the trajectory is more flat. This is ideal > for plotting the result I think, and gives me some insight into which > step sizes the integrator thought reasonable. > > So, I wanted to try to use the low-level evolve_apply functions (is > that the right way to go about this?). But the really good solvers for > stiff problems require a driver object, which allocates all of the > arguments for the evolve_apply function internally. I don't see any way > to access those objects. So, I don't know how to call the evolve_apply > function at all, other than making those objects a second time > (manually) and hoping that they are similar enough (i.e. that I don't > specify two very different control functions by accident). It just > seems unatural to have the driver internal step/control function and > another (manually made) step/control function. > > Should I... not try to obtain adaptively spaced output and just pick a > fixed time-step for the trajectory? (this is what I'm doing now) > > This would probably mean that I won't know which steps the solver made. > Currently I pick a safe (small) step size so that the plotted curves > look smooth enough. > > I suspect that I don't fully understand the reasoning behind the odeiv2 > interface. > > Best, > Andrei Kramer > > > -- tuomo.keskit...@iki.fi http://iki.fi/tuomo.keskitalo