Problem initialization

Initialization functions are necessary for proper definition of the optimization problem. The initialization of a node must be fully defined by an object of type AbstractInitData. The concrete type InitData is implemented with the expected functionality for most problems. It features a dictionary with the keys being the labels of the states subjected to updates. A standard behavior for InitData is provided, which allows for updating considering that the labeled states can be initialized by their previously calculated values at the corresponding time period, i.e. the last implementation time period. The variables to be read from the model can only be indexed over the associated AbstractElement and TimePeriod.

To utilize the AbstractInitData object in the model calculations, additional equations must be provided. That can be done in several ways, and the user is referred to the page on how to adapt EMX elements for examples.

Custom initialization objects

The user that implements new AbstractInitData types must implement methods for the functions that process this object, as well as extra types. The functions to be dispatched upon for a new AbstractInitData are

• _find_update_paths is the function used to detect the fields in the AbstractInitData object to be updated over changing horizons and
• update_init_data! is the function used to update the receding horizon AbstractInitData object based on the solution of the receding horizon problem in a previous time window.

These functions are automatically used in the main function run_model_rh, and they can be easily dispatched upon for custom elements.

In addition, a new subtype of AbstractInitDataPath associated to the new object must be created. AbstractInitDataPath refers to a subtype of AbstractPath, which serves to identify the model variables that need updating (see the section on the code structure for more details). The standard behavior for this object is implemented in InitDataPath, which simply contains the variable key to be updated.

One example for the implementation of a new initial data is given by TransInitData in the EnergyModelsGeography extension and its internal library:

• TransInitData,
• TransInitDataPath,
• EMRH._find_update_paths,
• EMRH.update_init_data!
• POIExt._update_parameter!, only required for the ParametricOptInterface extension.

The extension POIExt can be accessed for dispatching through

using EnergyModelsRecedingHorizon
using ParametricOptInterface

const EMRH = EnergyModelsRecedingHorizon
const POIExt = Base.get_extension(EMRH, :POIExt)

function EMRH._reset_field(
    m,
    x_rh,
    res_type::InitReset{VectorInitDataPath},
    𝒰::UpdateCase,
    𝒯ᴿᴴ::TimeStructure,
)
    val_par = MOI.Parameter.(res_type.val)
    res_type.var = @variable(m, [eachindex(res_type.val)] ∈ val_par)
    @reset res_type.lens(x_rh) = res_type.var
    return x_rh
end