Unit test and example for Genrou class.

[pelesh]

Description

The 6th order electrical machine model implemented in Genrou class has been tested in an example where results of a simulation for a 2-bus system are compared to Powerworld simulations of the same system, comparing the results to within 3-4 significant digits. That example does not test Genrou methods to the machine precision, which is needed for models of such complexity. This PR adds a unit test for the model residual evaluation function and another example comparing results to Powerworld reference.

Closes #78

Proposed changes

Add a unit test that initializes the Genrou model at a consistent DAE solution and then verifies that all residual vector elements are zero to within machine precision. In addition, a 3-bus example is added which verifies simulation result to the numerical integration tolerance.

Checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.

Further comments

This requires a little bit more work before it is ready for review.

[abirchfield]

Everything looks good. Compiled and ran example 2 on my machine with no issues.

[pelesh]

@abirchfield, the Load component model test for residual evaluation fails in this branch:

test 24
      Start 24: PhasorDynamicsLoadTest

24: Test command: /Users/55y/src/gridkit/build-clang/tests/UnitTests/PhasorDynamics/test_phasor_load
24: Working Directory: /Users/55y/src/gridkit/build-clang/tests/UnitTests/PhasorDynamics
24: Test timeout computed to be: 10000000
24: --- PASS: Test constructor
24: --- FAIL: Test residual
24: 
24: 
24: Test Summary
24: ----------------------------
24: 	Successful tests:     1
24: 	Failed test:          1
24: 	Skipped tests:        0
24: 	Expected failures:    0
24: 	Unexpected successes: 0
24: 
24/26 Test #24: PhasorDynamicsLoadTest ...........***Failed    0.22 sec

[pelesh]

@abirchfield, I believe docs for the PhasorDynamics::Load model need to be updated, as well, after you fixed the bug in the model?

[pelesh]

Everything looks good. Compiled and ran example 2 on my machine with no issues.

Perhaps we should use more descriptive names instead of "Example 1" and "Example 2"?

[alexander-novo]

@pelesh I really don't like the littering of _USE_MATH_DEFINES everywhere - it's almost certainly going to continue to be a problem like this going forward for the MSVC platform (which requires its use to access math constants like M_PI). We should look into defining this macro in cmake rather than in every individual file which needs it. Otherwise I can foresee countless pull requests later adding these defines everywhere whenever someone on Linux needs to use M_PI and forgets to define this. Thoughts?

[pelesh]

@pelesh I really don't like the littering of _USE_MATH_DEFINES everywhere - it's almost certainly going to continue to be a problem like this going forward for the MSVC platform (which requires its use to access math constants like M_PI). We should look into defining this macro in cmake rather than in every individual file which needs it. Otherwise I can foresee countless pull requests later adding these defines everywhere whenever someone on Linux needs to use M_PI and forgets to define this. Thoughts?

My suggestion would be to have a file with constants protected with a namespace and something like constexpr real_type PI = M_PI. We can def and undef _USE_MATH_DEFINES around it. In any case, we need one place where we define $\pi$ in the entire code. I would use a separate PR for that, though.

[abirchfield]

Fixed load bug, including impacts to tests and docs. Still runs great on my machine.