D3.8: Description and report of developed multi-physics SAInt modelling tool for network coupling and optimisation. Final version
Abstract
This deliverable describes and reports on the developed multi-physics SAInt modelling tool for network coupling and optimisation. Final and revised version.
Full text
HYPERGRYD. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 101036656 WP3 – ICT MODULES AND SIMULATION TOOLS Task 3.5 Development of an energy network modelling tool to plan and operate coupled gas, electricity, and thermal networks D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimisation. Final version Ref. Ares(2024)6803103 - 26/09/2024
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 2 DISCLAIMER The opinion stated in this report reflects the opinion of the authors and not the opinion of the European Commission. All intellectual property rights are owned by HYPERGRYD consortium members and are protected by the applicable laws. Reproduction is not authorised without prior written agreement. The commercial use of any information contained in this document may require a license from the owner of that information. ACKNOWLEDGEMENT This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement Nº 101036656.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 3 Project Project Acronym HYPERGRYD Project Title Hybrid coupled networks for thermal-electric integrated Smart Energy Districts Grant Agreement number 101036656 Call identifier H2020-LC-GD-2020 Topic identifier LC-GD-2-1-2020 Innovative land-based and offshore renewable energy technologies and their integration into the energy system Funding Scheme Research and Innovation Action Project duration 42 months (From 1 October 2021) Coordinator ARCbcn Website http://hypergryd.eu Deliverable Deliverable No. 3.8 Deliverable title Description and report of developed multi-physics SAInt modelling tool for network coupling and optimisation. Final version. Description Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final and revised version. WP No. WP3 Related task Task 3.5 Development of an energy network modelling tool to plan and operate coupled gas, electricity, and thermal network Lead Beneficiary 10 - encoord GmbH Author(s) Nicola Zaccarelli, Edward Xu, Getnet Ayele, Emre Utku Solak Contributor(s) Mauro Cornaglia (ENVIPARK), Michał Gliński (IMP-PAM) Type R Dissemination PU Public Language English – GB Due 30/09/2024 Submission date 26/09/2024 Version Date Authors Description V.0.1 04/09/2024 encoord GmbH (ENCO) The initial complete draft of the document. V.0.2 25/09/2024 encoord GmbH (ENCO) Revision based on reviewers’ comments V.1.0 26/09/2024 Coordinator (ARCbcn) Final deliverable
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 4 Table of Contents 1 Executive Summary .............................................................................................. 12 2 Introduction ......................................................................................................... 13 2.1 Scope ....................................................................................................................... 13 2.2 Audience ................................................................................................................. 13 2.3 Definitions / Glossary.............................................................................................. 13 2.4 Abbreviations .......................................................................................................... 13 2.5 Contributions of Partners ....................................................................................... 14 2.6 Relation to Other Activities .................................................................................... 14 2.7 Structure ................................................................................................................. 15 3 General Structure of SAInt .................................................................................... 16 3.1 Product Overview ................................................................................................... 19 3.2 Product Architecture and User Interfaces .............................................................. 20 3.2.1 SAInt GUI.......................................................................................................................... 21 3.2.2 SAInt API .......................................................................................................................... 22 4 Energy System Model Structure ............................................................................ 26 4.1 Network .................................................................................................................. 27 4.2 Objects .................................................................................................................... 27 4.3 Scenarios ................................................................................................................. 27 4.4 Solutions ................................................................................................................. 28 5 Scenarios in SAInt ................................................................................................. 36 5.1 Overview of Available Scenario Types .................................................................... 36 5.2 Electric Scenarios .................................................................................................... 39 5.2.1 Power Flow (ACPF/UACPF) .............................................................................................. 39 5.2.2 Optimal Power Flow (ACOPF) .......................................................................................... 41 5.2.3 Production Cost Modelling (DCUCOPF) ........................................................................... 42 5.3 Gas Scenarios .......................................................................................................... 44 5.4 Thermal Scenarios .................................................................................................. 46 5.1 Combined Scenarios and Co-scenarios ................................................................... 48 6 Documentation and Data ...................................................................................... 50 6.1 SAInt Documentation ............................................................................................. 50 6.1.1 Reference Guide .............................................................................................................. 50 6.1.2 How-to Guides ................................................................................................................. 50
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 5 6.1.3 Tutorials ........................................................................................................................... 51 6.1.4 Learn More ...................................................................................................................... 52 6.2 Data Provider Integration ....................................................................................... 52 6.2.1 Solar Weather Data ......................................................................................................... 52 6.2.2 Wind Weather Data ......................................................................................................... 52 6.3 Model-Ready Datasets ............................................................................................ 55 6.3.1 Non-commercial Model-ready Datasets ......................................................................... 55 6.3.2 Commercial Model-ready Datasets ................................................................................. 56 7 Data Importing Tools ............................................................................................ 57 7.1 Synergi Gas to SAInt ................................................................................................ 57 7.2 CYME to SAInt ......................................................................................................... 57 7.3 OpenDSS to SAInt ................................................................................................... 58 7.4 PSS®E to SAInt ......................................................................................................... 58 8 Software Installation and Management ................................................................ 59 8.1 System Requirements ............................................................................................. 59 8.2 SAInt Download and License Management ............................................................ 59 8.3 License Types .......................................................................................................... 59 9 SAInt Objects Overview ........................................................................................ 60 9.1 Electric objects ........................................................................................................ 62 9.2 Gas objects .............................................................................................................. 65 9.3 Thermal objects ...................................................................................................... 68 9.4 Combined electric-gas objects ................................................................................ 70 10 Mathematical Models ........................................................................................... 72 10.1 Steady-state Model of a Thermal Network ............................................................ 72 10.1.1 Node level equations................................................................................................... 73 10.1.2 Branch Level Equations ............................................................................................... 75 10.1.3 Externals ...................................................................................................................... 76 10.1.4 Control Mode .............................................................................................................. 77 10.2 Simulation and Complexity of the Problem............................................................ 78 10.3 Steady-state AC Power Flow (ACPF) Model of Electric Network ........................... 79 10.3.1 Branch Equation .......................................................................................................... 80 10.3.2 Nodal Equation ............................................................................................................ 80 10.3.3 Equations for Externals ............................................................................................... 81
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 6 10.3.4 Control Modes in ACPF ............................................................................................... 81 11 Examples of Applications ...................................................................................... 83 11.1 Electric Network Example ....................................................................................... 83 11.1.1 The IEEE 39-bus Test Bench ........................................................................................ 83 11.1.2 Preliminary Model for the EnviPark Electric Network ................................................ 87 11.2 Thermal Network Example ..................................................................................... 90 11.2.1 Barry Island testbed .................................................................................................... 90 11.2.2 Prototype model for the Sonnenplatz thermal network ............................................ 94 11.3 Electric-Thermal Co-Simulation Example ............................................................... 98 11.3.1 Preliminary model of the EnviPark combined electric and thermal networks ........... 98 12 Conclusions ........................................................................................................ 104 13 References ......................................................................................................... 105
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 7 List of Figures Figure 1. Software architecture of SAInt and CodeMeter for license management. ......................... 20 Figure 2. Main elements of the dock panel of SAInt GUI. Numbers indicate: (1) the project explorer, (2) the model explorer, (3) the map window, (4) the script editor, (5) the property editor, (6) the workspace, (7) the command window, (8) log window, and (9) the chart window. Number (10) indicates the entry View in the ribbon bar from where the user can control the previous windows.22 Figure 3. SAInt structure where a model has a network, scenarios, and solutions layers. This model approach addresses the efficient simulation or optimization of single energy systems. SAInt allows for an extra class of networks, called HUBS, which defines the coupling points between existing singleenergy systems to carry out a combined simulation or a co-simulation. ........................................... 26 Figure 4. Solar weather resource data providers covered by NSRD and PVGIS (colours described in Table 5). ............................................................................................................................................... 53 Figure 5. Wind weather resource data providers covered by NREL Wind Toolkit (colours described in Table 6) ................................................................................................................................................ 54 Figure 6. Diagram representing all supported objects in SAInt 3.5 and their parent-child relationships. From the top-left corner and clockwise, the hierarchical structure of an electric network, a gas network, a thermal network, and a hub system for coupling electric and gas systems. .................... 61 Figure 7. The two modelling viewpoints used in SAInt to describe a thermal network. At the top, the hydraulic viewpoint sees water pumped to circulate within pipelines and heat exchangers in the hot and cold sub-networks. At the bottom, the heat viewpoint focuses only on the hot part, which delivers heat from supplies to demands. ......................................................................................................... 72 Figure 8. PI-equivalent model of an electric branch. 𝑍12=𝑅+𝑗𝑋 represents the series impedance of the line, while the 𝑌11 and 𝑌22 represent the shunt admittance parts. For an electric line and a transformer with a nominal turn ratio, Y11, and Y22 are equal and represent half of the shunt admittance of the branch. For a transformer with an off-nominal turns ratio, or with a tap position and phase adjustment, 𝑌11 and 𝑌22 will be generally different. The same is true if there are different shunt capacitors at the two sides of the node. ................................................................................... 80 Figure 9. Example of the SAInt interface showing: the Model Explorer with the main objects making up the model for the IEEE 39-bus power system (see numbers in brackets for the count of such objects), the Map Window with power system with nodes indicating the voltage magnitude (per unit) and lines indicating the voltage angle (in degree) for a steady state ACPF simulation, and the Property Editor showing some of the details of the selected bus number 2. ................................................... 84 Figure 10. An example of the hourly dynamic of the total active power of one of the demands in the electric model (i.e., demand “A2_OFFICE”) for the ACPF scenario for the EnviPark model during the simulated period. The example is based on a virtual scenario using fictional data matching the range of the real demand and it is used as a proof of concept..................................................................... 88 Figure 11. Active power extracted from the external transmission line (A) and produced by the hydropower facility (B) or the photovoltaic panels (C) in the EnviPark complex during the simulated period. The hydropower and PV data are actual profiles used as input to the model. The external
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 8 transmission line data are one of the results of the ACPF simulation. The example is based on a virtual scenario using fictional data and is used as a proof of concept. ........................................................ 88 Figure 12. An example of the SAInt interface showing: the Model Explorer with the main objects making up the model (see numbers in brackets for the count of such objects), the Map Window with a prototype electric network of EnviPark on top of Google Map, with nodes and lines indicating the base voltage, and the Property Editor showing details of the electric demand “A2_OFFICE”. Active power values are for the solved steady state ACPF simulation used as initialisation state for the quasidynamic ACPF simulation. ................................................................................................................... 89 Figure 13. An example of the SAInt interface showing: the Model Explorer with the main objects making up the Barry Island network (see numbers in brackets for the count of such objects), the Map Window with the schematic of the Barry Island thermal system, and the event table (on the right) with the list of events for the heat demand externals. The steady state thermal scenario is solved. 91 Figure 14. Example of the SAInt interface showing: the Model Explorer with the main objects making up the thermal model for the case study of Sonnenplatz (see numbers in brackets for the count of such objects), and the Map Window with the simplified thermal network and the solution for the supply point and two demand points of the steady state scenario. Nodes are described using the mass flow of the fluid, while pipelines are coloured based on the heat loss on the hot side of the network. The Property Editor shows some details of the heat demand HD_01. The example is based on a virtual scenario using fictional data, and it is used as a proof of concept. .................................................... 95 Figure 15. Example of a stochastic profile used to define the hourly dynamic of a demand point in the model of the Sonnenplatz network. On the right the numerical region used to generate the profile, with median value and standard deviation for the chosen probability distribution (i.e., uniform). The example is based on a virtual scenario using fictional data, and it is used as a proof of concept. ..... 96 Figure 16. Examples of the results for the supplied heat (in kW) and the mass flow (in kg/s) of the supply point in the dynamic scenario for the model of the Sonnenplatz network for the reference day of 14-02-2023. As expected, they have the same shape, but different units for the y-axis. The example is based on a virtual scenario using fictional data, and it is used as a proof of concept. ................... 96 Figure 17. Example of the SAInt interface showing the mass flow at node level and heat loss on the hot side at pipeline level for the simulated day of 14-02-2023 for the thermal model for the case study of Sonnenplatz. The chart shows the thermal and hydraulic view for the demand in the southern part of the model (i.e., see the selected label). The example is based on a virtual scenario using fictional data, and it is used as a proof of concept. .......................................................................................... 97 Figure 18. Stage one of the quasi-dynamic co-simulation of the thermal-electric system for the EnviPark complex (simulation time 12:00 a.m. of 01.02.2020). The picture shows the electric grid, and the active power extracted from the external transmission line at the node “CENTRALE_TERMICA_MW” along with the electric demand at the coupling point “A2_Uffici (electric)” (electric side) / “A2_UFFICI” (thermal side). The arrow in the centre indicates the electric line on which the new extra thermal load will be activated. In this step, the electric system is operated in isolation, and the equivalent thermal load is assumed to be zero. ................................................ 99 Figure 19 Stage two of the quasi-dynamic co-simulation of the thermal-electric network for the EnviPark complex (simulation time 12:00 a.m. of 01.02.2020). The picture shows the thermal grid and
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 9 the heat extracted from the external district heating system at the node “CENTRALE_TERMICA” along with the heat demand at the coupling point “A2_Uffici (electric)” (electric side) / “A2_UFFICI” (thermal side). In this step, the thermal system is operated in isolation, and the thermal load of the heat pump is assumed to be provided by the external district heating system. .............................. 101 Figure 20. Stage three of the quasi-dynamic co-simulation of the thermal-electric network for the EnviPark complex (simulation time 12:00 a.m. of 01.02.2020). The picture shows the active power on the electric side (purple-red colour legend for electric lines) and the total thermal power and the mass flow on the thermal side (yellow-green colour legend for thermal pipelines) at the coupling point “A2_Uffici (electric)” (electric side) / “A2_UFFICI” (thermal side). The thermal load from stage two is used as electric demand and removed from the thermal load. The electric and thermal networks are updated and operated at the same time. The arrow in the centre indicates the electric line with the new extra thermal load with low voltage per unit values. The background map is changed to Bings Map, “canvas grey” to facilitate the reader. ..................................................................................... 102 Figure 21. Change in the total active power extracted from the node where the coupling point “A2_Uffici (electric)” (electric side) / “A2_UFFICI” (thermal side) is off (A, power demand of the external) and on (C, power demand of the node). The active power demand from the newly converted heat load is shown in B. The example is based on a virtual scenario using fictional data and is used as a proof of concept. ............................................................................................................................ 103
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 16 3 General Structure of SAInt As a direct consequence of the environmental and climatic impacts of fossil-based energy usage, the energy policies and objectives defined by the European Union are targeting greater penetration and usage of renewable energy sources (RES) (Directorate-General for Energy, European Commission, 2019). High utilisation of RES has multiple advantages: (1) the potential to reduce greenhouse gas emissions, (2) increase the share of locally produced renewable electricity, (3) making users less dependent on the grid favouring energy security and reducing energy costs, (4) transform the individual user from consumers into prosumers, or (5) increase efficiency (Owusu & AsumaduSarkodie, 2016). However, certain types of renewable energy sources come with risks. Electricity production from RES is subject to intermittency, and its availability can fluctuate within a day and throughout different seasons. To cope with certain RES shortcomings, it is possible to adopt specific strategies like diversification of sources (Wałachowska & Ignasiak-Szulc, 2021) and sector coupling. Diversifying the portfolio of sources of renewable energy allows for compensating for possible seasonal unavailability and changes in amounts and strengthens resilience by enhancing redundancy in supply paths. Sector coupling, on the other hand, is the concept of integrating multiple energy networks into one energy system (Lund, Østergaard, Connolly, & Mathiesen, 2017). This strategy enables higher local efficiencies and utilisation of domestic renewable energy, promoting decarbonisation, and introducing flexibility in meeting the energy demand (Jasmine Ramsebner, 2021). Over the last decade, the coupling of power, heat, and gas sectors has been recognised as a pivotal enabler of a more sustainable energy system. Research and experimentation have tested and assessed different enabling technologies allowing for a solid understanding of strengths and weaknesses at the component level. But what is still missing is an understanding of effects and interactions at the energy system level, both at coupling points in multi-energy systems or even more so in hybrid energy networks (Ramsebner, et al., 2021). As clearly addressed in their comparative review of software tools, Widl et al. (2022) point to the lack of tools for the assessment of multiand hybrid energy networks. The Authors mark how the research, or the industrial audience, can choose from a variety of well-established tools for system design, optimisation, and operation for all relevant domains (heat, power, gas, etc.). Those tools are widely adopted in the energy industry and have a high standard of quality to meet the designing and management needs of a single domain only. Widl et al. (2022) also indicate that the established tools (at the time of the review) for modelling multi-energy systems have important limitations, like not being able to address certain specific network-level properties (e.g., network capacity or congestion). The Authors also recognize the effort that, in recent years, the research community or the industrial sector has been putting into developing new tools and methods for the assessment of multiand hybrid energy systems. In their paper Widl et al. (2022)) review fourteen different software tools available to the public under different types of commercial and open-source licenses. The list was the result of a screening phase based on an online survey and literature review, followed by a selection
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 17 procedure to achieve a consolidated shortlist. The selected tools were classified and discussed based on a set of criteria covering: the spatial resolution of component models, the temporal resolution of component models, the targeted scale of the system model, the targeted time horizon of the system model, the application class, the types of network models, and the use of energy storage objects. One of the reviewed software was the “Scenario Analysis Interface for Energy Systems” tool (SAInt) (release 3.0 by the beginning of the year 2022). In another review, Lohmeier et al. (2020) provide an analysis of the available approaches and the needed requirements for software platforms focusing on coupled energy infrastructure (Table 1). They review grid simulation tools, energy system modelling and optimization tools, and multi-energy grid simulation tools. In their paper, the Authors stress how the software landscape has evolved in the last ten years by primarily adding new open-source tools. These tools are of special interest to the research community because they can be customised and automatised, and mostly, they are free of charge. On the other hand, commercial tools usually focus on user interface and usability, and they provide customer support, references, and training material to reduce the steepness of the learning curve. Tool CRITERIA Type OS Power Gas DH Detailed Grid Model Coupled simulation Other features SINCAL GS ✓ ✓ ✓ ✓ GUI, OPF, (TOP) *** STATNET GS ✓ ✓ ✓ ✓ GUI, TC (DH), (TOP) *** TRNSYS GS ✓ ✓ GUI, TC (DH), CTRL MATPOWER GS ✓ ✓ ✓ OPF, (TOP) ***, LIB PyPSA GS ✓ ✓ (✓)** (✓)** ✓ OPF, (TOP) ***, LIB pandapower GS ✓ ✓ ✓ OPF, CTRL, TOP, LIB pandapipes GS ✓ ✓ ✓ ✓ CTRL, TOP, LIB OSeMOSYS ESMO ✓ ✓ ✓ ✓ ✓ Balmorel ESMO (✓)* ✓ ✓ ✓ calliope ESMO ✓ ✓ ✓ ✓ ✓ LIB Switch ESMO ✓ ✓ ✓ LIB oemof ESMO ✓ ✓ ✓ ✓ ✓ TOP, LIB SAInt MEGS ✓ ✓ ✓ ✓ ✓ GUI, OPF, TC (G) HyFlow MEGS ✓ ✓ ✓ (✓)** ✓ MYNTS MEGS ✓ ✓ ✓ ✓ GUI, TC (all), CTRL TransiEnt MEGS (✓)* ✓ ✓ ✓ ✓ ✓ TC (all), CTRL Pandapipes multi-energy MEGS ✓ ✓ ✓ ✓ ✓ ✓ OPF, CTRL, LIB DH District Heating, * Only usable with proprietary software. ** Simplified model. *** Only connected components. OS, open source; GS, grid simulation tool; ESMO, energy system modelling and optimization tool; MEGS, multi-energy grid simulation tool; GUI, graphical user interface; OPF, optimal power flow (for power grid); TC, transient calculation; DH, district heating grid; G, gas grid; CTRL, evaluation of control strategies; TOP, analysis of grid topology; LIB, external libraries for evaluation usable (e.g., Python and MATLAB). Table 1. Updated table of power, gas and district heating simulation tools as reviewed in Lohmeier et al. (2020).
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 18 When it comes to grid simulation tools, Lohmeier et al (2020) note that they offer detailed grid models, sometimes even for different infrastructures. What these tools lack is the possibility of coupling different systems within the same simulation. Energy system modelling and optimization tools are mainly software used to analyse power flows between defined areas with a strong focus on energy balancing. Such tools can precisely model power plants and devices with their control strategies and characteristics (e.g., efficiency or ramp rates), but they do not provide detailed grid models, and in doing so they can easily integrate all infrastructures within one simulation. These options can be used for optimal power system design or power plant deployment planning, but they do not offer sophisticated models for integrated infrastructures, as either the grid model is simplified, or a coupled simulation is not possible. When it comes to multi-energy grid simulation tools, Lohmeier et al. (2020) show how two approaches are prominent: (1) combining dedicated tools with the help of a co-simulation platform and (2) integrating all models in one tool (i.e., combined simulation). The main advantage of a cosimulation approach is the possibility of integrating any tool, while leaving the development to the respective experts (Widl, et al., 2020). A co-simulation approach is open to distributed simulations and may reduce the need to exchange sensitive data. However, co-simulations have problems like data exchange between platforms, which could be very challenging and time-consuming and act as a bottleneck for complex simulations resolved in space and time. Moreover, the design, functionalities, and licensing of coupled tools might introduce difficulties for the user in setting up a model. And most co-simulation approaches are tailor-made. Many of these issues are addressed and solved by applying a combined simulation approach. Wild et al. (2015) point to the fact that in multi-energy grid simulations, the main challenge lies in the complexity of the addressed problems. The Authors underline that any tool designed to solve a multitude of different problems in this field must focus on tackling the complexity of the problem and must provide a good «user experience» which might greatly affect the tool's success. Lohmeier et al. (2020) identify three main criteria to assess the quality of a combined simulation tool: 1. data structure: a clear data structure able to capture large amounts of data and balance simplicity with rigour. 2. adaptable model setup: construction and adaptation of a full simulation model should be simple and efficient. This requires pre-defined, but adaptable models for grid components and sector coupling facilities with their physical properties and respective control strategies. The presence of extensive component libraries is an important part of the tools. 3. performance: from the user’s point of view, spending a lot of time waiting for calculations to finish can be very inconvenient and inefficient. The user is interested in evaluating many different setups and use cases, which prompts reasonable computing times. Model efficiency and simulation speed are of main concern in many tools. SAInt is a software platform designed to model integrated and multi-energy networks and markets. Thanks to the activities carried out in the HYPERGRYD project, the company behind SAInt, encoord GmbH, has been able to further extend its modelling capabilities to cover not only energy markets,
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 19 electricity networks, gas networks, coupled electric and gas networks, but also thermal networks and combined electric-thermal systems, and improve electric ACPF simulations. SAInt has been developed with a clear strategy in mind to address and solve the majority of the concerns raised by the reviews quoted in the previous paragraphs. This report provides a general overview of the capabilities of the software and focuses on the contribution to the HYPERGRYD project of the release 3.5 of SAInt. Key features of SAInt are: • detailed modelling of single energy carrier for electric, gas, and thermal transmission and distribution systems; • steady state and dynamic simulation for hydraulic systems; • steady state and quasi-dynamic AC power flow simulations of electric networks; • steady state and quasi-dynamic simulations of thermal networks; • unit-commitment and production cost optimization of electric networks (DCUCOPF); • combined simulation of electric-gas systems; • co-simulation of electric markets and hydraulic systems; • co-simulation of steady-state and quasi-dynamic electric-thermal systems; • user-friendly graphical user interface; • flexible API for integration in Python software or other software via C#, C++, or VB; • detailed documentation; • extensive customer support. 3.1 Product Overview SAInt is the first commercial software application that enables the simulation of electricity, gas, and thermal networks in a single integrated simulation environment and graphical user interface. SAInt was developed in MS Visual Studio using the fully object-oriented programming languages VB.NET and C#. The software also uses IronPython as a scripting language to communicate with the user through Python expressions. SAInt is specifically designed to analyse the operation and interdependency of interconnected electricity, gas, and thermal networks. SAInt can be used as a standalone power system simulator, gas system simulator, and thermal simulator. In addition, SAInt can be used as a combined multi-time period power system and gas simulator. What distinguishes SAInt from other existing tools on the market is its ability to model, simulate, and analyse different energy vectors in a single integrated user interface and simulation environment. Therefore, it avoids time-consuming and error-prone iterative data exchanges between any two structurally separated electricity, gas, or thermal system solvers.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 20 3.2 Product Architecture and User Interfaces SAInt‘s architecture is divided into four layers, the interface, core, and data layer, as shown in Figure 1. The interface layer is the main access point for the user to interact with the software and comprises three assemblies: 1. Graphical User Interface (GUI), which is a Windows Forms desktop application that enables the user to interact with the software via mouse and keyboard input. 2. Application Programming Interface (API), which is a dynamic link library that exposes a collection of callable functions to external applications and programming languages such as Python, C#/C++ or Matlab. 3. Command Line Interface (CLI), which is a console application that allows the user to interact with the software via command line input. 4. Feed Manager: a dynamic link library that handles the import and export of data into and from SAInt native format and other formats like Microsoft Excel ™, comma-separated values, and ASCII text format. The four assemblies in the interface layer communicate directly with the main library of the software (SAInt-Core.dll) which constitutes the core layer. The core layer contains the object model, business logic, and the implementation of the mathematical algorithms. The object model includes the abstraction of the different network types (electricity, gas, and thermal) and their components (electric lines, generators, storage, etc.) in terms of properties, actions, and functions. Figure 1. Software architecture of SAInt and CodeMeter for license management.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 21 The data layer communicates directly with the core layer and contains the model data and data format. An energy system model in SAInt requires two types of native input files, the network and scenario files. These files are saved as eXtensible Markup Language (XML) files. The network file is used to build the energy system framework by defining the network topology, reference properties, and assets of the network (line impedances, compression ratio for a unit, thermal pipeline length, etc.). The scenario file is used to create a case study that defines the mathematical algorithm used for the analysis and contains any dynamic input data (load and generation profiles, control set points, fuel price, gas storage inventory, etc.). The user can create any number of scenarios for a single network. The results of a scenario run are saved in a solution file, which is a SQLite database. SAInt uses the third-party solution CodeMeter by Wibu-Systems AG (www.wibu.com) for its software protection and license management (SPLM). The SPLM is an integral part of SAInt and is installed together with the SAInt assemblies during the software installation process. The user can use the SPLM interface to create license requests, update existing licenses, and view available license containers and license entries. 3.2.1 SAInt GUI SAInt’s GUI contains three main controls: ribbon bar, dock panel, and status bar. The GUI has many windows that serve different purposes and can be rearranged based on the preferences of the user. Windows in the GUI include (Figure 2): • Project explorer: The project explorer gives an overview of the model files available in the project directory. The file types include network, scenario, state, solution, profile, label, vertex, log, and script. • Model explorer: The model explorer shows the hierarchical overview of the different objects in the network model grouped by different object types (e.g., subs, zones, groups, nodes, branches, externals). • Property editor: The property editor allows the user to edit the properties of the network, scenario, and their child objects. The property editor filters the list of properties depending on the loaded scenario type. • Map window: The map window shows a topological representation of the network, visualizes differences across a network (e.g., properties), and shows animations of solutions obtained from executing a scenario. If data have a geographic attribute (i.e., a valid coordinate reference systems) the model is displayed using a service map service – like OpenStreetMaps – as base image. • Workspace: The workspace lists the predefined and user-defined functions and variables accessible from the command window and script editor of the GUI. The list includes the name, syntax, and the description of the functions.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 22 Figure 2. Main elements of the dock panel of SAInt GUI. Numbers indicate: (1) the project explorer, (2) the model explorer, (3) the map window, (4) the script editor, (5) the property editor, (6) the workspace, (7) the command window, (8) log window, and (9) the chart window. Number (10) indicates the entry View in the ribbon bar from where the user can control the previous windows. • Chart window: The chart window displays plots for one or multiple properties of network objects. The plots can either be derived from the results of a simulation or input parameters. • Command window: The command window is a control that uses pre-defined functions in an IronPython environment to perform various tasks such as mark objects, create plots, tables, evaluate properties. It uses the IntelliSense feature to guide the user while entering the commands. • Script editor: The script editor allows the user to create and save customized codes using IronPython functionalities. Like the command window, it uses the IntelliSense feature to guide the user while entering the commands. • Log window: The log window is the primary source of information for the GUI operations. It displays the log for network and scenario operations including the scenario execution logs. 3.2.2 SAInt API SAInt-API is a powerful tool to automate the manual processes in the GUI. It gives access to multiple network and scenario data processing and execution functions. The API can be used with Python, Matlab, C++, and other programming languages. The API offers more than 100 callable functions to
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 23 import, open, save, and export network, scenario and solution files. It offers the possibility to serialize or parallelize the execution of multiple scenarios. The API has been extended to incorporate calls and functions covering thermal modelling in SAInt as a direct result of the HYPERGRYD project. Table 2 provides an overview of the new entry points to SAInt API to expose the new modelling capabilities concerning thermal simulations. The API has also been improved to incorporate changes for the ACPF simulation capabilities in SAInt in light of better co-simulation with thermal systems and general improvements to the objects’ description. Table 3 provides an overview of the entry points to SAInt API to expose the ACPF modelling capabilities concerning electric simulations. Object Type API Calls Description network openTNET(string TNETFile) Open thermal network model and load it into memory. importTNET(string ImportFile) Import thermal network model from a network import file and load it into memory. exportTNET(string ImportFile) Export thermal network to network import file. includeTNET(string TNETFile) Include thermal network model from a network file to loaded thermal network model. paraimportTNET(string ImportFile) Import parameter import file and apply it to loaded thermal network model. includeTNET(string MainTNETFile, string TNETFileToAdd, string targetTNETFile, bool PreserveContainers, bool LoadAfter) Include a thermal network model from a network file to another thermal network model from network file and save the joined network to the target file. Each network must be in a different directory. includeInLoadedTNET(string TNETFileToAdd, string targetNetFile, bool PreserveContainers, bool LoadAfter) Include thermal network model from a network file to loaded thermal network model and save the joined network to the target file. Each network must be in a different directory. convertCRSTNET(string targetFileName, string sourceEPSG_ID, string targetEPSG_ID, bool transferWholeNet) Convert the coordinates and, optionally, make a copy of the network from a source to a target reference coordinate reference system. exportTNETByEPSGID(string ImportFile, string EPSG_ID) Export a thermal network to network import file with a new CRS indicated by an EPSG code. scenario newTSCE(string ScenarioNameStr, string ScenarioTypeStr, string StartTimeStr, string EndTimeStr, int TimeStep) Create new thermal scenario for loaded thermal network model. openTSCE(string TSCEFile) Open thermal scenario for loaded thermal network model. importTSCE(string FileName) Import scenario events from import file to loaded thermal scenario. exportTSCE(string FileName) Export thermal scenario events to scenario event import file. includeTSCE(string FileName, string StartTimeStr, string EndTimeStr) Include thermal scenario to loaded network model and scenario. scenario profiles importTPRF(string FileName) Import profile import file to loaded thermal scenario. exportTPRF(string FileName) Export profiles from current thermal scenario to export file. includeTPRF(string FileName) Include profiles from profile file to current thermal scenario. scenario execution runTSIM() Run thermal scenario for loaded thermal network, scenario and condition file.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 24 Table 2. Overview of the API calls for thermal simulations and thermal networks added to cover the new thermal modelling capabilities in SAInt. Object Type API Calls Description runTSIMCustomDLL(string AssemblyPath, string NamespaceName, string ClassName) Run thermal scenario for loaded thermal network, scenario and condition file using custom dll file. scenario solutions openTSOL(string SOLFile) Open thermal solution file for loaded thermal network model. writeTSOL(string SOLInputFile, string SOLOutputFile) Write thermal scenario results to file using result description file. openTCON(string CONFile) Open state/condition file to loaded thermal network model. writeTCON(bool writefile) Switch between writing and not writing thermal network state file after simulation. exportTCON(string Filename, string TimeStr) Export thermal network state at the specified simulation time to a state file. Object Type API Calls Description network openENET(string ENETFile) Open an electric network model and load it into memory. importENET(string ImportFile) Import an electric network model from a network import file and load it into memory. exportENET(string ImportFile) Export an electric network to network import file. paraimportENET(string ImportFile) Import a parameter import file and apply it to a loaded electric network model. paraexportENET(string ExportFile) Export an input parameter for an electric network model. importWTPC(string ImportFile) Import a wind turbine power curve to a loaded electric network. includeWTPC(string WTPCFile) Include a wind turbine power curve to a loaded electric network. exportWTPC(string ExportFile) Export a wind turbine power curve from a loaded electric network to an import or include file. importFCC(string ImportFile) Import a fuel consumption curve to a loaded electric network. includeFCC(string FCCFile) Include a fuel consumption curve to a loaded electric network. exportFCC(string ExportFile) Export a fuel consumption curve from a loaded electric network to an import or include file. includeENET(string MainENETFile, string ENETFileToAdd, string targetENETFile, bool PreserveContainers, bool LoadAfter) Include an electric network model from a network file to another electric network model from network file and save the joined network to the target file. Each network must be in a different directory. includeInLoadedENET(string ENETFileToAdd, string targetNetFile, bool PreserveContainers, bool LoadAfter) Include an electric network model from a network file to loaded electric network model and save the joined network to the target file. Each network must be in a different directory. convertCRSENET(string targetFileName, string sourceEPSG_ID, string targetEPSG_ID, bool transferWholeNet) Convert the coordinates and, optionally, make a copy of the network from a source to a target reference coordinate reference system. exportENETByEPSGID(string ImportFile, string EPSG_ID) Export an electric network to network import file with a new CRS indicated by an EPSG code. scenario newESCE(string ScenarioNameStr, string ScenarioTypeStr, string StartTimeStr, string EndTimeStr, int TimeStep) Create new electric scenario for loaded electric network model. openESCE(string ESCEFile) • Open electric scenario for loaded electric network model. importESCE(string FileName) Import scenario events from import file to loaded electric scenario.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 25 Table 3. Overview of the API calls for electric simulations and electric networks in the ACPF modelling capabilities in SAInt. Object Type API Calls Description exportESCE(string FileName) Export electric scenario events to scenario event import file. includeESCE(string FileName, string StartTimeStr, string EndTimeStr) Include electric scenario to loaded network model and scenario. scenario profiles importEPRF(string FileName) Import profile import file to loaded electric scenario. exportEPRF(string FileName) Export profiles from current electric scenario to export file. includeEPRF(string FileName) Include profiles from profile file to current electric scenario. scenario execution runESIM() Run electric scenario for loaded electric network, scenario and condition file. runESIMCustomDLL(string AssemblyPath, string NamespaceName, string ClassName) Run electric scenario for loaded electric network, scenario and condition file using custom dll file. scenario solutions openESOL(string SOLFile) Open electric solution file for loaded electric network model. writeESOL(string SOLInputFile, string SOLOutputFile) Write electric scenario results to file using result description file. openECON(string CONFile) Open state/condition file to loaded electric network model. writeECON(bool writefile) Switch between writing and not writing thermal network state file after simulation. exportECON(string Filename, string TimeStr) Export electric network state at the specified simulation time to a state file.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 32 Object Extension Description Result Type PXGEN Total active power generation from all generic generators in the network, sub, zone or group. Calculated as the sum of all active power (P) derived PHGEN Total active power generation from all hydro generators in the network, sub, zone or group. Calculated as the sum of all active power (P) derived PIN Total active power injection to the network, sub, zone or group by all externals. It also includes storages and hydros when discharging derived PL Total active power loss of all branches in the network, sub, zone or group. In DCUCOPF losses are considered if INCLUDELOSSES (network) event is applied derived PLSTR Total active power losses from all storages objects in the network, sub, zone or group. Calculated as the sum of all storages losses (PL) derived PNS Difference between scheduled and delivered active power for all generators in the network, sub, zone or group. Calculated as the sum of PSET minus P derived PPHSTR Total active power generation from all pumped hydro storages in the network, sub, zone or group. Calculated as the sum of all active power (P) derived PSHT Total Active Power Demand by connected Shunts derived PPV Total active power generation of all solar generators in the network, sub, zone or group. Calculated as the sum of all active power (P) derived PSTR Total active power charge(-)/discharge(+) from all electric storages in the network, sub, zone or group. Calculated as the difference between charging (P with negative sign) and discharging (P with positive sign) derived PWIND Total active power generation by wind generators in the network, sub, zone or group. Calculated as the sum of all active power (P) derived PNSDEM Difference between scheduled and delivered active power for all electric demands in the network, sub, zone or group. Calculated as the sum of PSET minus P derived PNSFGEN Difference between scheduled and delivered active power for all fuel generators in the network, sub, zone or group. Calculated as the sum of PSET minus P derived PNSXGEN Difference between scheduled and delivered active power for all generic generators in the network, sub, zone or group. Calculated as the sum of PSET minus P derived PNSHGEN Difference between scheduled and delivered active power for all hydro generators in the network, sub, zone or group. Calculated as the sum of PSET minus P derived PNSPV Difference between scheduled and delivered active power for all solar generators in the network, sub, zone or group. Calculated as the sum of PSET minus P derived PNSWIND Difference between scheduled and delivered active power for all wind generators in the network, sub, zone or group. Calculated as the sum of PSET minus P derived QLC Total line charging derived QFB Reactive power flow balance derived QD Total reactive power demand derived QFGEN Total active power generation from fuel generators derived QG Total reactive power generation derived QHGEN Total active power generation from hydro generators derived QL Total reactive power loss derived QSHT Total Reactive Power Supply by connected Shunts derived QVRG Total active power generation from variable renewable generators derived STRINV Total storage inventory of all storages in the network, sub, zone or group. Calculated as the multiplication between state of charge (SOC) and maximum storages capacities (MaxCap) derived node VA Voltage Angle base VPU Voltage magnitude per unit base
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 33 Object Extension Description Result Type P Total active power supply minus demands from externals. Demand is the sum of demand, storage and hydro when charging. Calculated as (PIN) minus (POUT) derived PD Total active power extraction from the node by all electric demands objects derived POUT Total active power extraction from the node by all externals (demands, storages and hydro when charging) derived PFGEN Total active power generation from all fuel generators connected to the node. Calculated as the sum of all active power (P) derived PG Total active power generation from all generators objects connected to the node. Calculated as the sum of all active power (P) derived PXGEN Total active power generation from all generic generators connected to the node. Calculated as the sum of all active power (P) derived PHGEN Total active power generation from all hydro generators connected to the node. Calculated as the sum of all active power (P) derived PIN Total active power injection from the node by all externals including storages and hydro when discharging derived PSHT Total active power absorption(-)/injection(+) from all shunts connected to the node. Calculated as the difference between absorption (P with negative sign) and injection (P with positive sign) derived PLSTR Total active power losses from all storages connected to the node. Calculated as the sum of all storages losses (PL) derived PNS Difference between scheduled and delivered active power for all externals connected to the node. Calculated as the sum of PSET minus P derived PEPS Total active power generation/demand from all electric prosumers connected to the node. Calculated as the sum of all active power (P) derived PPHSTR Total active power generation/demand from all pumped hydro generators connected to the node. Calculated as the sum of all active power (P) derived PPV Total active power generation by solar generators connected to the node. Calculated as the sum of all active power (P) derived PSTR Total active power charge(-)/discharge(+) from all storages connected to the node. Calculated as the difference between charging (P with negative sign) and discharging (P with positive sign) derived PWIND Total active power generation by wind generators connected to the node. Calculated as the sum of all active power (P) derived PNSDEM Difference between scheduled and delivered active power for all demands connected to the node. Calculated as the sum of PSET minus P derived PNSFGEN Difference between scheduled and delivered active power for all fuel generators connected to the node. Calculated as the sum of PSET minus P derived PNSXGEN Difference between scheduled and delivered active power for all generic generators connected to the node. Calculated as the sum of PSET minus P derived PNSHGEN Difference between scheduled and delivered active power for all hydro generators connected to the node. Calculated as the sum of PSET minus P derived PNSPV Difference between scheduled and delivered active power for all solar generators connected to the node. Calculated as the sum of PSET minus P derived PNSWIND Difference between scheduled and delivered active power for all wind generators connected to the node. Calculated as the sum of PSET minus P derived QSHT Reactive power injection from shunts (-) absorption / (+) injection derived SOC State of charge for the in service storage(s) calculated as the weighted energy average stored (in %) of the storages connected to the node derived STRINV Total storage inventory of all storages connected to the node. Calculated as the multiplication between state of charge (SOC) and maximum storages capacities (MaxCap) derived S Magnitude of the net apparent power at the node derived Q Total reactive power supply minus demand from externals derived
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 34 Object Extension Description Result Type QD Reactive Power Demand derived QG Total reactive power supply from externals derived VM Voltage Magnitude (for UACPF, the average of line-to-line voltage magnitudes of available phases at the node) derived Branch (electric line) State Current operating state of object. Permitted states are ON and OFF. When referred to a node, all externals connected to the node inherit the state base PF Total active power flow (+) leaving / (-) entering the FromNode derived LLP Active power loading calculated as a ratio between active power (P) and maximum active power (PMAX). PMAX = PMAXDEF if no PMAX event defined (for unbalanced system, it returns the maximum loading among the three phases) derived PL Total active power loss in the branch derived PT Total active power flow (+) leaving / (-) entering the ToNode derived SF Total apparent power passing through the branch, next to "from" node, of all the phases of parallel branches derived LLS Apparent power loading given as ratio between apparent power and maximum apparent power (for unbalanced system, it returns the maximum loading among the three phases) derived ST Total apparent power passing through the branch, next to "to" node, of all the phases of parallel branches derived QLCF Charging reactive power FromNode side derived QLCT Charging reactive power ToNode side derived I Magnitude of the current in the middle part of PI-model directed from the FromNode to ToNode derived IA Phase angle of the current in the middle part of PI-model directed from FromNode to ToNode derived IAF Phase angle of current flowing into FromNode derived IAT Phase angle of current flowing into ToNode derived LLI Current loading given as ratio between current and maximum current (for unbalanced system, it returns the maximum loading among the three phases) derived IF Magnitude of the current flowing into the branch from the FromNode assuming a balanced three-phase system derived IT Magnitude of the current flowing into the branch from the ToNode assuming a balanced three-phase system derived IPU Magnitude of the current in the middle part of PI-model in network per unit directed from FromNode to ToNode derived QF Total reactive power flow (+) leaving / (-) entering the FromNode derived QL Total reactive power consumption in the series part derived QT Total reactive power flow (+) leaving / (-) entering the ToNode derived QLC Total charging reactive power flowing through the shunt part derived VAD Voltage angle difference calculated as the difference between "ToNode" and "FromNode" voltage angles (VA) derived VAF Voltage angle at FromNode derived VAT Voltage angle at ToNode derived VMD Magnitude of the voltage difference between ToNode and FromNode derived VMF Voltage magnitude at FromNode (for UACPF, the average line-to-line voltage at the FromNode is taken) derived VMR Voltage magnitude ratio, ratio between ToNode and FromNode voltage magnitudes (for UACPF, the ratio between the average line-to-line voltages at the two sides is taken) derived VMT Voltage magnitude ToNode (for UACPF, the average line-to-line voltage at the ToNode is taken) derived P Total active power base
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 35 Table 5. List of the basic and derived results SAInt can model in electric networks and for electric objects in ACPF simulations for some selected objects. The extension is the actual name used in SAInt. The list does not cover all objects but showcases some examples. Object Extension Description Result Type electric demand State Current operating state of object. Permitted states are ON and OFF. When referred to a node, all externals connected to the node inherit the state base Q Total reactive power base PNS Difference between scheduled and delivered active power. Calculated as the sum of PSET minus P derived VMAX Maximum Voltage Magnitude in network per-unit derived VMIN Minimum Voltage Magnitude in network per-unit derived VA Voltage Angle derived VM Voltage Magnitude (for UACPF, the average of line-to-line voltage magnitudes of available phases at the node) derived VPU Voltage magnitude per unit derived electric supply (e.g., generic generator ) P Total active power base State Current operating state of object. Permitted states are ON and OFF. When referred to a node, all externals connected to the node inherit the state base Q Total reactive power base PNS Difference between scheduled and delivered active power. Calculated as the sum of PSET minus P derived VMAX Maximum Voltage Magnitude in network per-unit derived VMIN Minimum Voltage Magnitude in network per-unit derived RampRate Active power ramp rate. Change in active power per time between two consecutive time steps derived VA Voltage Angle derived VM Voltage Magnitude (for UACPF, the average of line-to-line voltage magnitudes of available phases at the node) derived VPU Voltage magnitude per unit derived P Total active power base State Current operating state of object. Permitted states are ON and OFF. When referred to a node, all externals connected to the node inherit the state base electric supply (e.g., solar generator ) Q Total reactive power base PNS Difference between scheduled and delivered active power. Calculated as the sum of PSET minus P derived VMAX Maximum Voltage Magnitude in network per-unit derived VMIN Minimum Voltage Magnitude in network per-unit derived RampRate Active power ramp rate. Change in active power per time between two consecutive time steps derived VA Voltage Angle derived VM Voltage Magnitude (for UACPF, the average of line-to-line voltage magnitudes of available phases at the node) derived VPU Voltage magnitude per unit derived
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 36 5 Scenarios in SAInt A scenario is a case study performed on a network. A scenario consists of a set of events, constraints, and conditions to be accommodated by the network. Time dependency is incorporated in a scenario by using profiles for events or by specifying the time an event must occur. Every scenario has a startand end-time, and a time step defining its time granularity. A scenario can either be a simulation or an optimization case, depending on the type of problem the network is used to address. SAInt addresses electric network optimisation problems by solving a DCUCOPF scenario. All other cases for electric, thermal or gas systems are physical simulations. In case of an optimisation problem, lookahead time and lookahead time-step are also needed. In SAInt a network can be linked to an infinite number of scenarios. Scenarios are saved with the extension *.gsce, *.esce or *.tsce for gas, electricity or thermal cases, respectively. 5.1 Overview of Available Scenario Types SAInt offers a variety of scenario types to address physical simulations of energy networks or optimise energy markets. In the case of electric networks, SAInt offers ( 1 ): • Steady AC-Power Flow: Steady (single-time step) alternating current power flow. Simulation of power flows in an electric network using AC power flow equations with a distributed slack bus model. • Steady AC-Optimal Power Flow: Steady (single time step) alternating current optimal power flow. Optimization of electricity generation dispatch in an electric network considering generator and transmission constraints using AC power flow equations. • Steady Unbalanced AC-Power Flow: Steady (single-time step) alternating current power flow for unbalanced single or multi-phase networks. Simulation of power flows in an unbalanced single or multi-phase electric network using AC power flow equations. • Quasi Dynamic AC-Power Flow: Quasi-dynamic alternating current power flow. A succession of independent (steady AC-power flow) simulations of power flows in an electric network using AC power flow equations. • Quasi Dynamic AC-Optimal Power Flow: Quasi-dynamic alternating current optimal power flow. A succession of (steady AC-optimal power flow) optimizations of electricity generation dispatch in an electric network considering generator and transmission constraints using AC power flow equations. 1 Compared to release 3.4, SAInt 3.5 has removed the steady and quasi-dynamic DC-power flow and steady and quasi-dynamic DC-optimal power flow simulation capabilities. The final version of this report has been updated to reflect this change.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 37 • Quasi Dynamic Unbalanced AC-Power Flow: Quasi-dynamic alternating current power flow for unbalanced single or multi-phase networks. A succession of (in)dependent (steady state AC-power flow) simulations of power flows in an unbalanced single or multi-phase electric network using AC power flow equations. • Direct current unit commitment optimal power flow scenario (DCUCOPF): Multi-time step mixed integer optimization problem that optimizes the decisions on unit commitment and economic dispatch considering generator, storage, and transmission constraints using a DCapproximation of the AC power flow equations. Each optimization time horizon can have a look-ahead period to inform decisions that influence the network's state beyond the optimization window's end. In the case of gas networks, SAInt offers: • Steady Gas: Steady (single-time step) hydraulic gas network simulation. • Dynamic Gas: Transient hydraulic gas network simulation. Simulates the operation of a gas network under time-varying demand profiles, control settings, and set points. In the case of thermal networks, SAInt offers: • Steady Thermal: Steady (single-time step) thermal-hydraulic simulation of district heating networks. • Quasi Dynamic Thermal: A succession of independent (steady thermal-hydraulic) simulations of district heating networks. There are two combined scenarios in SAInt: steady and quasi-dynamic. The combined scenarios are between the electric and gas networks. The electric scenarios differentiate between power flow and optimal power flow. • Steady Gas and Steady AC-Power Flow: Steady (single-time step) combined simulation of alternating current power flow and a steady hydraulic gas network simulation. • Dynamic Gas and Quasi Dynamic AC-Power Flow: Combined simulation of a succession of (steady AC-power flow) simulations of power flow in an electric network using AC power flow equations and a transient hydraulic gas network simulation under time-varying demand profiles, control settings, and set points. SAInt allows for any meaningful combination of scenarios of single energy carrier networks to carry out co-simulations. In the case of the HYPERGRYD project what is most relevant is the co-simulation of thermal networks with electric AC systems. An extension of such capability is the possibility of adding gas networks as well. For any steady state scenario, SAInt allows to specify the following set of scenario’s properties: • “StartTime”: Start time of the scenario. The default is to set the calendar day and hour of when the scenario is created. The property is not relevant to the solution of a steady state simulation.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 38 • “EndTime”: End time of the scenario. The default is to set the calendar day and one hour plus of when the scenario is created. The property is not relevant to the solution of a steady state simulation. • “TimeWindow”: Total simulation time window. It is set to a fixed one-hour duration. The property is not relevant to the solution of a steady state simulation. • “TimeStep”: Time step for the scenario. The property is fixed to 60 minutes, and it is not relevant for the solution of a steady state simulation. Furthermore, SAInt allows to specify some settings for the solver to control the residual tolerances and the maximum number of iterations admitted during the numerical solution. The properties of a quasi-dynamic scenario allow the user to specify solver settings, time-related information, general attributes, and chart visualization options when accessed using the property editor. Solver settings provide control over the residual tolerances and the maximum number of iterations admitted during the numerical solution of the quasi-dynamic thermal problem formulation, as in the steady state case. The time settings for a quasi-dynamic scenario are: • “StartTime”: The start time of the scenario. This is the first time step in a scenario. The default is to set the calendar day and hour when the scenario is created by the user. • “EndTime”: The end time of the scenario. This is the final time step in a scenario. The default is to set the hour and a plus one calendar day of when the scenario is created. • “TimeWindow”: The total simulation time window or the total amount of time in a scenario (i.e., the difference between EndTime and StartTime). • “TimeStep”: A time step is a fraction of the scenario time window used for discretizing the scenario time window into distinct time points, which are calculated for the variables. The time window is a multiple of the time step, i.e., “TimeWindow” divided by “TimeStep” must be an integer greater than or equal to one. The default is to have a 900 second (i.e., 15 minutes) timestep. • “StepsTimeWindow”: The number of time steps for the scenario time window (i.e. “TimeWindow” divided by “TimeStep”). • “IniState”: Name of the scenario whose terminal state is used as the initial state for the current scenario. This is an optional property, and the default is set to none. The property is in the "General" section of the property editor. In both types of simulations, SAInt is looking for a solution by complying with the solver settings. Such settings define a stopping criterion, which is used to decide when the simulation should stop iterating. The maximum number of iteration steps for the problem linearization is a straightforward criterion, as it defines the maximum number of attempts. However, it cannot enforce a minimum level of accuracy alone. The residual tolerance covers the accuracy of the achieved solution. The criterion is checking whether the intended numerical accuracy has been achieved by comparing the maximum absolute value of the residuals against the user-defined residual tolerance. The iteration continues if
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 39 the residual exceeds the tolerance, and the maximum user-defined number of iterations has not been exceeded. 5.2 Electric Scenarios 5.2.1 Power Flow (ACPF/UACPF) When electrical generators have energized an alternating current (AC) electric network, it is important to understand how current flows across this network and arrives at the demand points so that the safe and stable operation of the network under question can be ascertained. As the demands on the network can vary substantially due to consumer (whether residential, commercial, industrial, or any aggregate of these) behaviour, so too must the generation source and magnitude to meet this demand, with any moment in time of these varying demands and generation constituting an operating condition. In an ideal situation, at any moment, the power supplied to the system must be equal to that consumed via the demands and system losses ( 2 ). The AC power flow (ACPF) problem constitutes the identification of network active and reactive power flows, the associated nodal voltage magnitude and phase angle, and generator outputs that characterize any one of these operating conditions. The network's physical properties, such as the transmission line impedance, susceptance, and other electrical component equivalent values, are used to create a mathematical model to solve these operating conditions. In the power flow solution process, it is implicitly assumed that the system is in a steady state; e.g., at the particular operating condition in question, the generator supplied and demand/network consumed powers are – in ideal conditions - equal and unchanging. Therefore, the “SteadyACPF” scenario in SAInt is characterized by solving the ACPF problem only for a single instance. There are a variety of tools and equipment assets that power system operators can utilize to improve the operating conditions of the system, particularly at times when voltages or losses are higher than preferred. SAInt provides various common components to the user, enabling a true emulation of most electric networks. Transformers with automatic tap control are the most common and are supported in SAInt with voltage control for local and remote buses, line drop compensation, and reactive power control. Shunt devices, which can provide or consume reactive power and, therefore, regulate voltages, are also available. Distribution systems interface consumers with the transmission system. As a result, they operate at much lower voltages and are susceptible to unbalanced loading, making the approximation of phase balance of ACPF simulations no longer applicable and requiring individual phase modelling to 2 In real systems, this cannot be achieved, and disturbances are common. For modelling reasons, the ideal situation is generally considered.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 40 appropriately emulate the loading on that part of the system ( 3 ). To account for these imbalances, the user can use SAInt’s unbalanced ACPF (UACPF) capabilities, which allow the user to model the individual phases of distribution systems, including the associated spatial and load diversity. UACPF builds upon the network constructed with ACPF data and allows the user to provide additional detail to achieve unbalanced modelling results. This UACPF modelling capability maintains all automatic control elements of ACPF. While this scenario type permits the user to use SAInt to model distribution systems, it also provides a platform to model transmission and distribution systems simultaneously. This allows users to assess the interplay between these systems, which is a new capability in commercially available electric network simulation platforms. While an electricity network's steady state operating conditions are of great interest to system modellers for various reasons, such as assessing stability challenges and mitigation processes, there is perhaps just as much interest in understanding how the operating conditions change over time. SAInt provides this capability in the form of “quasi-dynamic” scenarios for all the previously mentioned steady power flow scenarios. These scenarios execute a sequence of power flow simulations applicable to the relevant scenario type (e.g., ACPF or UACPF). With the quasi-dynamic simulations, the progression of operating conditions for an electric network can be assessed as the load and generation vary throughout the designated period of simulation. This functionality complements SAInt’s production cost modelling capabilities by permitting a direct analysis of the full range of determined dispatches. For electric network ACPF simulations, a scenario can use a combination of events of the reach portfolio available for the different electric objects. Some examples of the events are described in Table 6. There is no limit on the number of events used in a scenario. 3 Frequency deviations are another problem in the transient analysis of distribution systems. In this release, SAInt does not simulate any frequency response due to a transient (i.e., a sudden increase or decrease of the generation/demand). SAInt assumes that the system returns to its normal frequency after a transient and covers simulations with a time step of seconds and above.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 41 Object Extension Description network PRIOR Turn on active power compensation mode prioritization. node OFF Turn off connected externals. ON Turn on connected externals. PREF Active power reference. Minimum: 0. QREF Reactive power reference. VMAX Maximum voltage magnitude. Minimum: 0. VMIN Minimum voltage magnitude. Minimum: 0. VMREF Voltage magnitude reference. Minimum: 0. Branch (electric line) IMAX Maximum current. Minimum: 0. OFF Turn off facility, service or object. ON Turn on facility, service or object. PMAX Maximum active power. Minimum: 0. SMAX Maximum apparent power. Minimum: 0. electric demand OFF Turn off facility, service or object. ON Turn on facility, service or object. PMAX Maximum active power. Minimum: 0. PMIN Minimum active power. Minimum: 0. PREF Active power reference. Minimum: 0. PSET Total active power set point. Minimum: 0. QMAX Maximum reactive power. QMIN Minimum reactive power. QREF Reactive power reference. QSET Total reactive power set point. electric supply (generic generator ) OFF Turn off facility, service or object. ON Turn on facility, service or object. PFSET Active power compensation factor set point. Minimum: 0. PMAX Maximum active power. Minimum: 0. PMIN Minimum active power. Minimum: 0. PREF Active power reference. Minimum: 0. PSET Total active power set point. Minimum: 0. QMAX Maximum reactive power. QMIN Minimum reactive power. QREF Reactive power reference. QSET Total reactive power set point. VMSET Voltage magnitude set point. Minimum: 0. Maximum: 100. Table 6. Examples of the events SAInt can model in electric networks and for some of the available electric objects in a ACPF scenario. The extension is the actual name used in SAInt for the event. 5.2.2 Optimal Power Flow (ACOPF) The power flow problem previously discussed involves solving for the flow on the network when there are as many unknowns as describing equations with knowns by using a linearised iterative method. As a result, there is presumed to be a unique solution. When constraints are used instead of static values, such as a range of operating voltages for a generator instead of a specific setpoint, the power flow problem becomes an optimization problem in that the solution engine can look for a set of operating conditions that fulfil some particular objective. The most common objective is minimizing
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 48 For thermal network simulations, a scenario can use a combination of any of the events described in (Table 9). There is no limit on the number of events used in a scenario, but for heat demand and supply objects, not all combinations are acceptable. Certain combinations lead to under-determined problems, while others lead to over-determined problems. SAInt checks for such combinations and provides the user with a description of the possible problem in the simulation's log file. 5.1 Combined Scenarios and Co-scenarios The installations of gas-fired power plants around the world, significant replacement of the traditional gas turbines with electric drivers to operate facilities in the gas system–like LNG terminals, underground gas storages, and compressor stations–and the considerable development of the power to gas technology, have dramatically increased the coupling and interconnections between gas and electricity networks. This increased coupling between gas and electricity networks brought economic and environmental benefits. However, it made the planning and operation of these two systems much more challenging and necessitated using tools capable of modelling the interdependencies between them. A combined scenario describes the operation of two or more networks of different types according to conditions specified in each participating scenario and to the type and properties of the coupling objects. One of the unique features of SAInt is that it allows users to perform combined gas and electric network simulation. In the combined simulation, the system of equations that describe the behaviour of each of the networks will be integrated by adding coupling equations that model the interconnection between gas and electric facilities. Thus, simultaneously solving this integrated system of equations represents the behaviour of these two combined interconnected systems. SAInt simulates various interconnections between gas and electricity networks as a “hub object”. Hub objects include: • The gas offtake from gas networks to generate electricity in gas-fired power plants connected to electricity networks. • The power offtake from the electric network to operate the electric engines in gas compressor stations. • The power offtake from the electric network to operate LNG regasification terminals. • The power offtake from the electric network to operate gas storages. • The power offtake from the electric network to operate Power-To-Gas facilities and to inject hydrogen and synthetic natural gas into the gas network system. Next to a combined simulation approach, SAInt allows for the carrying out of co-simulations. The co-simulation process conceptually involves the extraction of operating conditions from one type of simulation to be used as initial conditions or to adjust constraints on other types of simulations. This process leverages the unique approach of the SAInt software of establishing a network with as much detail as the user can provide, from which a slew of different simulation types can be applied, which will only use the network properties relevant to the simulation of interest. In this way, multi-
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 49 timescale/detail simulations can be executed on the same network, making data handling and control far more efficacious. The predominant application of this process in the SAInt software to date is in two areas: • as an interface between DCUCOPF and AC(O)PF simulations; • as an interface between ACPF simulations and thermal simulations. Within the last case is the application of SAInt to the case study for the living laboratory of the HYPERGRYD partner EnviPark and Sonnenplatz, led by the partner KTH with the support of encoord GmbH. See section 11 for some preliminary examples.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 50 6 Documentation and Data 6.1 SAInt Documentation SAInt’s documentation is organized into four sections. The “Reference Guide” navigates the user through the interface and functionalities of the GUI, CLI, and API. The “How-to Guides” offers instructions to achieve specific tasks. The “Tutorials” section shows, using a case study approach, how to address modelling simulations or optimizations of networks. Finally, the “Learn-More” section dives into the theory and mathematical details, describing modelling choices, logic, and software standards. The user can access SAInt documentation in two ways: (1) through a local copy, which is downloaded during the installation process of SAInt, and (2) a regularly updated, cloud-based version found on the encoord Doc’s webpage. The documentation can be navigated by using either the table of contents on the left (general) or right (section specific), or by searching a specific term using the integrated search engine. 6.1.1 Reference Guide The Reference Guide explains how the software is organized, which functionalities and settings are available, and where to find them. It describes the GUI, API, and introduces a set of typographical conventions to recognize objects, concepts, and properties. The Reference Guide starts with an overview of the software’s architecture (As described in section 1.2 in this document). The most significant part of the Reference Guide is dedicated to a presentation of the GUI, with subsections dedicated to the ribbon bar, the dock panel, and the status bar. In the “Objects” chapter, all modelled objects in SAInt are described, along with their properties, relationships, set of events, and basic and derived results. In the “Scenario” chapter, each simulation or optimization strategy is presented based on the type of network the user needs to model. The “Data Exchange” chapter discusses the capabilities of SAInt to import or export model data or results from and to different formats, like Microsoft Excel™, comma-separated values (CSV) tables, or shapefiles for geographic data, utilizing templates. The chapter “Functions, Expressions and Conditions” uses examples and charts to detail how to use the built-in IronPython scripting capabilities to create customized plots and tables, carry out calculations on results, or implement conditional statements for a “what-if logic” in the simulation. Finally, the Reference Guide covers the use, calls, and methods available in the API using examples and snippets of reusable code. The local copy of the “Reference Guide” can be accessed at any moment from SAInt by using the keyboard shortcut F1. When a user hovers over an icon, object, or section of the GUI and presses F1, they will be redirected to the relevant section for that element. 6.1.2 How-to Guides The How-to Guides section of SAInt documentation is designed to support a user's daily activities. Each How-to Guide addresses a specific and well-defined set of steps guiding the user from one point to another. How-to Guides cover the most frequent tasks and actions a user performs in SAInt and is divided into five different sub-sections, including “Generic”, “Electricity Markets”, “Gas Networks”,
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 51 “Electricity Networks”, “Thermal Networks”, and “Combined". The “Generic” sub-section of the Howto Guides covers actions like defining a network, creating a scenario, editing the topology, or importing data from external data sources. The how-to guides in the “Electricity Markets” section address actions such as outage periods, transmission losses, or flexible demand. The “Gas Networks” section provides step-by-step instructions for actions like creating and editing new gas objects in a network, creating and editing a gas component, and importing and exporting gas qualities. The “Electricity Networks” sub-section covers topics like adding new facilities or fuel types, retrieving wind turbine data, connecting to meteorological data providers, or adding ancillary services. The “Thermal Networks” shows examples of the creation of new externals, networks and events. The "Combined” sub-section contains how-to guides showing the sequence of steps to create a hub system and facility. The “How-to Guides” are recommended for users new to SAInt or would like a refresher on certain topics in SAInt. 6.1.3 Tutorials The “Tutorials” section of SAInt’s documentation provides step-by-step actions on how to use SAInt in real-world industry case studies. SAInt’s advanced functionalities and tools are explored, along with examples of advanced charting, results post-processing, and scenario assessment. The Tutorial section is for users who want to broaden their knowledge of the software, take full advantage of its flexibility, and find better solutions to complex problems. Tutorials engage the user in a self-guided set of step-by-step exercises. They are recommended for any user who prefers a self-paced and selftaught training plan to deepen the understanding of how to address energy systems models practically. As with any other part of SAInt’s documentation, they are constantly under revision and extended to new cases. The available list of tutorials is: • Energy Markets: o Fundamentals of direct current unit commitment optimal power flow (DCUCOPF) o Analyse an electricity market optimization model o Model electricity storage, solar, and wind production in a DCUCOPF o Setting up an Electric Storage in a DCUCOPF Scenario • Electricity Networks: o Steady and quasi-dynamic alternating current power flow (ACPF) simulation o Analyse an alternating current power flow (ACPF) o High voltage and medium voltage ACPF simulation • Gas Network: o Transmission system steady and dynamic simulation o Analyse a transmission system dynamic model o Contingencies and hydrogen blending in transmission systems • Thermal Networks o Steady State and Quasi-Dynamic Thermal Simulation • Coupled Networks: o Feedback in combined dynamic gas and electricity networks
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 52 • Scripting: o API Beginner o API Advanced 6.1.4 Learn More Users can further their technical knowledge of SAInt in the “Learn More” section of SAInt’s documentation. The “Learn More” section provides a mathematical explanation of how SAInt represents and describes objects used in building energy systems. The Learn More section is recommended for the SAInt user interested in learning more about how SAInt operates and how SAInt can be used to solve problems. 6.2 Data Provider Integration SAInt connects to several weather resource data providers, which allows the creation of highresolution wind and solar power time series for different plant designs and locations where weather resource data are available. 6.2.1 Solar Weather Data The current solar weather resource data providers integrated into SAInt are the National Solar Radiation Database (NSRDB), owned and maintained by the National Renewable Energy Laboratory (NREL), and the Photovoltaic Geographical Information System (PVGIS), managed by the Joint Research Centre of the European Commission. The database allows users to collect solar weather resource data into SAInt from around the world (Figure 3). Through solar weather resource data, users can access global horizontal irradiance (GHI), direct normal irradiance (DNI), diffuse horizontal irradiance (DHI), air temperature, and wind speed. Figure 4 and Table 10 describe the solar geographical coverage across the globe. SAInt uses the PVWatts (no financial model) of the System Advisor Model (SAM) developed by NREL to calculate solar PV generation profiles. SAM is a techno-economic model designed to facilitate decision-making for people in the renewable energy industry. This model generates time series data representing solar electricity production for each PV object over a year. The generated profile timestep depends on the weather data’s temporal resolution and inputs describing the system's nameplate capacity, array orientation, mounting type, system losses, etc. 6.2.2 Wind Weather Data The WIND Toolkit is owned and maintained by NREL. SAInt has a built-in wind power performance model to calculate a wind power plant’s power generation time series. The database allows users to collect wind weather resource data into SAInt from around the world. Through wind weather resource data, users can access wind speed, wind direction, air pressure, and air temperature at different locations and heights.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 53 Figure 5 and Table 11 describe the wind geographical coverage across the globe. SAInt has a built-in wind power performance model to calculate a wind power plant’s power generation time series. The generated profile timestep depends on the weather data’s temporal resolution and inputs describing the system's nameplate capacity, wind turbine power curve, system losses, etc. This model generates time series data representing wind electricity production for each WIND object over a year. The installation folder gives the user a database of over 200 wind turbine power curves based on commercial data from over 40 manufacturers. Figure 4. Solar weather resource data providers covered by NSRD and PVGIS (colours described in Table 5). Data Provider Weather Year(s) Temporal Resolution Spatial Resolution Coverage Area (Color) NSRDB - Full Disc 2019 - 2020 15, 30, 60 minutes 2 km x 2 km Dark and Light Blue NSRDB - PSM v.3 1998 - 2020 30, 60 minutes 4 km x 4 km Light Blue NSRDB - PSM v.3.2.2 2021 30, 60 minutes 4 km x 4 km Light Blue (only USA) NSRDB - PSM v.3 - Five Minute Temporal Resolution 2018 - 2020 5, 15, 30, 60 minutes 4 km x 4 km Light Blue NSRDB - India (Suny) 2000 - 2014 60 minutes 10 km x 10 km Green NSRDB - Europe and Africa (METEOSAT IODC PSM) 2017 - 2019 15, 30, 60 minutes 4 km x 4 km Red NSRDB - Himawari PSM v.3 2016 - 2020 10, 30, 60 minutes 2 km x 2 km Orange NSRDB - Puerto Rico 1998 - 2017 5, 30, 60 minutes 4 km x 4 km Black PVGIS 2005 – 2020 (*) 60 minutes between 4 km x 4 km and 25 km x 25 km (*) All World (+) * Depending on the continent of interest. + The global spatial coverage is a mosaic of different satellite databases (PVGIS-SARAH2, PVGIS-NSRDB, PVGIS-SARAH, and PVGIS-ERA5). Antarctica and areas above 80 ° of latitude North are excluded (cfr. https://joint-research-centre.ec.europa.eu/photovoltaicgeographical-information-system-pvgis/getting-started-pvgis/pvgis-user-manual_en). Table 10. Solar weather resource data providers integrated into SAInt.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 54 Figure 5. Wind weather resource data providers covered by NREL Wind Toolkit (colours described in Table 6) Data Provider Weather Year(s) Temporal Resolution Coverage Area (Color) WIND Toolkit - Mexico 2007 - 2014 60 minutes Dark Blue WIND Toolkit - India 2014 15, 60 minutes Dark Purple WIND Toolkit - Central Asia 2015 15, 30, 60 minutes Brown WIND Toolkit - Offshore California 2000 - 2020 5, 15, 30, 60 minutes Light Red WIND Toolkit - Offshore Great Lakes 2000 - 2020 5, 15, 30, 60 minutes Orange WIND Toolkit - Offshore Hawaii 2000 - 2020 5, 15, 30, 60 minutes Black WIND Toolkit - Philippines 2017 60 minutes Dark Yellow WIND Toolkit - Vietnam 2016 60 minutes Light Yellow WIND Toolkit Data - Continental USA 2007 - 2014 5, 15, 30, 60 minutes Dark Red WIND Toolkit - Offshore Gulf of Mexico 2000 - 2020 5, 15, 30, 60 minutes Light Blue WIND Toolkit - Offshore Mid Atlantic 2000 - 2020 5, 15, 30, 60 minutes Aqua Blue WIND Toolkit - NW Pacific 2000 - 2020 5, 15, 30, 60 minutes Light Green WIND Toolkit - Offshore North Atlantic 2000 - 2020 5, 15, 30, 60 minutes Dark Green WIND Toolkit - Southeast Asia 2017-2021 15, 30, 60 minutes Light Purple Table 11. Wind weather resource data providers integrated into SAInt.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 55 6.3 Model-Ready Datasets Model-Ready Datasets (MRD) are datasets ready to be used in SAInt. MRDs are curated and managed by encoord and available for purchase for clients with a SAInt license. There are two types of MRDs: non-commercial and commercial. 6.3.1 Non-commercial Model-ready Datasets Non-commercial MRDs are available by request for all users of SAInt. • Belgium Coupled Model: This model allows the execution of steady AC-Power Flow and steady gas-independent analysis or as a combined simulation of the two scenarios. The electric model has 75 nodes, 77 transmission lines, 12 transformers, 46 electric demand consumption points, 21 generic generators, 45 fuel generators fuelled by different fuels (natural gas, coal, nuclear, and oil), 8 hydro generators, 10 wind generators (onshore and offshore), and 9 solar generators. The gas model has 147 nodes, 172 pipelines, 3 compressor stations (1 gas-driven and 2 electric-driven), 3 control valves, 38 gas demand consumption points, 8 supply points, 1 underground storage, and 1 Liquid Natural Gas (LNG) terminal. In addition, there are 2 gas qualities implemented (methane and hydrogen). Finally, there are 4 hub facilities where electric and a gas object overlap: 2 electric-driven gas compressors, 1 gasfired generator, and 1 power to gas facility. • GasLib134 – Greece: This model allows the execution of a steady and dynamic gas scenario. The model network, its topology, set of facilities, type of fluid, demand profiles are entirely fictional. The gas model has 131 pipelines, 1 compressor station, 1 control valve, 45 gas demand consumption points, 3 supply points, and 1 gas quality type. The dynamic scenario is an 8-day time period with a time step resolution of 15 minutes (Schmidt, et al., 2017) and the data is available at https://gaslib.zib.de). • IEEE 39 Bus System: This model allows the execution of steady AC-Power Flow. The model has 39 nodes, 34 transmission lines, 12 transformers, 31 demand consumption points, 10 generic generators, and 2 shunts (Zuo, Sossan, Bozorg, & Paolone, 2018; Athay, Podmore, & Virmani, 1979). • IEEE 9 Bus System: This model allows the execution of steady AC-Power Flow. The model has 9 nodes, 6 transmission lines, 3 transformers, 3 demand consumption points, and 3 generic generators. • RTS-GMLC – based on IEEE 96 bus system: The model allows the execution of steady ACPower Flow, and 3 production cost model scenarios (DCUCOPF) of 1 year, 2 weeks, and 5 days. The electric model has 3 zones, 73 nodes, 106 lines, 15 transformers, 15 ancillary services (up and down reserves), 3 user-defined constraints replicating a DC-line flow, 53 demand consumption points, 53 generic generators (utility PV and wind generators), 1 hydro generator, 75 fuel generators, 31 solar generators, 1 electric storage unit, and 3 shunt devices. The scenario comprises 3 demand profiles for the 3 zones, 1 concentrated solar
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 56 power (CSP), 25 utility PV, 4 wind, and 31 rooftop PV. The original data are available from the Git repository at https://github.com/GridMod/RTS-GMLC. • Barry Island: The model allows the execution of a steady thermal scenario. The model network, its topology, set of facilities, and demand profiles are entirely fictional. The model has 33 nodes, 33 pipelines of diameters between 32 mm and 125 mm, 22 thermal demand consumptions, and 3 supply points. This model has been developed as a contribution to the HYPERGRYD project to allow users to experiment with thermal modelling and co-simulations with electric networks (Liu, 2013; Liu, Wu, Jenkins, & Bagdanavicius, 2016). 6.3.2 Commercial Model-ready Datasets Commercial MRDs can be purchased by the SAInt user. The list below explains the commercial MRDs. Encoord can develop ad hoc electric, gas, thermal, and combined models upon request. • European Zonal Electricity Market: The model allows the execution of production cost model scenarios (DCUCOPF) of 1 year with an hourly resolution. The model has been developed using data collected from the European Network of Transmission System Operators for Electricity (ENTSOe) and additional sources. The model has been benchmarked against ENTSOe in terms of generation, power not served, and flow distribution. The model has 46 bidding zones, 44 demands, 86 interconnections, and 2453 generators separated into 18 production types (solar, wind onshore, wind offshore, biomass, geothermal, other renewable, waste, other, run-of-river, hydro water reservoir, pumped storage, natural gas, oil, hard coal, oil shale, peat, lignite, and uranium). • United States Zonal Electricity Market: The model allows the execution of production cost model scenarios (DCUCOPF) of 1 year with an hourly resolution. The model has 11 zones (CAISO, MISO, ERCOT, PJM, etc.), 134 nodes, 134 demands, 310 interconnections, 75 storages, and 9270 generators separated by multiple production types. • Indian Zonal Electricity Market: The model allows the execution of production cost model scenarios (DCUCOPF) of 1 year with an hourly resolution. The model has been developed and benchmarked against the Regional Energy Deployment System (ReEDS) Indian model in terms of generation, power not served, and flow distribution. The model has 34 bidding zones, 34 demands, 70 interconnections, and 1067 generators separated into different production types (solar, wind, hydro run-of-river, coal, lignite, oil, diesel, natural gas, bagasse, and uranium fuel generators).
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 57 7 Data Importing Tools In order for SAInt to read network data files, the data needs to be in a certain native format. Most likely, when a user starts to work on a new project, he may not have the data readily available in SAInt native format, but data could be in other formats and/or from other software platforms. Because creating a SAInt network may require time and effort, a set of translation tools is available to convert other common data types for electric and gas networks into the SAInt format. While a few of the translations require the use of an external Python interpreter, others are integrated into the backend of SAInt. 7.1 Synergi Gas to SAInt Synergi Gas is a hydraulic modelling simulation tool by DNV ( 5 ). SAInt provides a conversion tool that supports importing and converting Synergi Gas models to SAInt gas networks. The tool allows for conversion of the coordinate reference system of the original data, and to import a steady state scenario to be used as validation step to check the conversion. The user can compare the solution from Synergi Gas to the solution calculated by SAInt using the same set of events and object properties. The objects from the Synergi model are converted to the SAInt object types using as much of the original data as possible. SAInt and Synergi gas benchmarking has been verified on many test networks and physical systems. The tool will utilize default properties if data is unavailable. This conversion tool is integrated into the SAInt software and requires no additional software or installations. 7.2 CYME to SAInt CYME ( 6 ) is an industry-standard distribution simulation tool developed by CYME International T&D Inc. SAInt is capable of reading CYME datasets and converting them in a one-to-one manner to SAInt objects and solving a UACPF scenario type to arrive at the unbalanced power flow results. This translation has been validated to ensure the power flow results between the tools are identical. With this conversion, CYME users can immediately convert to the SAInt data framework and continue working on their models with the additional features that SAInt provides. This translation tool is not integrated directly into SAInt, but it is provided along SAInt as an easy-to-use Python script. 5 Read the product description at https://www.dnv.com/services/hydraulic-modelling-and-simulation-software-synergi-gas-3894 (last visited on 14/02/2024). 6 Read the product description at https://www.cyme.com/software/ (last visited on 14/02/2024).
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 64 Object Extension Description (electric line) CalcImp Indicates how the network per unit impedances are calculated. If CalcImp is false, the branch per unit values are used for the calculation. If true, the per unit lenth properties of line are used XXDEF Positive sequence series reactance in line per unit system. Series capacitor is represented by negative value. Used if "CalcImp" is false. RRDEF Positive sequence series resistance in branch per unit system. Defined to be non-negative. Used if "CalcImp" is false. BBDEF Positive sequence shunt susceptance in branch per unit system. Used if "CalcImp" is false. Must be non-negative for electric line, because the shunt is capacitive XX0DEF Zero sequence line reactance in line per unit system. Series capacitors can be modeled with negative values. The value is ignored for sigle-phase lines RR0DEF Zero sequence line resistance in line per unit system. The value is ignored for single-phase lines BB0DEF Zero sequence line susceptance in line per unit system. The value is ignored for single-phase lines DrawLine If true, element will be drawn as a straight line and internal points will be neglected FromName Name of FromNode N Scaling factor for impedances. The series impedance will be divided by this value, and the shunt admittance will be multiplied by this value. Not used if "CalcImp" is false Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node L Total length of electric line Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type PHASESINUSE Identifies which phases of the line are connected, valid values are A, B, C, AB, AC, BC or ABC. XXL Positive sequence line reactance per length RRL Positive sequence line resistance per unit length BBL Positive sequence line susceptance per unit length RATEDS Rated apparent power, assuming balanced three-phase object. If its value is NaN, which is the default, the network Base Apparent Power will be taken. It is used in the network per unit calculations. To change the value of a property to its default, right-click on the property and select "Set to the default value" RATEDV Rated line-to-line voltage, assuming balanced three-phase object. If its value is NaN, which is the default, the network Base Voltage will be taken. It is used in the network per unit calculations. To change the value of a property to its default, right-click on the property and select "Set to the default value" SubName Sub the branch belongs to ToName Name of ToNode Visible If true, the object symbol will be visible in maps XX0L Zero sequence line reactance per unit length. The value is ignored for single-phase lines RR0L Zero sequence line resistance per unit length. The value is ignored for single-phase lines BB0L Zero sequence line susceptance per unit length. The value is ignored for single-phase lines Electric demand Alias Alternative object name. Any character, including non-alphanumeric, is allowed Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node LOADTYPE How the load is connected between phases and (or) neutral, valid values are Wye (balanced), Delta (balanced), A, B, C, AB, BC, or CA Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type NodeName Name of node the external is connected to PWF Power factor, PWF=cos(phi)=P/S PWFType Power factor type "ind" for lagging (inductive load) and "cap" for leading (capacitive load) power factor. The type doesn’t matter for a resistive load (unity power factor) as far as the PowerFactor is set to 1. Used for calculating QSET from PSET if no QSET event is defined
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 65 Object Extension Description RATEDV Rated line-to-line voltage, assuming balanced three-phase object. If its value is NaN, which is the default, the network Base Voltage will be taken. It is used in the network per unit calculations. To change the value of a property to its default, right-click on the property and select "Set to the default value" Visible If true, the object symbol will be visible in maps Electric supply (generic generator ) Alias Alternative object name. Any character, including non-alphanumeric, is allowed CALCDFLT Calculate default values for maximum ramp rate (MaxUpRampDef and MaxDownRampDef), and (when applicable) startup time (MinUpTimeDef and MinDownTimeDef), generator capability curve (GCC), heat rate curve (HR0, HR1, and HR2) GenType Specifies the generator type Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type NodeName Name of node the external is connected to XXN Neutral reactance in in pu in the generator base system RRN Neutral resistance in pu in the generator base system XXSE Per phase output reactance in in pu in the generator base system RRSE Per phase output resistance in pu in the generator base system RATEDS Rated apparent power, assuming balanced three-phase object. If its value is NaN, which is the default, the network Base Apparent Power will be taken. It is used in the network per unit calculations. To change the value of a property to its default, right-click on the property and select "Set to the default value" RATEDV Rated line-to-line voltage, assuming balanced three-phase object. If its value is NaN, which is the default, the network Base Voltage will be taken. It is used in the network per unit calculations. To change the value of a property to its default, right-click on the property and select "Set to the default value" Visible If true, the object symbol will be visible in maps Table 13. Partial list of the input required by SAInt to model electric networks and some of the electric objects. Not all electric objects are reported. The extension is the actual name used in SAInt for the event. 9.2 Gas objects A set of gas objects has been designed in SAInt to carry out extensive simulations. The list of implemented objects is provided in Table 14. For these objects, SAInt requires the user to provide details as object’s input. Table 15 describes a partial list of the modelled input for some of the types of gas objects. The reader should check Table 8 in section 5.3 for an example of a list of events that can be used to build steady state or quasi-dynamic gas scenarios.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 66 Icon Type Name Description GNET Gas Network Models the characteristics and interactions of facilities and/or components of a gas network. Serves as a container for all objects in the gas network GSUB Gas Sub Models a subset of nodes, branches, and gas externals of a gas network. A gas sub is branch-oriented, i.e., only gas branches can be assigned to a gas sub, and every gas branch belongs to only one gas sub GZN Gas Zone Models a subset of nodes, branches, and externals of a gas network. A gas zone is nodeoriented, i.e., only gas nodes can be assigned to a gas zone, and every gas node belongs to only one gas zone GGRP Gas Group Models a subset of different objects in a gas network. Except for the gas network, subs, and zones, any gas object can be added to a gas group. In contrast to gas subs and zones, gas groups do not follow any specific assignment rules. Thus, a gas object can be part of multiple gas groups GNO Gas Node Models a physical or virtual location in the gas network where gas can be injected or extracted through externals (gas demand, supply, storage, etc.) GPI Gas Pipeline Models the transport of gas between two distant locations GCS Gas Compressor Models the increase of inlet pressure to a higher outlet pressure to ensure continuous transport and delivery of gas to customers at the contracted nominations and delivery pressures GCV Gas Control Valve Models the reduction of inlet pressure to lower outlet pressure or the control of gas flow to a downstream network GVA Gas Valve Models a valve station, which is used to route the gas stream and shut down sections of the network for maintenance or in case of a disruption. GRE Gas Resistor Models passive devices that cause a local pressure drop, such as meters inlet piping, scrubbers, coolers, heaters, etc GSUP Gas Supply Models the injection of gas at a node GDEM Gas Demand Models the consumption of gas at a node GSTR Gas Storage Models the withdrawal and injection of gas from/into the storage inventory of an (underground) gas storage facility LNG LNG terminal Models the arrival of LNG-vessels and the discharge, storage, regasification, and injection of liquefied natural gas in an LNG regasification terminal GQUAL Gas Quality Models the thermodynamic properties (gross/net calorific value, relative density, etc.) and the mixtures of different gas molecules (gas components) flowing through the network GCMP Gas Component Models the thermodynamic properties (gross/net calorific value, relative density, etc.) of a gas molecule included in the gas mixture GCUS Gas Component Usage Models the molar percentage of mixture of a gas component included in a gas quality Table 14. Icons and descriptions of the object types available in the gas network model in SAInt 3.5.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 67 Object Extension Description network PAMB Ambient pressure Pz_b Base pressure for custom compressibility factor equation: Z(P.bar) = 1 + Z_1 * P.bar + Z_2 * ((P.bar - Pz_b.bar) ^2 - Pz_b.bar ^2) ZEQN Equation for computing compressibility factor CRSType Network coordinate reference system for the node locations LAMEQN Equation for computing friction factor Info Information related to the network model. Any character, including non-alphanumeric, is allowed Kappa Isentropic exponent, i.e. ratio between isobaric and isochoric heat capacity Z_1 Coefficient of linear term in custom compressibility factor equation: Z(P.bar) = 1 + Z_1 * P.bar + Z_2 * ((P.bar - Pz_b.bar) ^2 - Pz_b.bar ^2) Z_2 Coefficient of quadratic term in custom compressibility factor equation: Z(P.bar) = 1 + Z_1 * P.bar + Z_2 * ((P.bar - Pz_b.bar) ^2 - Pz_b.bar ^2) Pn Pressure at reference condition Tn Reference temperature VarPAMB Consider ambient pressure dependence on the elevation VISC Dynamic viscosity used for calculating the friction factor node H Elevation Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type Visible If true, the object symbol will be visible in maps X Cartesian X coordinate for visualizing the node in the map. Externals assigned to the node are not displayed Y Cartesian Y coordinate for visualizing the node in the map. Externals assigned to the node are not displayed ZoneName ZoneName of the zone the node belongs to Branch (gas pipeline) DrawLine If true, element will be drawn as a straight line and internal points will be neglected FromName Name of FromNode HTC Heat transfer coefficient Info Information entered for the object. Any character, including non-alphanumeric, is allowed D Inner pipe diameter or design diameter of non-pipe branches RO Inner wall roughness of pipeline InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type Eff Pipeline efficiency L Pipeline length SubName Sub the branch belongs to ToName Name of ToNode Visible If true, the object symbol will be visible in maps WTH Thickness of the pipe wall Gas demand Alias Alternative object name. Any character, including non-alphanumeric, is allowed Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type NodeName Name of node the external is connected to Visible If true, the object symbol will be visible in maps Alias Alternative object name. Any character, including non-alphanumeric, is allowed
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 68 Object Extension Description Gas supply Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type NodeName Name of node the external is connected to SQSETNAME Name of scheduled supply gas quality Visible If true, the object symbol will be visible in maps Table 15. Partial list of the input required by SAInt to model gas networks and some of the gas objects. Not all gas objects are reported. The extension is the actual name used in SAInt for the event. 9.3 Thermal objects A set of thermal objects has been designed in SAInt to carry out basic simulations. The list of implemented objects is provided in Table 16. For these objects, SAInt requires the user to provide details as the object’s input. Table 17 describes the list of the modelled input for each type of thermal object. The reader should check (Table 9) in section 5.4 for a list of events that can be used to build steady state or quasi-dynamic thermal scenarios. Icon Type Name Description TNET Thermal Network Models the characteristics and interactions of facilities and/or components of a thermal network. Serves as a container for all objects in the thermal network TSUB Thermal Sub Models a subset of nodes, branches, and thermal externals of a thermal network. A thermal sub is branch-oriented, i.e., only thermal branches can be assigned to a thermal sub, and every thermal branch belongs to only one thermal sub TZN Thermal Zone Models a subset of nodes, branches, and externals of a thermal network. A thermal zone is node-oriented, i.e., only thermal nodes can be assigned to a thermal zone, and every thermal node belongs to only one thermal zone TGRP Thermal Group Models a subset of different objects in a thermal network. Except for the thermal network, subs, and zones, any thermal object can be added to a thermal group. In contrast to thermal subs and zones, thermal groups do not follow any specific assignment rules. Thus, a thermal object can be part of multiple thermal groups TNO Thermal Node Models a physical or virtual location in the thermal network where heat (or cold) can be injected or extracted through externals TPI Thermal Pipe Models the transport of heat (or cold) between two distant locations HSUP Heat Supply Models the injection of heat at a node HDEM Heat Demand Models the consumption of heat at a node Table 16. Icons and descriptions of the object types available in the thermal network model.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 69 Object Extension Description network PAMB Ambient pressure CRSType Network coordinate reference system for the node locations Info Information related to the network model. Any character, including non-alphanumeric, is allowed PDMIN Minimum pressure difference between two sides of all the nodes node Alias Alternative object name. Any character, including non-alphanumeric, is allowed H Elevation Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type Visible If true, the object symbol will be visible in maps X X coordinate for visualizing the node on a geographic map or on a Cartesian plane. Externals assigned to the node are not displayed. Y Y coordinate for visualizing the node on a geographic map or on a Cartesian plane. Externals assigned to the node are not displayed. branch Alias Alternative object name. Any character, including non-alphanumeric, is allowed Info Information entered for the object. Any character, including non-alphanumeric, is allowed D Inner pipe diameter or design diameter of non-pipe branches RO Inner wall roughness of pipeline InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node HTCLIN Linear heat transfer coefficient Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type L Pipeline length Visible If true, the object symbol will be visible in maps FromName Name of from node ToName Name of to node Heat demand Alias Alternative object name. Any character, including non-alphanumeric, is allowed Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService ndicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type NodeName Name of node the external is connected to Visible If true, the object symbol will be visible in maps Heat supply Alias Alternative object name. Any character, including non-alphanumeric, is allowed Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService ndicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type NodeName Name of node the external is connected to Visible If true, the object symbol will be visible in maps Table 17. List of the input required by SAInt to model thermal networks and thermal objects. The extension is the actual name used in SAInt for the event.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 70 9.4 Combined electric-gas objects The list of implemented coupling objects between electric and gas networks is provided in Table 18. For these objects, SAInt requires the user to provide details as object’s input. Table 19 describes the list of the modelled input for each type of hub object. Icon Type Name Description HUBS Hub System Models the operation of facilities coupling different energy network types. Serves as a container for all hub objects GFG Gas-Fired Generator Models the coupling between a Fuel Generator (FGEN) and a Gas Demand (GDEM) P2G Power-To-Gas Facility Models the coupling between an Electric Demand (EDEM) and a Gas Supply (GSUP). A prime example of a Power-To-Gas Facility is an electrolyzer plant, in which electric power is used to convert water into oxygen and hydrogen. The latter is then injected into the gas network EDGCS Electric-Driven Gas Compressor Models the coupling between an Electric Demand (EDEM) and a Gas Compressor (GCS). In an Electric-Driven Gas Compressor, electric power is converted into the mechanical power needed to increase the gas pressure EDGSTR Electric-Driven Gas Storage Models the coupling between an Electric Demand (EDEM) and a Gas Storage (GSTR). It models the electricity consumption needed to operate the gas storage EDLNG Electric-Driven LNG Terminal Models the coupling between an Electric Demand (EDEM) and an LNG Terminal (LNG). It models the electric power consumption needed to operate the LNG terminal Table 18. Icons and descriptions of the object types available in the hub system in SAInt 3.5. Object Extension Description Electricdriven gas compress or station EDEMNAME Electric Demand Name GCSNAME Gas Compressor Name Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type PWF Power factor, PWF=cos(phi)=P/S PWFType Power factor type "ind" for lagging (inductive load) and "cap" for leading (capacitive load) power factor. The type doesn’t matter for a resistive load (unity power factor) as far as the PowerFactor is set to 1. Used for calculating QSET from PSET if no QSET event is defined Visible If true, the object symbol will be visible in maps Electricdriven gas storage K0 Coefficient of constant term for the coupling equation EDEMNAME Electric Demand Name GSTRNAME Gas Storage Name Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node K1 Coefficient of linear term for the coupling equation Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type PWF Power factor, PWF=cos(phi)=P/S
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 71 Object Extension Description PWFType Power factor type "ind" for lagging (inductive load) and "cap" for leading (capacitive load) power factor. The type doesn’t matter for a resistive load (unity power factor) as far as the PowerFactor is set to 1. Used for calculating QSET from PSET if no QSET event is defined K2 Coefficient of quadratic term for the coupling equation Visible If true, the object symbol will be visible in maps Electricdriven LNG terminal K0 Coefficient of constant term for the coupling equation EDEMNAME Electric Demand Name Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node K1 Coefficient of linear term for the coupling equation LNGNAME LNG Terminal Name Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type PWF Power factor, PWF=cos(phi)=P/S PWFType Power factor type "ind" for lagging (inductive load) and "cap" for leading (capacitive load) power factor. The type doesn’t matter for a resistive load (unity power factor) as far as the PowerFactor is set to 1. Used for calculating QSET from PSET if no QSET event is defined K2 Coefficient of quadratic term for the coupling equation Visible If true, the object symbol will be visible in maps Gas-fired generator Alias Alternative object name. Any character, including non-alphanumeric, is allowed HR0 Constant heat rate coefficient FGENNAME Fuel Generator Name GDEMNAME GasDemandName Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node HR1 Linear heat rate coefficient Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type HR2 Quadratic heat rate coefficient Visible If true, the object symbol will be visible in maps Power-togas facility EDEMNAME Electric Demand Name GSUPNAME Gas Supply Name Info Information entered for the object. Any character, including non-alphanumeric, is allowed InService Indicates if an object is considered or disregarded in the execution of a scenario. Externals connected to the node inherit the "inService" status of the node Name Object Name. Permitted characters are letters, numbers, and underscore ("_"). The name should start with a letter, and have a length of 1 to 30 characters. The name should be unique for each object type Eff Efficiency factor for the power-to-gas conversion PWF Power factor, PWF=cos(phi)=P/S PWFType Power factor type "ind" for lagging (inductive load) and "cap" for leading (capacitive load) power factor. The type doesn’t matter for a resistive load (unity power factor) as far as the PowerFactor is set to 1. Used for calculating QSET from PSET if no QSET event is defined Visible If true, the object symbol will be visible in maps Table 19. List of the input required by SAInt to model hubs objects. The extension is the actual name used in SAInt for the event.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 72 10 Mathematical Models The following sections provide a high-level mathematical formulation of the numerical models implemented in SAInt 3.5 for thermal and electric objects. 10.1 Steady-state Model of a Thermal Network A thermal network delivers heat from supplies to demands based on the transportation of working fluid (liquid, non-compressible) and heat exchangers. The transportation of fluid must be described, and the equation is largely simplified compared to that of compressible gas (Frederiksen & Werner, 2013). However, the heat transferred into/out of the working fluid is usually specified. That is, the event in the scenario is not related to flow but heat. Thus, another set of equations to describe the relationship between temperature and heat must be considered. There are two viewpoints in a thermal network, illustrated in Figure 7: • At the top, the hydraulic viewpoint sees the network as having two parts: hot and cold water is pumped to circulate along pipes and externals (which transfer heat in or out of the network). • At the bottom, the heat viewpoint focuses on the delivery of heat from supplies to demands and on how the fluid returns to the supply points through the cold part of the network. Figure 7. The two modelling viewpoints used in SAInt to describe a thermal network. At the top, the hydraulic viewpoint sees water pumped to circulate within pipelines and heat exchangers in the hot and cold sub-networks. At the bottom, the heat viewpoint focuses only on the hot part, which delivers heat from supplies to demands. When looking at other modelling platforms (e.g., MATLAB Simscape with “House Heating System”) ( 9 ), one aspect is clear, they require the user to provide an important amount of data and details to 9 Read the modelling approach description with MATLAB Simscape at https://se.mathworks.com/help/hydro/ug/house-heatingsystem.html;jsessionid=69fb1d7111c41bc57bedbb823bfc (last visited on 14/02/2024).
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 73 start with. This requirement not only imposes a burden on the user but also implies the need to maintain and quality-check the information. SAInt thermal network capabilities have been developed with the primary focus on network topology and on how supply/demand can be matched. The overall mathematical treatment has been simplified as much as possible by striking a balance between rigorous physical description of the hydraulic and heat transfer processes, as well as usability, scalability, and maintenance of the model and the data. The hydraulic viewpoint implemented in the solver of SAInt assumes that: (1) the cold part of a network mirrors the hot part; (2) heat exchangers and pipelines are described as SAInt branch objects; (3) in any network there must be at least one external to regulate the pressure of the fluid in the system. The mathematical graph conceptualizing a thermal network will have two types of nodes: one type on the hot side and the other on the cold side. It is important to distinguish these two types because a heat exchanger must connect a supply point and a return point and a pipeline should connect two nodes in the same type. The heat viewpoint implemented in the solver of SAInt assumes that: (1) the pipelines in the cold and hot part are the same (this simplifies the set of equations related to pipelines); (2) flow rates and pressure drops will be equal in magnitude and opposite in direction between cold and hot parts; (3) heat exchangers representing supply/demand points are modelled as “external” objects (i.e., heat flows either in or out of them) like electric or gas demand/supply points. In the following sections, the reader is introduced to the basic set of equations to describe a thermal network from the hydraulic and thermal point of view and considering a graph perspective (i.e., nodes and branches). A short description of the iterative approach used in the linearization problem of the set of equations is also provided, along with an indication of the complexity of the problem by enumerating how many equations are needed based on the number of building blocks (i.e., nodes and branches). 10.1.1 Node level equations When a graph approach is used to describe a thermal network, the first step is to model the hydraulic and energy processes happening at the node level. The node model allows the imposition of two balancing equations for the mass of the circulating fluid and its energy, which also incorporate the connectivity of the system by using branches and externals making up the network. The balancing equations are based on the application of Kirchhoff’s Current Law to mass and energy in the network (Frederiksen & Werner, 2013). SAInt uses two types of nodes to better describe the hydraulic viewpoint: one type of node is for the hot side of the system and the other type is for the cold side. In SAInt a heat exchanger is modelled as a «special pipeline» (i.e., it uses under the hood the same model and code infrastructure as a normal pipeline), and it connects a supply node and a return node (while a normal pipeline connects two nodes in the same type), and – usually – it has one default temperature value for the supply part
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 80 10.3.1 Branch Equation Using a per-unit system, application of the Ohm’s law for a branch connecting two nodes can be expressed as (Figure 8): 𝑉1−𝑉2=(𝑅+𝑗𝑋)𝐼12 =𝑍12𝐼12 𝐼11 =𝑌11𝑉1 𝐼22 =𝑌22𝑉2 𝐼12_𝑓𝑟𝑜𝑚 =𝐼12 +𝐼11 and 𝐼21_𝑡𝑜 =𝐼22 −𝐼12 Figure 8. PI-equivalent model of an electric branch. 𝑍12 =𝑅+𝑗𝑋 represents the series impedance of the line, while the 𝑌11 and 𝑌22 represent the shunt admittance parts. For an electric line and a transformer with a nominal turn ratio, Y11, and Y22 are equal and represent half of the shunt admittance of the branch. For a transformer with an off-nominal turns ratio, or with a tap position and phase adjustment, 𝑌11 and 𝑌22 will be generally different. The same is true if there are different shunt capacitors at the two sides of the node. 10.3.2 Nodal Equation The nodal equation guarantees the current balance by applying Kirchhoff’s current law. It states that the sum of all currents flowing into the node is equal to the sum of all currents leaving the node. For a given node 𝑖, the current balance equation is given by: ∑ 𝐼𝑠 𝑆𝑜𝑢𝑟𝑐𝑒𝑠 𝑠=1 − ∑ 𝐼𝑑 𝐷𝑒𝑚𝑎𝑛𝑑𝑠 𝑑=1 = ∑ 𝐼𝑠ℎ 𝑆ℎ𝑢𝑛𝑡𝑠 𝑠ℎ=1 + ∑ 𝐼𝑖𝑗 𝑁𝑜𝑑𝑒𝑠 𝑗=1 The first term on the left-hand side represents the sum of the current injected at the node from the sources, while the second term represents the sum of currents withdrawn by the loads/demands connected to the node. The first term on the right-hand side denotes the sum of charging currents due to line susceptance or shunt capacitances (e.g. 𝐼11 for the node on the left side, in Figure 8 above). The
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 81 last term represents the branch current flows leaving the node-𝑖 (e.g. 𝐼12 for the node on the left side in Figure 8). Note that multiplying the conjugate of the current balance equation at a given node with the corresponding nodal voltage gives the active and reactive power balance equations. 10.3.3 Equations for Externals Sources and demands, including storage devices, are governed by an apparent power equation that relates their current and nodal voltage with their active and reactive power. 𝑆=𝑃+𝑗𝑄 =𝑉𝑛𝑜𝑑𝑒𝐼∗ A shunt capacitor is described using its rated reactive power and active power (due to equivalent leakage resistance). Using the network per unit system, these values can be converted to equivalent susceptance (B) and conductance (G) values. The shunt current leaving the node can then be expressed using the following equation. 𝐼𝑠ℎ =(𝐺+𝑗𝐵)𝑉𝑛𝑜𝑑𝑒 10.3.4 Control Modes in ACPF In ACPF, sources (generators and storage devices) and transformers can be operated in different control modes. Active power and reactive power control modes can be independently defined for a source. Considering active power dispatch, a source can either participate in a distributed slack operation mode or be set to produce only a fixed active power output. Distributed slack is a setting in which different sources can share the deficit of generation to meet the demand and losses in the network according to predefined participation factors. Sources can also be set in either a fixed reactive power generation mode or a voltage control mode. In the latter case, the source generates or consumes as much reactive power as required to keep the nodal voltage at the set value. If the required reactive power generation exceeds the minimum or maximum limit, the source will be set at the nearby boundary and act as a fixed reactive power supply unit. On the other hand, a transformer can be operated in four different control modes. The default is TAPSET, in which the value of the TAP position set by the user is directly taken in the power flow computation. The second control mode is the voltage control mode which is defined together with a remote node and set value. In this case, the solver tries to find out the value of the tap position that keeps the voltage magnitude at the remote node closer to the voltage setting. The third control mode is called line-drop-compensation mode. In this mode, the tap position is adjusted in such a way that the difference between the To-side voltage magnitude of the transformer and the voltage set point is closer to the voltage drop on an-equivalent line-drop-impedance when the transformer current (on
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 82 the To-side) flows through it. The fourth control mode is the reactive power control mode, in which the tap positions are adjusted so that the reactive power flow through the transformer is closer to the set value. In quasi-dynamic scenarios, a tolerance/deadband value is applied for voltage, line-dropcompensation and reactive power control modes to avoid too frequent switching. In a steady-state scenario, zero tolerance is applied so that a solution as close as the set value can be achieved.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 83 11 Examples of Applications In the following, we showcase some examples to demonstrate the functionalities of SAInt for ACPF electric network analysis, thermal modelling, and co-simulation of electric and thermal networks. The examples are based on publicly available models or are prototypes based on an initial analysis of the systems of the HYPERGRYD partners EnviPark and Sonnenplatz. The numerical details of the scenarios are based on fictional values and cannot be considered normal operational modes of the networks. 11.1 Electric Network Example The IEEE 39-bus test bench mentioned in section 6.3.1 is presented here as an example of a simulation model used to demonstrate the validation of the performance of SAInt in a steady state ACPF simulations. We use the nodal voltage magnitude and relative voltage angles at the node level, along with the active power and the reactive power of the generators as validation parameters. The results obtained by SAInt are compared to the ones obtained by PSS®E for the same type of infrastructure and – as much as possible - the same type of scenario. A copy of the IEEE 39-bus model in non-SAInt format is available from the online repository of the Texas A&M University “Electric grid test case repository” and is available from the section “LiteratureBased Power Flow Test Cases” (https://electricgrids.engr.tamu.edu/electric-grid-test-cases) along with the details of a base steady state scenario. Alternatively, the model can be reconstructed by using the description provided by Zhenyao (2024) available from the “IEEE DataPort” website (https://ieee-dataport.org). 11.1.1 The IEEE 39-bus Test Bench The IEEE 10-machine 39-bus power system is a simplified model of the high voltage transmission system in the northeast of the “New England area” of the United States of America. It was presented for the first time in a paper by Athany, Podmore and Virmani on the journal “IEEE Transactions on Power Apparatus and Systems” (1979). It has since been often used for scientific research and publications. The 10-machine 39-bus power system consists of 39 buses, 10 generators, 19 loads, 34 lines and 12 transformers (see Figure 9). A complete description of the system is provided in Zhenyao (2024) or from the files prepared by Pablo Ledesma (pab[email protected]m.es) for the “Electric grid test case repository” of Texas A&M University. The reference scenario used for the validation is an ACPF steady state simulation based on the system described in the quoted reference sources and reproducing the simulation provided by the “Electric grid test case repository”. Table 22 provides an overview of the comparison of active and reactive power for the 10 generators between the published PSS®E simulation values and the SAInt simulation values. The two series of values for the active power are practically identical (within the assumed numerical accuracy). For the reactive power, the maximum difference (in absolute terms) is -0.026 MW, which, in relative percentage, is equal to -0.02 % of the original value. The maximum percentage difference is 0.193 % for a value of -7.786 MW.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 84 Figure 9. Example of the SAInt interface showing: the Model Explorer with the main objects making up the model for the IEEE 39-bus power system (see numbers in brackets for the count of such objects), the Map Window with power system with nodes indicating the voltage magnitude (per unit) and lines indicating the voltage angle (in degree) for a steady state ACPF simulation, and the Property Editor showing some of the details of the selected bus number 2.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 85 Table 23 provides an overview of the comparison of the voltage angle values for all 39 nodes of the model. In four cases, we can identify a numerical difference (in absolute value) of 0.0001 MW. When looking at such a difference in percentage over the original PSS®E value, the largest figure we register is -0.0019 %. It should be noted that the original PSS®E values have a numerical precision of up to four decimal digits. Again, the two series are identical. Table 24 provides an overview of the comparison of the voltage magnitude (per unit) values for all 39 nodes of the model. In ten cases, we can identify a numerical difference of 0.00001 p.u. When looking at such a difference in percentage over the original PSS®E value, the largest figure we register is 0.001 %. It should be noted that the original PSS®E values have a numerical precision of up to five decimal digits. We can still conclude that the two series are practically identical. Overall, the validation supports the statement that the results obtained by using SAInt are perfectly aligned with the solution provided by PSS®E. Generator number Active power Reactive power PSS®E [MW] SAInt [MW] Delta [MW] Delta in % PSS®E [MVAr] SAInt [MVAr] Delta [MVAr] Delta in % 1 250 250 0 0 132.937 132.963 -0.026 0.0196 2 547.326 547.326 -0.0001 1.8 10-5 -45.966 -45.954 -0.012 0.0261 3 650 650 0 0 185.267 185.28 -0.013 0.0070 4 632 632 0 0 101.136 101.136 0 0 5 508 508 0 0 161.375 161.367 0.008 0.0050 6 650 650 0 0 200.254 200.263 -0.009 0.0045 7 560 560 0 0 97.192 97.195 -0.003 0.0031 8 540 540 0 0 -7.786 -7.771 -0.015 0.1927 9 830 830 0 0 18.124 18.132 -0.008 0.0441 10 1000 1000 0 0 73.603 73.594 0.009 0.0122 Table 22. Comparison of the active power and reactive power for the 10 generators in the IEEE 39-bus model between the solution provided by PSS®E and SAInt. The indicator “Delta” represents the difference between the PSS®E value and SAInt value. The indicator “Delta in %” reports in percentage the value of “Delta” over the value of PSS®E. Numerical precision is set to three decimal digits for the original values. Reported values may use from three to four decimal digits. Node number Voltage angle Node number Voltage angle PSS®E [degree] SAInt [degree] Delta [degree] Delta in % PSS®E [degree] SAInt [degree] Delta [degree] Delta in % 1 -8.369 -8.369 0 0 21 -4.080 -4.079 0 0 2 -5.772 -5.772 0 0 22 0.252 0.252 0 0 3 -8.608 -8.608 0 0 23 -0.018 -0.018 0 0 4 -9.512 -9.512 0 0 24 -6.294 -6.294 0 0 5 -8.432 -8.432 0.0001 -0.0012 25 -4.379 -4.379 0 0 6 -7.734 -7.734 0 0 26 -5.594 -5.594 0 0 7 -9.907 -9.907 0 0 27 -7.581 -7.581 0 0 8 -10.403 -10.403 0.0001 -0.0010 28 -2.091 -2.091 0 0
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 86 Node number Voltage angle Node number Voltage angle PSS®E [degree] SAInt [degree] Delta [degree] Delta in % PSS®E [degree] SAInt [degree] Delta [degree] Delta in % 9 -10.165 -10.165 0 0 29 0.662 0.662 0 0 10 -5.306 -5.306 0 0 30 -3.360 -3.360 0 0 11 -6.132 -6.132 0 0 31 0 0 0 12 -6.118 -6.118 0 0 32 2.658 2.658 0 0 13 -5.999 -5.999 0 0 33 3.995 3.995 0 0 14 -7.610 -7.610 0 0 34 2.981 2.981 0 0 15 -7.844 -7.844 0.0001 -0.0013 35 5.208 5.208 -0.0001 -0.0019 16 -6.374 -6.374 0 0 36 7.821 7.821 0 0 17 -7.421 -7.421 0 0 37 2.393 2.393 0 0 18 -8.299 -8.299 0 0 38 7.716 7.716 0 0 19 -1.221 -1.221 0 0 39 -9.935 -9.935 0 0 20 -2.210 -2.210 0 0 Table 23. Comparison of the voltage angle at the nodal level in the IEEE 39-bus model between the solution provided by PSS®E and SAInt. The indicator “Delta” represents the difference between the PSS®E value and SAInt value. The indicator “Delta in %” reports in percentage the value of “Delta” over the value of PSS®E. Numerical precision is set to four decimal digits for the original values. Reported values may use from three to four decimal digits. Node number Voltage magnitude [per unit] Node number Voltage magnitude [per unit] PSS®E [p.u] SAInt [p.u] Delta [p.u] Delta in % PSS®E [p.u] SAInt [p.u] Delta [p.u] Delta in % 1 1.049 1.049 0.00001 0.0010 21 1.034 1.034 0 0 2 1.052 1.052 0.00001 0.0010 22 1.051 1.051 0 0 3 1.036 1.036 0.00001 0.0010 23 1.046 1.046 0 0 4 1.017 1.017 0.00001 0.0010 24 1.041 1.041 0 0 5 1.014 1.014 0 0 25 1.060 1.060 0 0 6 1.011 1.011 0 0 26 1.055 1.055 0.00001 0.0009 7 1.002 1.002 0 0 27 1.041 1.041 0 0 8 1.002 1.002 0.00001 0.0010 28 1.052 1.052 0.00001 0.0010 9 1.031 1.031 0 0 29 1.051 1.051 0 0 10 1.021 1.021 0.00001 0.0010 30 1.048 1.048 0 0 11 1.017 1.017 0 0 31 0.982 0.982 0 0 12 1.005 1.005 0 0 32 0.983 0.983 0 0 13 1.020 1.020 0 0 33 0.997 0.997 0 0 14 1.020 1.020 0.00001 0.0010 34 1.012 1.012 0 0 15 1.020 1.020 0.00001 0.0010 35 1.049 1.049 0 0 16 1.035 1.035 0 0 36 1.064 1.064 0 0 17 1.038 1.038 0 0 37 1.028 1.028 0 0 18 1.036 1.036 0 0 38 1.027 1.027 0 0 19 1.051 1.051 0 0 39 1.030 1.030 0 0 20 0.992 0.992 0 0 Table 24. Comparison of the voltage magnitude (per unit) at the nodal level in the IEEE 39-bus model between the solution provided by PSS®E and SAInt. The indicator “Delta” represents the difference between the PSS®E value and SAInt value. The indicator “Delta in %” reports in percentage the value of “Delta” over the value of PSS®E. Numerical precision is set to five decimal digits for the original values. Reported values may use from three to five decimal digits.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 87 11.1.2 Preliminary Model for the EnviPark Electric Network As an example of the application of SAInt modelling capabilities to an electric system, we have created a preliminary and simplified model of the EnviPark main distribution network, along with its hydropower and photovoltaic generators. The example is based on a virtual hourly scenario over two days, which is using fictional data, and it is used as a proof of concept. Demand and production values are in the range of the corresponding real demands and production profiles for the hydroelectric and PV generators. Figure 10 shows an example of the results for the active power used at one of the demand points during the 24-hour simulation. Figure 11 shows the modelled behaviours of the active power at the interconnection point with the main external distribution grid (A), the hydro-generator (B), and the photovoltaic facility (C). In this system, the hydropower is exported to the external grid, and only the power generated by the solar panels contributes to the self-consumption. Figure 12 shows the electric model developed for the case study of the prototype EnviPark complex to be used for a quasi-dynamic ACPF hourly simulation over the period February 1st 00:00 to February 3rd 00:00. The model Explorer Window on the left describes the general structure of the model. There are 21 nodes, 20 branches (17 electric lines and 3 transformers), 14 demands, one generic generator, one hydropower generator, and one solar generator. The PV object uses solar data from the NREL database for the selected period rescaled to match the daily values collected at EnviPark for those days. The quasi-dynamic ACPF simulation has a 48-hour span, with a time step of 15 minutes. In the Map View (centre), the prototype model is displayed on top of Google Maps with nodes indicating the active power and lines indicating the base voltage per unit. The Property Editor shows details of the electric demand “A2_OFFICE” which is selected in the image and next to the white arrow.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 88 Figure 10. An example of the hourly dynamic of the total active power of one of the demands in the electric model (i.e., demand “A2_OFFICE”) for the ACPF scenario for the EnviPark model during the simulated period. The example is based on a virtual scenario using fictional data matching the range of the real demand and it is used as a proof of concept. (A) (B) (C) Figure 11. Active power extracted from the external transmission line (A) and produced by the hydropower facility (B) or the photovoltaic panels (C) in the EnviPark complex during the simulated period. The hydropower and PV data are actual profiles used as input to the model. The external transmission line data are one of the results of the ACPF simulation. The example is based on a virtual scenario using fictional data and is used as a proof of concept.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 89 Figure 12. An example of the SAInt interface showing: the Model Explorer with the main objects making up the model (see numbers in brackets for the count of such objects), the Map Window with a prototype electric network of EnviPark on top of Google Map, with nodes and lines indicating the base voltage, and the Property Editor showing details of the electric demand “A2_OFFICE”. Active power values are for the solved steady state ACPF simulation used as initialisation state for the quasidynamic ACPF simulation.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 96 Figure 15. Example of a stochastic profile used to define the hourly dynamic of a demand point in the model of the Sonnenplatz network. On the right the numerical region used to generate the profile, with median value and standard deviation for the chosen probability distribution (i.e., uniform). The example is based on a virtual scenario using fictional data, and it is used as a proof of concept. Figure 16. Examples of the results for the supplied heat (in kW) and the mass flow (in kg/s) of the supply point in the dynamic scenario for the model of the Sonnenplatz network for the reference day of 14-02-2023. As expected, they have the same shape, but different units for the y-axis. The example is based on a virtual scenario using fictional data, and it is used as a proof of concept.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 97 Figure 17. Example of the SAInt interface showing the mass flow at node level and heat loss on the hot side at pipeline level for the simulated day of 14-02-2023 for the thermal model for the case study of Sonnenplatz. The chart shows the thermal and hydraulic view for the demand in the southern part of the model (i.e., see the selected label). The example is based on a virtual scenario using fictional data, and it is used as a proof of concept.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 98 11.3 Electric-Thermal Co-Simulation Example 11.3.1 Preliminary model of the EnviPark combined electric and thermal networks As an example, to showcase the application of SAInt modelling capabilities to a quasi-dynamic cosimulation of thermal and electric networks, we combine a prototype version of the thermal and electric systems of the EnviPark complex and assess the case of the conversion of one heat demand to electric demand. We explore the case of the full electrification of the heat load on the DH network by means of an electric heat pump and check that the electric system is able to cope with the new load. We consider the case of a heat demand associated with a laboratory located at node “EDEM.UFFICIO2” linked to the thermal demand “HDEM. A2_UFFICI”. For this example, we assume a constant coefficient of performance for a heat pump equal to 3 (when operated in the heating mode). We do not consider any other conversion factor between technologies. We do not consider any other electric demand (e.g., we exclude the load associated with the operation of the pumps of the thermal system in the example). The example is based on a virtual scenario using fictional data, and it is used as a proof of concept to showcase capabilities. We explore a quasi-dynamic scenario operating over two days with a time step of 15 minutes. Figure 18 shows the results of the first stage of the quasi-dynamic co-simulation. We set the initial state of the electric system by considering the networks working in isolation (i.e., no active links with the thermal system). The picture describes the active power extracted from the external transmission grid and the existing electric demands at the node where the coupling point “A2_Uffici (electric)” (electric side) / “A2_UFFICI” (thermal side) link the two systems. During this step, the electric demands modelling the heat loads (i.e., the demand “A2_UFFICI”) has a value of zero kW. This step prepares the electric system to incorporate the heat demand and provides a sanity check of the operability of the system.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 99 Figure 18. Stage one of the quasi-dynamic co-simulation of the thermal-electric system for the EnviPark complex (simulation time 12:00 a.m. of 01.02.2020). The picture shows the electric grid, and the active power extracted from the external transmission line at the node “CENTRALE_TERMICA_MW” along with the electric demand at the coupling point “A2_Uffici (electric)” (electric side) / “A2_UFFICI” (thermal side). The arrow in the centre indicates the electric line on which the new extra thermal load will be activated. In this step, the electric system is operated in isolation, and the equivalent thermal load is assumed to be zero.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 100 Figure 19 shows the results of the second stage of the co-simulation. We set the initial state of the thermal system by still considering the networks working in isolation (i.e., no active links with the electric system). The picture describes the total heat delivered by the supply point and the heat required at the coupling point that will be electrified (i.e., the demands “A2_UFFICI). This stage defines the boundary conditions for a new electric run where the heat load at the coupling point is used as input. In this way, the modelled dynamic of the thermal system is used as input for a second electric simulation. Still, at this stage, both systems are considered in isolation. Figure 20 shows the last stage of the co-simulation. In this stage, the electric scenario is run by incorporating the constraint set by the heat demand. This is achieved by specifying the value of the electric event by using an expression that points to the value of the heat demand in the thermal system and uses the coefficient of performance for the ideal “heat pump” for each time step of the simulation. In this way, the new electric run can incorporate the new electrified heat demand as extra constraints. Next, the thermal scenario is executed again but without the electrified load. By looking at the grid supply points, it is clear how the new electric heat demand is reflected in an increased extraction from the external grid (e.g., from 120.0 to 263.5 kW at 12:00 a.m. of 01.02.2020) and how the heat supply has decreased (e.g., from 2662.0 to 2447.0 kW at 12:00 a.m. of 01.02.2020). Adding the newly converted heat load creates problems in the electric branch of the system up to the heat pump. For example, the two nodes defining the electric line LV_3 (see the arrows in Figure 18 and Figure 20) have a shift in voltage magnitude (per unit) from 0.940 to 0.720 p.u. for the starting node on the left and from 0.940 to 0.640 p.u. for the ending node on the right. This points to a situation where we need to improve the lines to secure the addition of new loads. Finally, Figure 21 shows the comparison of the power extracted from the electric node ENO.A2OFFICE with (A) and without (C) the electrified demand on or off. The newly converted heat load is shown in B.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 101 Figure 19 Stage two of the quasi-dynamic co-simulation of the thermal-electric network for the EnviPark complex (simulation time 12:00 a.m. of 01.02.2020). The picture shows the thermal grid and the heat extracted from the external district heating system at the node “CENTRALE_TERMICA” along with the heat demand at the coupling point “A2_Uffici (electric)” (electric side) / “A2_UFFICI” (thermal side). In this step, the thermal system is operated in isolation, and the thermal load of the heat pump is assumed to be provided by the external district heating system.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 102 Figure 20. Stage three of the quasi-dynamic co-simulation of the thermal-electric network for the EnviPark complex (simulation time 12:00 a.m. of 01.02.2020). The picture shows the active power on the electric side (purple-red colour legend for electric lines) and the total thermal power and the mass flow on the thermal side (yellow-green colour legend for thermal pipelines) at the coupling point “A2_Uffici (electric)” (electric side) / “A2_UFFICI” (thermal side). The thermal load from stage two is used as electric demand and removed from the thermal load. The electric and thermal networks are updated and operated at the same time. The arrow in the centre indicates the electric line with the new extra thermal load with low voltage per unit values. The background map is changed to Bings Map, “canvas grey” to facilitate the reader.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 103 (A) (B) (C) Figure 21. Change in the total active power extracted from the node where the coupling point “A2_Uffici (electric)” (electric side) / “A2_UFFICI” (thermal side) is off (A, power demand of the external) and on (C, power demand of the node). The active power demand from the newly converted heat load is shown in B. The example is based on a virtual scenario using fictional data and is used as a proof of concept.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 104 12 Conclusions Within the context of the HYPERGRYD project, encoord GmbH has extended the capabilities of the energy modelling platform SAInt by incorporating basic thermal objects, a solver to address steady state and quasi-dynamic problems, and the possibility of interacting with the existing gas and electric capabilities for the same type of simulation scenarios (i.e., steady state and (quasi-)dynamic). The report provides an overview of the capabilities of the software platform SAInt and focuses on the new and extended aspects of thermal simulation and electric-thermal co-simulation. We briefly describe the mathematical models behind the software implementation of the functionalities. We provide some examples of applications of SAInt to an ACPF simulation, to a steady state and quasidynamic thermal simulation, and to a quasi-dynamic thermal-electric co-simulation. Finally, we start to explore the use of the methods and simulation approaches by using prototype networks from the case study systems of the living labs of the project’s partners EnviPark and Sonnenplatz. By means of two cases, we describe examples of analysis of testbed systems to validate the computational capabilities of SAInt. By benchmarking SAInt’s results against other industry-standard software products, we show how SAInt matches, in terms of the accuracy of the results, other simulation environments (with possible numerical differences not more significant than 10-2). The thermal functionalities and the co-simulation capabilities are also available through SAInt API, exposing such a set of capabilities to external software platforms and frameworks. This report only touches upon the structure of the API and does not describe the calls to its entry points, but it is the SAInt API (i.e., SAInt without the graphical user interface) working in the simulation platform created in the HYPERGRYD project by WP4 (in tasks 4.2, 4.3, and 4.5) and WP5 (in tasks 5.4 and 5.5). We opted to summarise SAInt and its extended simulation capabilities using the more intuitive graphical user interface instead of a rather technical and “oriented to an audience of primarly developers” approach. The HYPERGRYD project has provided a unique opportunity to create and extend a tool which allows us to physically simulate thermal and electric systems (and add gas systems) within the same platform.
D3.8 Description and report of developed multi-physics SAInt modelling tool for network coupling and optimization. Final version. 105 13 References Athay, T., Podmore, R., & Virmani, S. (1979). A Practical Method for the Direct Analysis of Transient Stability. IEEE Transactions on Power Apparatus and Systems, PAS-98(2), 573 - 583. doi:10.1109/TPAS.1979.319407 Derviškadić, A., Zuo, Y., Frigo, G., & Paolone, M. (2018). Under Frequency Load Shedding based on PMU Estimates of Frequency and ROCOF. 2018 IEEE PES Innovative Smart Grid Technologies Conference Europe (ISGT-Europe), (pp. 1 - 6). Sarajevo, Bosnia and Herzegovina. doi:10.1109/ISGTEurope.2018.8571481 Directorate-General for Energy, European Commission. (2019). Clean energy for all Europeans. Euroheat and Power 14. Erickson, J. (2019). Algorithms. SBN: 978-1-792-64483-2 (paperback). Retrieved from http://jeffe.cs.illinois.edu/teaching/algorithmsI Frederiksen, S., & Werner, S. (2013). District Heating & Cooling. Studentlitteratur AB, p. 586: ISBN-13: 978-9144085302. Hass, J. R., Weir, M. D., & Thomas, G. B. (2024). University Calculus: Early Transcendentals. LibreTexts. Retrieved from https://math.libretexts.org/Bookshelves/Calculus Jasmine Ramsebner, R. H. (2021). The sector coupling concept: A critical review. WIREs Energy and Environment, 10(4), 1 - 27. Klinkel, K. (2020). Combined Simulation of District Heating and Electrical Power Networks, A thesis presented for the degree of Master of Science in Sustainable Energy Technology, Mechanical Engineering. Eindhoven, the Netherland: Technische Universiteit Eindhoven. Retrieved from https://pure.tue.nl/ws/portalfiles/portal/165859067/1508105_K.G.Klinkel.pdf Liu, X. (2013). Combined Analysis of Electricity and Heat Networks. Institute of Energy. Cardiff: Cardiff University. Retrieved August 5, 2024, from https://orca.cardiff.ac.uk/id/eprint/57830 Liu, X., Wu, J., Jenkins, N., & Bagdanavicius, A. (2016). Combined analysis of electricity and heat networks. Applied Energy, 1238 - 1250. doi:10.1016/j.apenergy.2015.01.102 Lohmeier, D., Cronbach, D., Drauz, S., Braun, M., & Kneiske, T. (2020). Pandapipes: An Open-Source Piping Grid Calculation Package for Multi-Energy Grid Simulations. Sustainability, 12, 9899. doi:10.3390/su12239899 Lund, H., Østergaard, P., Connolly, D., & Mathiesen, B. (2017). Smart energy and smart energy systems. Energy, 137, 556 – 565. Owusu, P. A., & Asumadu-Sarkodie, S. (2016). A review of renewable energy sources, sustainability issues and climate change mitigation. Cogent Engineering, 3(1), 1167990.