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

[Michael Kaufman]

On 10/2/17 12:14 PM, Tuomo Keskitalo wrote:
> Hello,
>
> On 02.10.2017 16:52, Michael Kaufman wrote:
>
> > > Also, maybe check that the solver is not making a huge number of 
> > > small steps (stiff problem?).
> >
> > Not sure how I do that.
>
> Sorry, this is not documented, though it is used in test.c. For 
> gsl_odeiv2_driver *d; after driver_apply() you can get the count of all 
> steps from the evolve object via d->e->count and count of failed steps 
> via d->e->failed_steps.

d->e->count:

count at trip: 72
median: 36.0 mean: 39.3616236162 skew: 2.70994388586
min: 3.0 max: 143.0
percent of distribution above: 3.61623616236

=======================================
d->e->failed_steps:

failed_steps at trip: 22
median: 8.0 mean: 9.18450184502 skew: 2.78191881041
min: 1.0 max: 49.0
percent of distribution above: 3.9852398524

correlation coefficient: 0.95291780981
sample distribution size: 2710

So nothing too extraordinary, but is near the top end of the distribution.

> However, if other explicit ODE-solvers have no issues and your solution 
> is always progressing at more or less constant rate, then it does point 
> towards msadams. But let's first try to rule out problem-specific 
> numerical issue. Could you please observe what happens in about 100 
> evolve_apply steps just before tripping? There is example in the manual 
> how to run evolve_apply manually (without driver). I'd be interested to 
> know if solver step length changes a lot just before tripping or not.
If I can find the time, I'll do this.

> It would of course be best if your problem could be reproduced in an 
> example you can share, but let's see how far we can get without.
>
> BR,
> Tuomo