[Boost-bugs] [Boost C++ Libraries] #13524: Parameter mismatch on make_controlled factory (incorrectly constructed controlled_runge_kutta)

Subject: [Boost-bugs] [Boost C++ Libraries] #13524: Parameter mismatch on make_controlled factory (incorrectly constructed controlled_runge_kutta)
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2018-04-16 15:41:21

#13524: Parameter mismatch on make_controlled factory (incorrectly constructed
controlled_runge_kutta)
-------------------------------------------------+-------------------------
 Reporter:  J.Saffer <j.saffer@…>                |      Owner:  karsten
     Type:  Bugs                                 |     Status:  new
Milestone:  To Be Determined                     |  Component:  odeint
  Version:  Boost Release Branch                 |   Severity:  Problem
 Keywords:  parameter, make_controlled, step-    |
  size, slow, adaptive                           |
-------------------------------------------------+-------------------------
 While constructing a ''controlled_runge_kutta'' (might also affect other)
 using the ''make_controlled'' factory, the constructor of
 ''controlled_runge_kutta'' gets passed the wrong parameters.
 The factory calls the constructor with ''(abs_error, rel_error,
 stepper)'', instead of the actual parameters of the constructor
 ''(error_checker, step_adjuster, stepper)''.
 (see ''"boost/numeric/odeint/stepper/generation/make_controlled.hpp:44"''
 and ''"boost/numeric/odeint/stepper/controlled_runge_kutta.hpp:247"'')
 This yields no compile error, since the respective class has the type of
 these paramerts as templates and the constructors of the actual expected
 types have all default parameters, without being explicit.
 This leads to the practically invisible error, where the passed values
 construct the types, expected by the constructor of
 controlled_runge_kutta, by populating the first parameter each (effectivly
 using these constructors as conversion constructors).

 Note: This leads to the maximal step size being set to the relative error
 limit and the relative error limit being set to the default value of
 10^-6^.
 Since one usually sets the relative error limit to a rather low value
 (like the default 10^-6^), this causes the controller to split usually
 small enough steps into even smaller, thus thousands of, substeps,
 drastically increasing computation time.

 I was able to notice this behavior while debugging why my calculation of
 the controlled runge kutta uses unreasonably many substeps, while the
 constant step size runge kutta got a error estimated much lower then the
 error limit of the controller while doing the whole interval in only one
 step.

-- 
Ticket URL: <https://svn.boost.org/trac10/ticket/13524>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.