bugGNU Scientific Library - Bugs: bug #52230, odeiv2/msadams fails with order...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #52230: odeiv2/msadams fails with order change -2

Submitted by:  Tuomo Keskitalo <tkeskita>
Submitted on:  Sun 15 Oct 2017 06:42:52 AM UTC  
 
Category:  Runtime error Severity:  2 - Minor
Operating System:  OSX Status:  Fixed
Assigned to:  Tuomo Keskitalo <tkeskita> Open/Closed:  Closed
Release:  2.4

Sun 22 Oct 2017 08:49:38 AM UTC, comment #2: 

Fixed in commit 1dea7fb057d7f402cbe665f5276db18f1842088c

Tuomo Keskitalo <tkeskita>
Project MemberIn charge of this item.
Sun 15 Oct 2017 07:13:04 AM UTC, comment #1: 

This error seems to originate from a very rare case where msadams operates on method order >2 and then carries out two consecutive failed steps, both of which decrease method order. In normal operation solver is reset after three consecutive failed steps, but this special case of two method order decreases raises error before resetting happens. Solution strategy: Add reset also when two method order decreases happen.

Tuomo Keskitalo <tkeskita>
Project MemberIn charge of this item.
Sun 15 Oct 2017 06:42:52 AM UTC, original submission:  

Subject: [Bug-gsl] msadams.c:973 aborts with GSL_ESANITY
Date: Tue, 26 Sep 2017 14:36:02 -0400
From: Michael Kaufman <kaufmanmc@ornl.gov>
To: -email is unavailable-
CC: Michael C. Kaufman <kaufmanmc@ornl.gov>

Hi all,

since the header says that this is a sanity check that shouldn't happen, I supposed I ought to report it.

-- order change -2
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.

I'm solving a 72 equation ODE.

The form of the equation is:
  dA_m(z)/dz = -a_m*A_m(z)+Sum_n[K_mn(z)*A_n(z)*exp(j*b_mn*z)]

where I split the complex A_m's into real and imaginary parts.

Unfortunately, the exact functional form of K_mn(z) is rather complicated, so there is no simple program (that I can write) that trips this bug.

This is how I initialize:

  driver = gsl_odeiv2_driver_alloc_y_new(&sys, gsl_odeiv2_step_msadams,
                                         0.05, abstol, 0);

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). If I solve just one time with abstol=1-10, then the abort doesn't happen (I'm reasonably sure that my initial conditions are the same) -> call this case 2.

By the by, after turning the gsl_error_handler off, under case 1 the ODE solver continues and delivers an answer that looks the same as case 2 to at least 5 significant digits.

M
------
For continued discussion, see thread https://lists.gnu.org/archive/html/bug-gsl/2017-09/msg00006.html

Tuomo Keskitalo <tkeskita>
Project MemberIn charge of this item.

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tkeskita (Submitted the item)
  •  

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-22 tkeskita StatusIn Progress => Fixed
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.5