Req:Subsecond

This document describes requirements for the subsecond simulation capability for GridLAB-D.

= Application Concept =

GridLAB-D users would like to run parts of models at subsecond time resolution by switching from the quasi-steady event simulation mode to a finite time-difference mode with homogeneous fixed time step.

Definitions

 * Event mode : This refers to the conventional simulation mode of GridLAB-D, i.e., event-driven clock updates.


 * Delta mode : This refers to the subsecond simulation mode of GridLAB-D, i.e., finite-difference clock updates.


 * Coherent model : This refers to models in which all object clocks are synchronized. Models that have diverse object clocks are described as incoherent models.


 * Consistent model : This refers to coherent models for which all object states are consistent. Models that are coherent but not consistent are described as inconsistent models.


 * Steady model : This refers to consistent models for which all object states remain unchanging or in a closed subsecond cycle of states in delta mode. Models that are consistent but not steady are described as non-steady models.

= Requirements =

R1

 * Simulation mode control : The simulation mode shall be controlled by a global variable that identifies which mode the simulation is running in, event time mode or finite time-difference mode.

R2

 * Simulation mode switching : The simulation mode shall be switched by the modules. The core shall only switch from delta to event when exceptions are encountered or when all modules indicate the model is steady.


 * Delta mode switch : The simulation shall switch from event to delta simulation modes only when the model is consistent (see Definitions)


 * Event mode switch : The simulation shall switch from delta to event simulation modes only when the model is coherent (see Definitions).


 * Delta mode time limit : The simulation shall process in delta mode for a maximum time that shall be specified by the user with a default of 1 hour.

R3

 * Time step control : The time step shall be controlled by a global variable with resolution sufficient to model up to $$10^9$$ time step per second.

R4

 * Object update order : Objects shall be updated in the bottom-up rank order (0->N) with objects of the same rank being executed in parallel when possible.

R5

 * Class export function : GridLAB-D classes that support finite-time difference models shall be required to implement an update function to support finite-time difference updates.

R6

 * Object update enable flag : Objects shall be required to assert when they are to be included in finite-time difference updates.

R7

 * Update callbacks : Modules shall be notified of the absolute time at the start of a series of finite time-difference updates, between loops of updates when the clock changes, and at the end of a series of finite time-difference updates.

R8

 * Profiling : The following performance data shall be collected to allow profiling of the delta mode simulation:


 * Total delta mode time
 * Initialization time
 * Preupdate time
 * Update time
 * Interupdate time
 * Postupdate time
 * Average timestep
 * Minimum timestep
 * Maximum timestep

= Validation =

The automatic validation test for the core implementation of delta mode shall establish the following:


 * Default values : The default values for the global variables shall be verified.


 * Variable control : The ability to evaluate and control the global variables related to delta mode shall be established.


 * Time step control : The ability to control the number and duration of the delta mode time step shall be established.


 * Time limit control : The ability to control the total runtime in delta mode shall be established.


 * Erroneous object : The ability to detect an object requesting delta process when its class does not support it shall be established.