Fix timestep control

[ketch]

This fixes a bug in which very small timesteps were forced to be larger. Now we check the step size relative to the overall simulation time.

[ahmadia]

David, do you have a fix for #258 in this pull request here as well?

Your updated logic seems fine to me. This seems reasonable when the time steps are very small (which is where I guess you were seeing incorrect behavior), but may allow time steps that the user does not want. Perhaps in the future it would make sense to allow the user to specify a set of tolerances for relative and absolute minimum step sizes that can be checked at this stage.

[mandli]

Right now you are multiplying by the time in solution rather than the overall simulation time which for large solution.t would break this check. Maybe multiplying by solver.dt or tend - solution.t would be better?

In response to @ahmadia's comment, I think those were probably leftover from when we were debugging the WENO routines. Those changed I don't think actually fix issue #258.

[ketch]

@mandli I believe that the reason for this check in the first place is to avoid an infinite loop if solver.dt/solution.t is on the order of machine epsilon (so adding dt doesn't change solution.t at all). Thus I think this scaling is precisely what's necessary. Do you agree?

[mandli]

I see what your saying, it's the relative size of solution.t and solver.dt that matters here. I think I was confused by the use of solution.t as an indication of the overall solution time where solution.t - t0, where t0 is the beginning of the simulation, is the overall length of time for the simulation.

[coveralls]

Changes Unknown when pulling 8ddc35a on ketch:fix_timestep_control into * on clawpack:master*.