Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY

[Michael Kaufman]

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;
}