bug-gsl
[Top][All Lists]
Advanced

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

[Bug-gsl] [bug #52230] odeiv2/msadams fails with order change -2


From: Tuomo Keskitalo
Subject: [Bug-gsl] [bug #52230] odeiv2/msadams fails with order change -2
Date: Sun, 15 Oct 2017 02:42:53 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0

URL:
  <http://savannah.gnu.org/bugs/?52230>

                 Summary: odeiv2/msadams fails with order change -2
                 Project: GNU Scientific Library
            Submitted by: tkeskita
            Submitted on: Sun 15 Oct 2017 06:42:52 AM UTC
                Category: Runtime error
                Severity: 2 - Minor
        Operating System: OSX
                  Status: In Progress
             Assigned to: tkeskita
             Open/Closed: Open
                 Release: 2.4
         Discussion Lock: Any

    _______________________________________________________

Details:

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

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




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52230>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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