Technical debt zero_engine [evolving issue]

[GillisHommen]

Following issues need to be solved in [zero_engine.alp]:

• Still possible to make an incorrect GridNode-tree by assigning 'circular dependencies' between GridNodes; this will probably lead to 'lost energy' from those GridNodes.
• Self-consumption on the gridConnection is calculated as: v_totalSelfConsumedEnergy_MWh = max(0,v_totalEnergyUsed_MWh - v_totalImport_MWh). For GCs with only a conversion asset (such as electrolyser!) where one energy carrier is imported and another is exported, total Import is non-zero (electricity), while selfConsumption is zero (no generation), and energy use is lower than import (due to the export of hydrogen). However, if there is also a non-zero selfConsumption on the gridConnection (such as heatpump for heating, or solar PV for EV charging), the electricity import for hydrogen will incorrectly reduce the total selfConsumed energy. How to fix this? This is not an issue of totalling over all timesteps, the same problem occurs within a single timestep. The real issue might be that the concepts of self-sufficiency are not really compatible with storage and conversion assets, when those assets lead to additional imports/exports, so they are not strictly for 'own use'.
• Repeating simulations doesn't give exactly the same result. Not all states properly reset? Happens only when battery is present?
• What is the effect of daylight-saving in the model?? Certainly not all aspects of the model correctly deal with this... How does Anylogic handle this?

Following issues have been solved:

• Methane, Hydrogen and Diesel 'import' totals will be negative when there is nett export. Is this ok for now? If so, add option for hydrogen import to be negative (meaning export!) to results_ui. Otherwise, split into import and export and update results_ui accordingly. -> This is tackled in the flowsMaps update of the engine: Full energycarrier flexibility via flowsMaps (instead of hardcoded set of energyCarriers) #83

• Using timestep_h other than 0.25 hour: Fixes to DLR and f_manageActivities() method of tripTrackers to work with any timestep. Different timeSteps can now be used with (approximately) the same results. Tried: 0.5h, 0.4h, 0.25h, 0.2h and 0.1h. ( 4facee7 )

• Memory use of arrays in GridConnections (35040 doubles each) limits model-size; residential areas with 1000's of houses can not run on systems with limited RAM. -> Created ZeroMath.jar package with custom 'ZeroAccumulator' object, which can store either complete timeseries or just (incremental) sums. This allows control over the memory use per GridConnection. Currently, only the yearly electricity balance is kept as a full 35040-length time series, all other annual values are simple sums, the time-series per timestep are not stored. Winter/summer-week still store the full 672 elements. Fixed in (c882923)

• Weekend/weekdays are on hardcoded dates, (don't even know for which year?!), which probably doesn't align with profiledata. Year needs to be an input to the engine, where the engine can derive by itself which are week- and weekend days. Fixed in (264c42e) Project-main model still has to provide the correct profiles for weather and consumption!

• Collection c_EVs in energyModel is redundant and prone to being forgotten when creating EVs. Can easily be removed from model, only change needed in f_sumBatteryUse. Fixed in (bcdc4af)

• Electric vehicle with 'passenger vehicle' behavior can cause energy balance errors. Haven't found the reason yet. It appears the energyUse_kW values from J_EAEV that are forwarded to the gridConnection are sometimes too low, compared to the total energyUsed_kWh of the energy asset. -> This happened when the vehicle had an endTrip() and startTrip() call in the same timestep, causing it to skip the forwarding of energyUse_kW to the gridConnection for that endTrip(). Fixed in (9c3a39a)

• Energy accounting of curtailer asset leads to failed energy balance check (two selfsufficiency calcs don't match)

• GridConnection nighttime/weekend opwek negatief; wsl fout in berekening.

• Facilitate different types of windmills (different weather profiles, hub-heights) and PV-panels: now possible via custom profiles per project, allowing also the use of different production patterns for different windmills and PV panels.

Following issues are known but are not a simple fix

• Battery charging strategy needs to be hand-tuned for every specific model setting. Could try a variant that uses the v_totalPVpowerinstalled_kW and v_totalWindpowerInstalled_kW together with weather forecasts for a more general-purpose strategy. That assumes the battery is always balancing the 'whole model' though.