Simplify/Fix Adaptivity for Small Errors or no CFL

[Steven-Roberts]

The TINY parameter used in the controllers could cause an error overestimation, particularly for the first step.

[drreynolds]

I am not expert on how robustly various architectures/compilers work with infinity. I'd like to see this PR pass all possible regression tests on all architectures before approving, but if infinity is handled correctly everywhere, then I would approve of these changes.

As another option, we could use the largest/smallest representable floating point numbers in the given precision to avoid having to do arithmetic with infinity.

[Steven-Roberts]

The behavior of pow, abs, min, max, and other functions for inf/nan is specified by the C standard, so I'm not too worried about that. I think a unit test where the error is 0 is warranted to double check. The standard only specifies that pow(0, 0) may cause a domain error (and doesn't even specify what the value could be), and pow(0, y) can cause floating point exceptions for certain y. I think I'll need to handle that more carefully in the controller.

[Steven-Roberts]

After considering the edge cases around pow(0,0), i.e., when there's no local error and a controller exponent is 0, it turns out to be benign. The C standard specifies pow(x,0)=1 for all x, and there's no undefined behavior. The test I added seems to support this for some limited cases.

[gardner48]

For a PI controller should this use the I controller only for the first step?

[Steven-Roberts]

That would be ideal, but I tried to balance that with how many conditions I need to check at every time step, i.e. k3==0 && k4 == 0 && k5 == 0. I can make this change if you think it's worth it. A longer-term change I would recommend is making the error and step histories arrays of exactly the right length rather than fixed $k1$ to $k5$. Then simpler controllers like I don't have to do extra checks and operations on unused k values.

[gardner48]

Instead of checking the k values every time maybe the condition if (SODERLIND_FIRSTSTEPS(C) > 1) could swap 1 for a parameter that's set at construction (or when the parameter values are updated) i.e., it would be -1 for an I controller, 0 for a PI controller, and 1 for a PID controller.

[gardner48]

This example fails after the changes. Not sure why it still prints the output below, maybe a return statement is missing

[Steven-Roberts]

I can't replicate this locally, so I increased the max step limit so it will at least finish the Jenkins test and we can examine the full out file stats. I think it's just a case of the limit being very close to the actual number of steps taken, and these changes pushed it slightly over.