Event system proposed edits + File format

[lukelowry]

Attempting to do a stacked PR on top of @PhilipFacklers changes because they are useful for my other WIP!

Changes

• Moved monitors into the study file specification as opposed to the INPUT_FORMAT.md
• Draft standard of the study file format
• Implementation edits for the new PDsim app
• Move BusFaults out of file format for case and into the study file.

The individual mon fields I believe, should remain in the case file format, but the output sink parameters should be a study/runner level parameter

[pelesh]

I understand rationale for this suggestion but have slightly different view how to go about this:

• One configuration file should specify the case (model) including model outputs (monitored variables).
• The other configuration file should specify solver settings such as tolerance, simulation start and end time, number of times outputs are requested/read, etc.

This division is based on which part of the software is processing what information. The case (model specification) file is processed by the system model constructor, so all the information affecting the model should stay in that file imho. The solver configuration (study) file is processed by the application instantiating the solver and configuring the simulation. That file should not contain information related to modifying/configuring the model.

[pelesh]

I would keep monitors specification in the case file.

[lukelowry]

Thank you for the feedback. I agree with you regarding the boundary of the model and runner. I have a few motivating concerns regarding a future consumer's workflow when using a GK App:

• (Regarding specific signals to be monitored) A researcher may want to run multiple simulations in parallel or use the same 'model' (e.g., the Texas case) for concurrent purposes. Some studies focus only on network signals (bus voltage, power injections), but others may be highly specific (e.g., monitoring a particular substation model and how it interacts with a distant sister site). Do we need to duplicate the entire file and store it on disk to run the same model with different outputs? And what if it's a confidential model?

• (Regarding the write output file of monitors) I imagine an application of GridKit where a developer is using GridKit as the engine to compute a wide class of simulations for an ISO or utility. If one service uses GridKit's stdout with a predefined set of signals to feed information into legacy software, and another service consumes GridKit's .csv outputs for heuristic data in some external optimizer, would they need two separate case files? Even if the only thing I change is what I measure and how I output that measurement?

• or: An ISO or company might provide a contractor with a 'black box' case model for proprietary reasons, but still permit simulations and interaction using some encrypted or hosted build of GridKit. That is more speculative, but might help show how GK may want to separate 'what happens to the model' from 'the information needed to simulate our grid'?

I agree with you, however. Is adding a third input layer for monitoring a poor design direction? Conceptually, I have thought of the monitors as a 'telemetry' or observation tool for the user to measure the model, rather than as part of the model itself. Let me know your thoughts. I am happy to go in either direction. Thanks!