Closed ghost closed 9 years ago
Hi,
seems, like there was a little bug in odeint. The problem was, that the system is unwrapped in bulirsch_stoer and then passed unwrapped to the underlying midpoint stepper. This creates a copy of the system which is of the type of the base class and hence base::operator() is called in midpoint.
I commited a fix in the current master and I wrote a small test program which produces the desired results, see https://gist.github.com/headmyshoulder/4f11f000cf80e6da59d6 . Does the fix solves your problem?
Wow - this indeed fixes the little problem I had. That's fantastic! Thanks for the incredibly speedy response and fix!
First off: great library!
The following is more a question than an issue, as there are workarounds. I am working with a variety of 'system's that share certain parameters and methods. I was hoping to work with class inheritance to avoid a lot of redundant code. I noticed:
do_step
andtry_step
(I've been usingbulirsch_stoer
andbulirsch_stoer_dense_out
steppers) do not cooperate when my base class is abstract, i.e.,virtual void operator()(...args...) = 0
; obviously, my derived systems do define that operator properly with the needed ODE.stepper.do_step(ref(*this))
works perfectly [forbulirsch_stoer_dense_out
] when included in the base class and called from a derived class. However, when I try to includestepper.try_step(ref(*this), m_Psi, m_time, dt)
in my base class [usingbulirsch_stoer
] and call it from a derived class, I always get stuck in the base class definition ofvirtual void operator()(...args...) = { cout << "this should never be called"; exit(1); }
instead of seeing the overriding operator() in the derived class being evaluated.Am I forgetting something important, or does odeint not fully support working with class inheritance? Thanks in advance!