Nobody yet wants to explain it?
The standard reason for this error is because you are creating a problem that is too stiff for the ODE solver to handle.
In there you can find some characterizations of what a stiff equation signifies, as well as some examples of classically stiff systems. The one I tend to think of is an atmospheric system model, used as the sun is rising. You would see sudden large transients that will also very quickly decay (think of turbulence in the system), while other things happen more slowly. Chemical reaction systems can also have the same behavior. Systems of springs, where one spring has a very different rate constant from the others could be an example too.
The ODE solvers in MATLAB (like ode45, for example) will reduce the step size as needed when the enter a problematic part of the solution. But if the needed reduction in step size is too small, then ODE45 will give up. Stiff solvers (in MATLAB, they are ode15s, ode23s, and ode23tb) employ methods specifically designed to handle such problems.
MATLAB even provides a classically quasi-stiff example problem, in vdp1000.m. This has the defining line of:
dydt = [y(2); 1000*(1-y(1)^2)*y(2)-y(1)];
We can try it out.
tic,[t,y] = ode15s(@vdp1000,[0 3000],[2 0]);toc
Elapsed time is 0.076076 seconds.
ode15s returned with a solution almost instantly. By the density of points in certain regions of the curve though, you can see that it had to greatly reduce the step size to meet the default integration tolerances. Other solvers, for example ode23tb have a similar profile. There are still places where the time step suddenly gets small.
tic,[t,y] = ode23tb(@vdp1000,[0 3000],[2 0]);toc
Elapsed time is 0.097514 seconds.
The spacing between points has changed a wee bit, but not that dramatically so. The clearest difference is it seems to have chosen a relatively large step in some places. But now, if I replace it with a call to ode45, while the other functions came back instantly for me, ode45 was slow.
tic,[t,y] = ode45(@vdp1000,[0 3000],[2 0]);toc
Elapsed time is 13.815437 seconds.
Perhaps this next plot will say as much:
So ODE45 had to work quite diligently over almost the entire curve. Only rarely was it able to come up for air and use a reasonably large step size, although it did not completely give up. A reasonably small step size was adequate here, since the problem is not really that stiff as things go. But for seriously stiff problems, ODE45 can sometimes be foreced to reduce the relative step size to eps, or smaller. And then ODE45 just gives up, getting too upset to continue. Then you will see a message like this:
"Unable to meet integration tolerances without reducing the step size below the smallest value allowed (1.136868e-13) at time t=51"
So what are you doing? This is difficult to know for sure, and why you have likely found nobody yet to answer your question. We don't see your code, not that I even remotely wish to see it. You have a moderately large problem, but one where you then randomly varied some of the parameters as a function of time. A characteristic of random numbers is some of the time, you get stuff in the tails, a parameter wanders into a corner where things just go to hell, and no solution is then available.
You appear to be generating systems of ODEs that may sometimes be far too randomly nasty, because of the randomly generated constants in there. For some sets of those constants the problem is getting getting just too stiff. That means the solvers need to use really, really small time steps. As you saw, even the stiff solvers were sometimes forced to reduce the time step, and that was for only a moderately stiff problem. You even point out that when you use parameter sets that are comparable to ones found in the literature, things worked well.
Sorry, but this is not a bug in the source code, perhaps something you can fix in ode15s. Inside the code, you will probably see a point where there is a sometimes ill-conditioned linear equation that is solved. When that linear system becomes rank deficient or at least so in double precision arithmetic, effectively numerically singular? This forces a reduction in the step size necessary to meet the integration tolerances to be too small to continue.
Not all problems will have a viable numerical solution. And, even were you to work in a higher precision, thus able to use smaller step sizes where really needed, the solution time will probably get absurdly large because of the infinitessesimally small step sizes needed. Higher precision code also runs much more slowly too.