Add variable monitor for solver iteration output

[PhilipFackler]

Description

Capability for printing monitored variables during time iterations

Proposed changes

Let each bus and device specify variables to monitor based on *Data input. During Ida::runSimulation allow for monitoring output as well as user-defined step_callback.

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.
• I have updated CHANGELOG.md to reflect the changes in this PR. If this is a minor PR that is part of a larger fix already included in the file, state so.

Further comments

I'm starting this as a draft because I need some feedback before I can consider it completed.

[superwhiskers]

this pull request leaves casing of enums inconsistent in data structures. for instance, the newly added monitorable variables in busdata are all caps, inconsistent with enums in other files. this should be resolved prior to merge.

additionally, we should evaluate whether we are willing to use magic_enum to sidestep the requirement of a SIZE variant, something i worked around with it previously.

[PhilipFackler]

this pull request leaves casing of enums inconsistent in data structures. for instance, the newly added monitorable variables in busdata are all caps, inconsistent with enums in other files. this should be resolved prior to merge.

additionally, we should evaluate whether we are willing to use magic_enum to sidestep the requirement of a SIZE variant, something i worked around with it previously.

Both good points. I'll check the guidelines for enum member styles. If we want to make magic_enum a public dependency that would help with the implementation here a lot. Or we could install it as part of gridkit so users don't have to deal with that. What do people think? I implemented this treating it purely as a build dependency.

[lukelowry]

Other than my one concern regardining output format, this is an invaluable PR. Labeled output data will accelerate verification for the 37/39 bus case and larger cases. Having this in the develop branch would be incredibly valuable right now.

[pelesh]

this pull request leaves casing of enums inconsistent in data structures. for instance, the newly added monitorable variables in busdata are all caps, inconsistent with enums in other files. this should be resolved prior to merge.
additionally, we should evaluate whether we are willing to use magic_enum to sidestep the requirement of a SIZE variant, something i worked around with it previously.

Both good points. I'll check the guidelines for enum member styles. If we want to make magic_enum a public dependency that would help with the implementation here a lot. Or we could install it as part of gridkit so users don't have to deal with that. What do people think? I implemented this treating it purely as a build dependency.

The GridKit code outside the I/O parser should not depend on magic_enum. I would try to avoid it being GridKit library dependency. It should be available only in utilities for building GridKit apps.

[pelesh]

this pull request leaves casing of enums inconsistent in data structures. for instance, the newly added monitorable variables in busdata are all caps, inconsistent with enums in other files. this should be resolved prior to merge.
additionally, we should evaluate whether we are willing to use magic_enum to sidestep the requirement of a SIZE variant, something i worked around with it previously.

Both good points. I'll check the guidelines for enum member styles. If we want to make magic_enum a public dependency that would help with the implementation here a lot. Or we could install it as part of gridkit so users don't have to deal with that. What do people think? I implemented this treating it purely as a build dependency.

magic_enum is an external library over which we have little control. Making it required GridKit dependency is something I would prefer to avoid. I understand it's easier said than done, though.

[PhilipFackler]

Just so y'all know, I'm planning to finish up requested changes and get this updated tomorrow.

[PhilipFackler]

I have added the capability of choosing the output format(s) using the JSON input file. By default, it will print CSV style to the console. I included changes to ThreeBusBasic.json as an example of how to use this. It prints three files (in addition to the console). If you want to change the console style, you just add a format group without the file_name parameter. Let me know what you all think. I'll add documentation, etc... next week. Happy Thanksgiving!

[PhilipFackler]

Not sure why the consumer test is failing (it works locally for me). I'll have to dig into that later this week.

[pelesh]

More offline discussion is needed before this PR can be merged. Some issues to consider:

• Conversion of strings to enums should ideally be in parser functions only. Moving them to component data structures is not an ideal design.
• Setting monitored variables should be done in parser. I am not sure the current solution is sustainable.
• Capitalization of enums should not be changed in this PR.
• It is unclear what is the purpose of the VariableMonitorBase class.

[PhilipFackler]

Conversion of strings to enums should ideally be in parser functions only. Moving them to component data structures is not an ideal design.

@pelesh That IS done only in the parser. If you're referring to the enumLabel function, that is for printing enum values as labels in the monitor output.

[superwhiskers]

overall the code quality looks good. i only have architectural questions that i would prefer be answered before we merge this.

[lukelowry]

Invaluable. Thank you @PhilipFackler ! This opens so many doors for case validation.

Any feedback of value from me will come after I use this feature to validate/debug the larger cases.