Suggestion: Add maximum iterations option.

[RebelMoogle]

I have a few experiments with analytical flow fields that don't behave nicely in some areas and cause the integration to explode (too many integration steps), even with setting larger minimum step sizes.

I would love the ability to set a maximum step number, optionally. something like the following: (In runge_kutta.jl, line 223

function oderk_adapt{N,S}(fn, y0::AbstractVector, tspan, btab_::TableauRKExplicit{N,S};
                          reltol = 1.0e-5, abstol = 1.0e-8,
                          norm=Base.norm,
                          minstep=abs(tspan[end] - tspan[1])/1e18,
                          maxstep=abs(tspan[end] - tspan[1])/2.5,
                          initstep=0.,
                          points=:all,
                          maxIterations=0 #optional argument through kwords...
                          )

same file, line 289

## Integration loop
    islaststep = abs(t+dt-tend)<=eps(tend) ? true : false
    timeout = 0 # for step-control
    iter = 2 # the index into tspan and ys
    while true
        # check number of iterations
        if(maxIterations > 0 && iter > maxIterations) #ignore at 0
            warn("Exceeded maximum number of iterations at #$iter.")
            # raise exception here?
            break
        end
        # ...  rest of loop ...
    end

Apologies if this is already present in some other way and I overlooked it. Let me know if you want a test case for the problem mentioned at the beginning.

[tomasaschan]

I am, in principle, for it. The implementation seems fine by me too, although we should make sure that the kwarg is supported for all methods where it makes sense (i.e. not necessarily restricted to oderk_adapt).

What makes the most sense - to limit the total number of steps, over the entire integration interval; or to limit the number of attempts at finding an appropriate step length for the next step?

[RebelMoogle]

I could check the other methods as well and submit the code I have as a pull request?

To me personally the total number of steps seems to most intuitive, the number of attempts to find an appropriate step length seem like a separate issue to me.

[acroy]

I agree that this might be useful to have, although I am not sure about the relations between tolerances, minstep and maxIterations (actually, refinements would be a better name). Could you give an example of how you would use this feature?

I could check the other methods as well and submit the code I have as a pull request?

I think ode23s is the only other method for which this should apply. Note that iter in your code is the index into the given time-step array not the number of interval refinements.

[RebelMoogle]

Actually I was suggesting to only use it for the total iterations, so the above is as intended. The refinement was a later addition.

In my current test-case the integration is continuously refined (smaller step size chosen) but never reaches the final timestep. Increasing the minimum step does not decrease this significantly, and I do need a small minimum step size for other areas (I am calculating a few hundread thousand separate integrations).

The other option would be to implement a domain / bounding box and test for going outside of it. In my current calculations I don't really need the integration to go all the way to the end, if it takes that many steps, chances are the result isn't useful to me anyway. (at least one of the dimensions explodes)

I also had problems with memory because of too many steps taken (and saved)

Also, I would allow me to bring over my code from numpy/scipy more easily. :)