Yes. Your interpretation is good. In your simple example,
gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t+1, &h, y); // First call // modify system parameters in some fashion gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t+1, &h, y); // Second call After the first call, e->dydt_out is updated by the most updated y. However, in 4771, e->dydt_in in the second call is updated by e->dydt_out. But e->dydt_out is based on old parameters before modifications. It may cause problems, as dydt_in is the next k1 in stepping functions. The deviation may cause the step size to be very small. I guess this is the reason why somebody experiences a performance regression. Alan 2013/11/6 Rhys Ulerich <[email protected]> > > For simplicity, I would like to call the following segment an iteration. > > > > while (t < t1) > > { > > int status = gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t1, &h, y); > > > > if (status != GSL_SUCCESS) > > break; > > } > > > > ... > > > > Honestly, I started to worry whether modifying things in params outside > > iterations is a misuse of GSL. > > This may be a use case for which 4771 introduces a bug. Hear me out... > > When using a plain-vanilla RK4 scheme, the system of equations and all > of its parameters must remain fixed from substep-to-substep for > full-order accuracy to be achieved. However, between RK4 steps one is > permitted to change the parameters however one likes. > > Along that line of reasoning, I would expect > gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t+1, &h, y); > // modify system parameters in some fashion > gsl_odeiv2_evolve_apply (e, c, s, &sys, &t, t+1, &h, y); > to behave identically pre- and post-4771 as line 1 completes some > number of full steps of the chosen scheme. That is, the modification > in line 2 is not done in between substeps. > > Alan, am I interpreting your use case correctly? > > Tuomo, is this use case supported and, if so, does 4771 break it in > some fashion? > > - Rhys >
