class - Class definition directives
Synopsis
class class-name { [public] GLM-type property-name[Units]; protected GLM-type reference-name[Units]; private C-type private-name; intrinsic create (object parent) { // ... return SUCCESS; // or FAILED }; intrinsic init (object parent) { // ... return SUCCESS; // or FAILED }; intrinsic isa (char* class-name) { // Template:NEW30 ... return true; // or false }; intrinsic precommit (void) { // Template:NEW30 ... }; intrinsic presync (TIMESTAMP from, TIMESTAMP to) { // ... }; intrinsic sync (TIMESTAMP from, TIMESTAMP to) { // ... }; intrinsic postsync (TIMESTAMP from, TIMESTAMP to) { // ... }; intrinsic plc (TIMESTAMP from, TIMESTAMP to) { // ... }; intrinsic commit (TIMESTAMP from, TIMESTAMP to) { // Template:NEW30 ... }; intrinsic notify (char* property-name, int event, void* value) { // Template:NEW30 ... }; function function-name (call arguments...) { // code }; }
Description
In GridLAB-D, a class is a named structure associated with a particular module or a runtime GLM file that is registered with the GridLAB-D core. A class can be defined or extended within an input file, publish properties, and export callback functions. At minimum, a class must define how it is constructed, and what it does during each synchronization time step.
The class directive can be used to alter the structure of an existing class.
commit
Prior to Hassayampa (Version 3.0)
- intrinsic commit (void) {...}
- The commit function is run after all synchronization passes have been completed. The commit function must return SUCCESS or FAILED to indicate the result. The simulation will stop if the return values is not SUCCESS.
As of Hassayampa (Version 3.0)
- intrinsic commit (TIMESTAMP from, TIMESTAMP to) {...}
- The commit function is run after all synchronization passes have been completed. The commit function must return a TIMESTAMP later than to (or TS_NEVER) to indicate the success. The simulation will stop if the return values is not later than to.
create
- intrinsic create (object parent) {...}
- The create function is run before user-defined values are loaded and init is performed. This event allows you to set up each object prior to user values being set by the GLM file. This is the time to set default values and values used to detect whether the user has defined required values (e.g., negative or zero values that are not valid). The create function must return SUCCESS or FAILED to indicate the result. The simulation will stop if the return values is not SUCCESS.
init
TODO:
isa
TODO:
notify
TODO:
plc
TODO:
postsync
TODO:
precommit
TODO:
presync
TODO:
sync
TODO:
Caveat
You should not define classes that are already defined in modules. There's nothing to prevent users from doing this, but the behavior of GridLAB-D under such conditions is not defined.
Windows users must have MinGW installed on their system for the class directive to load properly for anything other than adding public properties.
Examples
- Verifying class structures
To verify the structure of an existing class use the syntax:
module climate; class climate { double temperature[degF<math>]</math>; }
If the variable temperature is defined but is not a double with units degF, then the load of the GLM file will fail. This allows modelers to be certain that the variable and units remain as expected when a module is loaded.
- Altering class structures
To alter the structure of an existing class by adding new variables, use the syntax:
module climate; class climate { double elevation[ft]; }
If the variable elevation is not defined, then it will be added with the units specified.
- Creating new classes
To create a new runtime class with a double called elevation measured in [ft] use the syntax:
class my_class { double elevation[ft]; }
TODO: Add an example of a full-fledged class with runtime components.