From GridLAB-D Wiki
Jump to: navigation, search

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.

check()

test()

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

kmldump()

subload()

List of Known Modules

Simulation Modules

Ancilatory Modules

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