[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael Kaufman
Subject: Re: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY
Date: Mon, 2 Oct 2017 13:23:27 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

On 10/2/17 12:14 PM, Tuomo Keskitalo wrote:

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.


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


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]