Issues with truncated polynomial order in LeastSquaresFit and LeastSquaresFitHistory

[bwspenc]

Bug Description

The LeastSquaresFit and LeastSquaresFitHistory vectorpostprocessors are both using an option in PolynomialFit (which does the heavy lifting) that automatically truncates the order of the polynomial if an insufficient number of points is provided.

There are a few issues with this:

1. The automatic truncation code requires an arbitrary excessively high number of terms:

      _order = (_x.size() / 10) + 1;

This choice seems totally insane! @andrsd: git blame says you last touched this code. Do you know anything about that?

2. If you don't use the truncation option, there's an error check, but the logic for it is wrong. The < comparison operation should be a <=.

3. If you hit the error, rather than calling mooseError(), it throws a std::domain_error, which doesn't get handled, so the error message never gets printed out.

We need to fix all of these issues. I'm going to provide an option on whether to truncate the polynomial order in those vpps, and add a thorough set of test cases to make sure this is working correctly.

Steps to Reproduce

Use LeastSquaresFitHistory with 3 data points and ask for a 2nd order polynomial. You only get a 1st order polynomial.

Impact

We use this pretty heavily in Grizzly. I'm afraid that we may be inadvertently having the polynomial order truncated in problems we care about.

[andrsd]

git blame says you last touched this code. Do you know anything about that?

I did not write this code. The change you see in git history is from the old SVN days. The date tells me that it was when we rolled out the new MOOSE (what we internally call MOOSE 2.0). We probably moved that file from somewhere else and because git-svn did not handle moves properly it looks like a new file that I wrote.

The true author of this line is @permcody. This change occurred in May 2009, 21f90a9c555a7a9a2226d992a3c466d914f347f4 in git history.

[permcody]

OK - so 2009... A lot has changed since then 😄

1. The automatic truncation code requires an arbitrary excessively high number of terms:
   _order = (_x.size() / 10) + 1;
   This choice seems totally insane! @andrsd: git blame says you last touched this code. Do you know anything about that?

Clearly a hack for the single problem I was running at the time. This is long before I was properly in the framework and utility mindset. It does appear arbitrary so feel free to improve it.

2. If you don't use the truncation option, there's an error check, but the logic for it is wrong. The < comparison operation should be a <=.

Yep

3. If you hit the error, rather than calling mooseError(), it throws a std::domain_error, which doesn't get handled, so the error message never gets printed out.

Now this isn't necessarily a bad choice and we do this for other pure utilities that have zero dependence on MOOSE. It just passes the responsibility to the MOOSE class that calls the utility to handle the error. To call MooseError you'll have to add the MooseError.h header. Also you may want to provide a more informative error about input file parameters or other things more relevant to why the error was produced, which you can't do as easily at this low level.