On 9/28/17 12:08 PM, Tuomo Keskitalo wrote:
Hello,
On 26.09.2017 21:36, Michael Kaufman wrote:
gsl: msadams.c:973: ERROR: msadams_apply too large order change
Default GSL error handler invoked.
I'm running on OSX 10.11.6 using a gsl-2.4_1 from macports.
This might be compiler optimization issue. Can you please try with
non-optimized (-O0) version of GSL? I have no idea how to get that
with macports... Alternatively, can you try to run your program on Linux?
This has crashed on Linux (RHEL 7.4 as well as Fedora 25 with whatever
GSL their package managers fetch). Though not necessarily the exact same
input. My K_mn(z)'s are produced from a Monte Carlo routine.
Strangely, if I solve the ODE with and abstol of 1e-8 and then
immediately afterward solve again with an abstol of 1e-10, (for
convergence testing) then the abort happens (call this case 1).
Frankly, I don't understand why this could be unless there's some global
state in the GSL library that isn't reset..., or now that I think about
it, my evaluation function that I pass into the ODE driver does make
calls to gsl_spline_eval_e() using accelerators, and those accelerators
are _not_ getting reinitialized in between calls to "foo()" (see below).
How exactly do you "immediately afterward solve again"? Do you call
gsl_odeiv2_driver_reset in between calls to gsl_odeiv2_driver_apply?
something like:
ret1 = foo(abstol=1e-8);
if (ret1 != converged) {
ret2 = foo(abstol=1e-10);
}
where
double foo(abstol){
...
driver = gsl_odeiv2_driver_alloc_y_new(...);
...
gsl_odeiv2_driver_reset(driver);
...
for loop {
status = gsl_odeiv2_driver_apply(driver,...);
...
}
...
gsl_odeiv2_driver_free(driver);
return result;
}