Model object

The anyModel object is the overarching structure that contains all data and objects of particular energy system model created with AnyMOD.

anyModel(inDir::Union{String,Array{String,1}}, outDir::String; kwargs)

In- and output files

The constructor function above has two mandatory arguments that the directories for in- and output files. inDir::Union{String,Array{String,1}} specifies the directory (or directories) of input files. This can either be a string or an array of strings, if input files are spread across different directories.

All .csv files within the provided directories (and their sub-directories) starting with set_ or par_ will be read-in as an input file. Other files are ignored and can be used for documentation. Within the specific files, only columns whose name contains one of the following keywords are actually read-in: parameter, variable, value, id, region, timestep, carrier, technology, and mode. Other columns can be used freely for documentation.

Reserved keywords

Within the input files all is a reserved keyword. For an explanation on how it is used, see Time-steps.

outDir::String: defines the directory of output files. All reporting files including status reports, results, or graphs are written to this directory.

Optional arguments

Additionally, the constructor accepts a list of optional arguments listed in the table below.

argument	explanation	default	group
`objName`	internal name of the model object added to the name of output files and printed during reporting	`""`	data handling
`csvDelim`	specifies the delimiter used within the read-in csv files	`","`	data handling
`shortExp`	interval in years between steps of capacity expansion	`10`	model generation
`supTsLvl`	depth in the tree of time-steps that defines the superordinate dispatch level (usually years)	`0`
`redStep`	scales down energy quantities within the model, relevant when working with reduced time-series	`1.0`
`decomm`	controls if the model performs endogenous decommissioning, see decommissioning constraints for implementation available options are: `decomm`: capacities are decommissioned endogenously, once decommissioned capacities cannot be put into operation again `recomm`: no endogenous decommissioning, operated capacities equal installed capacities `none`: capacities are decommissioned endogenously and can be put back into operation	`:decomm`
`interCapa`	capacity expansion can be modelled at a resolution less detailed than yearly, this option determines how capacities are distributed among the subsequent years in this case available options are: `linear`: expansion is equally distributed among years resulting in a linear increase `none`: all expansion occurs in the first year	`:linear`
`reportLvl`	controls the frequency of writing updates to the console	`2`	reporting
`errCheckLvl`	controls the frequency of checking for errors	`2`
`errWrtLvl`	controls the frequency of writing to the report file	`1`
`avaMin`	availabilities smaller than this value are set to zero avoids high coefficients in conversion and storage capacity restriction, because availabilities are inversed (see Range of factors)	`0.01`	performance and stability
`emissionLoss`	determines if losses from exchange and self-discharge of storage are subject to emissions (see Range of factors)	`true`
`checkRng`	if set, reports all constraints whose range exceeds the specified value type is `Float64`	`NaN`
`scaFac`	scales different groups of variables within the model format for argument is `(capa = 1e1, oprCapa = 1e2, dispConv = 1e3, ...)` see Column scaling for details and defaults
`coefRng`	specifies the maximum range of coefficients in the matrix and right-hand side of the model's underlying optimization problem format for argument is `(mat = (1e-2,1e5), rhs = (1e-2,1e2))` see Row scaling for details and defaults
`bound`	sets external bounds for all capacities and dispatch variables (in GW) and for the objective value (in Mil. €) see Variable limits for details and defaults format for argument is `(capa = NaN, disp = NaN, obj = NaN)`

Fields

Relevant fields of the model object include:

sets::Dict{Symbol,Tree}: sets defined within the model and their tree structure each saved as Tree object (see Sets and mappings for details)
parts::NamedTuple: all parts of the model, these contain the specific parameters, variables, and constraints (see Parts for details)
report::Array{Tuple,1}: entries for writing to the reporting file (see Error handling for details)
graInfo::graInfo: properties for creation of plots and graphics, can be used to adjust colors and labels (see Styling for details)
optModel::Model: the actual JuMP object of the models underlying optimization problem