Modules are libraries that GridLAB-D can load in that make use of the core callbacks in order to register classes with the core. Modules themselves contain a combination of variables and classes. These classes contain the logic behind the construction and synchronization of objects .
Modules consist of published variables and classes. There are many modules without published variables, and a few modules without published classes, though those are generally special cases that are directly hooked into from the core.
Modules have a major and a minor version number. It is expected that all minor versions within a major version will be backwards compatible, if not forwards compatible. It is expected that any version with a different major version number may not be compatible with any other major version.
Modules may publish global variables that are only relevant to internal operations. These variables are generally published with the module and and two colons as a prefix, such as "module::property".
Modules may publish classes using gl_register_class(). These classes may be referenced within the load file either by the class name, or prefixed with their module and two colons, in order to avoid class name collisions.
Modules may export a number of functions related to how objects are published, that allow module integrity testing, and that describe how the module is created.
This is the entry point into a module's logic, called after a module is named within an input file. The module should verify that it is able to set the callback function table, else immediately return 0. The remainder of the typical init() process is spend registering the module's variables (with gl_global_create()), registering the module's classes (with gl_register_class()), and publishing those classes' variables (with gl_publish_variable()). The module should return a pointer to the CLASS structure from the first registered class. It is not an error to return a null pointer, as some special-case modules do not publish any classes, such as the GLM-Java module.
Used to retrieve module-level properties based on mechanisms internal to the specific module. This system has been deprecated by the global variable system, but is still present for backward compatibility.
Used to set values for module-level properties based on mechanisms internal to the specific module. This system has been deprecated by the global variable system, but is still present for backward compatibility.
Called when the "import [module] [filename]" directive is located in a GLM file. Used for module-specific file processing, such as converting powerflow models from third party formats into GridLAB-D.
Called when the simulation gracefully shuts down, if the 'dumpall' global property is set. Used to export module-specific data, typically for debugging purposes.
Deprecated. Runs module unit tests. Called when GridLAB-D is running in test mode, which requires compiling with the preprocessor directive "_NO_CPPUNIT".
List of Known Modules
- Climate module: contains weather data and reads TMY2 files
- Commercial module: models office buildings
- Market module: provides wholesale market simulation and responsive appliance controllers
- Network module: simulates the transmission level of power grid models
- Powerflow module: simulates the distribution level power grid models
- Residential module: models a single-family home and various home appliances
- Reliability module: runs one-off reliability analysis on Powerflow models