From GridLAB-D Wiki
Jump to: navigation, search

 Approval item:  REQUIREMENT Grizzly (Version 2.3)

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 [math]10^9[/math] 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.

See also