Dev:Module

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.

Module Contents
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.

Versioning
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.

Variables
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".

Classes
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.

Module Interface
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.

init
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.

getvar
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.

setvar
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.

import_file
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.

export_file
Called when the simulation gracefully shuts down, if the 'dumpall' global property is set. Used to export module-specific data, typically for debugging purposes.

test
Deprecated. Runs module unit tests. Called when GridLAB-D is running in test mode, which requires compiling with the preprocessor directive "_NO_CPPUNIT".

Simulation 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

Ancilatory Modules

 * Reliability module: runs one-off reliability analysis on Powerflow models

Support Modules

 * Assert module: contains objects that are used in test modules by breaking the simulation if observed values deviate from expected values.
 * Java module: provides JNI interface for loading modules written in Java
 * Tape module: object boundary condition I/O module