Feature requests

[GillisHommen]

The following features have been requested:

• Flex consumption assets; abstract periodic consumption asset that can be flexibly scheduled by an EMS algorithm. Should provide methods like "getHorizonConsumption_kWh(horizon_h)", have a limited max power, and can contain data to allow different consumption patterns in different parts of the year (weekday/weekend, day/night, summer/winter, holidays, etc.). Also should be able to block some times for consumption, such as: only during nighttime hours.
• Mimic 'passive curtailment' of home-PV due to overvoltage? Similarly, mimic passive 'load shedding' of heatpumps and charge poles due to undervoltage? How to prevent excessive switching behavior? Could approximate local voltage as 230+factor*GridNodeLoad_kW, perhaps with a local component per GridConnection to have some heterogeneity.
• Store consecutive results of yearsims to allow comparisons between runs. Multiple instances of energyModel? Or is that overkil? Perhaps make a simResults record (java object) for a number of agent types (GridConnection, GridNode, EnergyCoop), which can be stored in collections to allow reviewing multiple simulations. '(deep-)cloning' of the EnergyModel agent is not available in anylogic, so when multiple energyModel agents would be used, each one needs its populations filled and initialized separately. (very slow!)
• Engine initialisation split up into two sub-functions; one to create all links between agents, and one to set all initial values of states (for example low-pass filters) This allows a proper 'reset' of the model after a yearrun by calling an f_setInitialValues() functions, such that repeated simulations give identical results.
• Statistics on signals; min, max, mean, std-dev, ... Could be combined with accumulator functionality. When no time-series are stored, min, max, mean is still possible.
• More different driving profiles for different types of vehicles. For example: Commute-from-home, commute-from-work, distribution-daytime, distribution-nighttime, etc. (is this really an engine functionality?)
• Object validation in constructors: Add various checks to constructors of objects such as energy assets to ensure they are in a valid state before simulation starts. This can help prevent energy balance errors.
• Transport losses in the electricity grid, which amount to 'about 7% of the transported energy' according to Koen Kok.
• 'Achter de meter', 'directe lijn', 'gesloten distributiesysteem'; basically allowing gridConnections to exchange electricity not only via their main GridNode but also through some other link. Perhaps add a new type of transport asset to allow flows directly between gridConnections? How to maintain consistency of power between gridConnections? Such as asset would be a flex-asset, but it would 'live' in two gridConnections. Not compatible with parallel execution of GridConnections?

The following features have been added (including link to commit!)

• Facilitate simulations with duration less than one full year, including correct KPIs and load duration curves: 28962bf

• Different types of solar panels (mostly orientation). Different size wind turbines with their own production profiles (different wind/power curves, wind patterns). Zero_engine now allows adding custom profiles to each simulation, which can be used to create energy assets of type J_EAProduction with their own production profiles. (the same goes for J_EAConsumption) The enum energyAssetType of the energy asset controls to which category the energy asset is assigned for accounting (ie: c_windAssets, c_pvAssets, etc.) 35aa79d

• Ability to adjust total yearly mileage of vehicles from the project-module (main-model). TripTracker has setAnnualDistance_km() method to set travel distance of vehicle; scales all trips to reach a certain total annual distance. Can lead to infeasibly long/fast trips if used without care!

• f_removeFlows() function in gridConnection, to be used for things like curtailment, load-shifting, etc. Basically to give more flexibility to 'merit order' within gridConnection. Related to execution order of energy assets (or at least potentially serving the same purpose): allowing 'curtailment' of fixed consumption/profile assets. For curtailment of production assets this is implemented as a 'revisit' of the energy flows of the production asset (which is considered a 'fixed' asset) at the end of the GridConnection-merit-order, to correct it's energy flows for that timestep. Another way could be to have a mirror to the f_addFlows() function in the GridConnection, like f_removeFlows(), to be used for curtailment of production but also potentially production and profile assets. ( a5d52d0 )

• Load shifting can be implemented in a manner similar to curtailment, using the f_removeFlows(), with the addition that the 'lost-load' should be recovered at a later time (probably...).

• Add curtailProduction(curtailmentPower_kW) method to production assets, instead of a separate curtailer asset. When the curtialProduction method is called, it can trigger another call to f_addFlows() in the gridConnection with a negative production power. The GridConnection abstract agent now has a function f_curtailment() function to manage curtailment when the variable v_enableCurtailment is true. (6da7855)

• Battery charging/discharging losses (619aa66)

• 'Dynamic' GridNode execution order based on a list of GridNodes, where this list is built 'top-down' by starting from the HSMS gridnodes and listing all its children. This allows an arbitrary 'depth' of the tree, more than just the HSMS and MSLS gridNode levels. Also, prevents gridNodes being skipped for total energy balance, as every unconnection node is treated as a top-level node (directly connected to the HS grid) (6d4699e)

• GridNode livedata en jaartotalen voor visualisatie in Results_UI (70cc5f1)

• Adjust 'MAX_POWER' charging strategy to always charge EVs to their required SOC, even if it means overloading the GC, add boolean to make this behavior optional. (be9e892)

The following features are not planned:

• 'Dynamic' execution order (merit order!) of energy assets per GridConnection. Similar to dynamic execution order of GridNodes; generate a list of energy assets based on some priority metric. What should this metric be? And how to ensure that code to 'operate' each gridNode can run in arbitrary order? Is this really feasible/desirable? For now, the f_addFlows() and f_removeFlows() functions in the gridConnection should provide sufficient flexibility. If really needed, a project can have its own child-agent of the abstract agent GridConnection, implementing a different merit order within a GridConnection.