Pyomo.DoE: adding more verbose output for sensitivity analysis

[smondal13]

Fixes # .

Summary/Motivation:

• Adding more verbose is helpful to analyze the problem
• Adding a new method to check the FIM in the utils.py can help in the general usage of the method.
• Adding a new standalone function in utils.py to calculate different metrics of the FIM is helpful in case the user does not want to build the get_labeled_model().
• Adding arguments in the reactor_example.py will help with the testing.

Changes proposed in this PR:

• added eigenvalues, determinant of FIM, and trace of FIM for sensitivity output in compute_FIM_full_factorial()
• added check_FIM() in utils.py by separating it from check_model_FIM() in doe.py
• added compute_FIM_metrics() in utils.py
• added get_FIM_metrics() in utils.py
• added arguments in the reactor_example.py

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[smondal13]

@adowling2 @djlaky ready for early feedback

[adowling2]

Next step:

• Also add solver status

[adowling2]

@smondal13 See #3532 for an example of what @jsiirola is suggesting

[smondal13]

@blnicho, I have added the print statement, and on my Mac, the values of "log10 D-opt" are exactly the same as the "log10_D_opt_expected" values. test_doe_solve.py passed all the tests on my machine. As per your suggestion, I have changed atol = 1e-6 from its default value, atol=1e-8. I hope this works for other operating systems.

I have also solved the import issue.

[blnicho]

Tests are still failing due to slight numerical differences across different operating systems. Try changing these to use self.assertStructuredAlmostEqual(value, expected) instead of the combo of assertTrue and np.allclose. I think this will print out which values are different when the test fails without needing the explicit print statement you added above. You may have to use Python lists of floats instead of numpy arrays and data types. Once we figure out the tolerance to use for "log10 D-opt", I'm expecting we'll see similar numerical issues with the checks below.

Suggested change

	self.assertTrue(
	np.allclose(ff_results["log10 D-opt"], log10_D_opt_expected, atol=1e-6)
	)
	self.assertStructuredAlmostEqual(ff_results["log10 D-opt"], log10_D_opt_expected, abstol=1e-4)

[smondal13]

@blnicho, I have changed the design_ranges for the example in test_doe_solve.py . Previously, the values of D-opt were very small. I have also changed the datatype of the lists. These changes will probably solve the numerical issue.

[blnicho]

@smondal13 the lint check failed. Please run black on this again.

[smondal13]

@blnicho, I have changed the example again. This time, it has passed all the checks, except one.