ENTSO-E Transparency Stakeholder Expert Group Meeting - February 2013
Agenda included discussions on terms of reference, manual of procedures, project monitoring, and feedback on data provider criteria. Requests were made for comments on proposals before the next meeting. Draft minutes and detailed descriptions were to be reviewed and comments submitted. The meeting aimed at finalizing decisions and actions for the ENTSO-E Transparency platform.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
ENTSO-E Transparency Stakeholder Expert Group Meeting 2 28 February 2013
Agenda Alain Taccoen Welcome and Introduction 10:30 10:40 WGMIT Convenor Peter Campbell Terms of Reference Approval 10:40 10:50 ENTSO-E Transparency Advisor Draft Manual of Procedures Andy Spiceley 10:50 11:20 overview, scope, aims & readership IT Project manager Comments on detailed descriptions Alain Taccoen 11:20 12:30 Load, Generation WGMIT Convenor - Lunch 12:30 13:30 Alain Taccoen Comments on detailed descriptions continued 13:30 14:30 WGMIT Convenor Transmission, Balancing Andy Spiceley/Dalius Sulga Feedback on data provider technical & operational criteria and Local 14:30 14:50 IT Project manager/Platform senior advisor Project Monitoring Coffee Break 14:50 15:05 Peter Campbell Feedback on Production types 15:05 15:25 ENTSO-E Transparency Advisor Alain Taccoen Conclusions, Actions and Next steps 15:25 15:45 WGMIT Convenor A.O.B All 15:45 16:00 2 End of Meeting 16:00
TSEG meeting 1 follow up.. Sent on 4 Feb: The draft minutes comment before Wednesday 13 February. (see next slide) The draft detailed descriptions and comment sheet The updated ToR as discussed for final approval. Asked for proposals for: Art.5-1-c, Technical and operational criteria which data providers would need to fulfil when providing data to the central information transparency platform Art.5-1-d, Appropriate classification of production types . We would like to ask for you to return your comments in the Excel sheet and proposals before 22nd February, 12 noon to peter.campbell@entsoe.eu which will then be consolidated and discussed at the next TSEG meeting on 28th February in Brussels. Input received after 22 February will not be considered. All documentation will be published at https://www.entsoe.eu/data/entso-e-transparency- platform/ 3
Manual of Procedures: Terms of Reference Jean-Noel MARQUET (EDF) Concerning the 1st TSEG meeting draft minutes, I suggest to add these items ( 4) : "In the morning, the Convenor has mentioned the possibility to disclosure additional information using "free text" : that is a interesting idea". "It is useful to have a cost/benefit approach to any further specification" Marcus Mittendorf (EEX) (Group comments) add: No requirement to send older data before EMFIP is established A list on the ENTSO-E transparency platform of who complies with the data provider requirements (including TSOs) should be made to have the same level playing field for everybody, Modify the sentence: ENTSO-E remains the sole party responsible for the development of the central information transparency platform and manual of procedures and shall not be bound to accept all suggestions provided by stakeholders. If a suggestion is rejected, ENTSO-E shall endeavor to provide an explanation. ENTSO-E asks for approval of the ToR 5
Draft Manual of Procedures Overview, scope, aims and readership
Overview Readership: Data owners Data providers Data consumers Purpose: To provide, either directly or by reference: All information that would be required for a data provider to develop & operate a system to submit data to the platform in accordance with the legislation and with ENTSO-E system definitions All information that would be required to develop & operate a system to extract data from the platform 7
Scope of the manual of procedures In scope: details and format of the data to be published per Art 4 of the regulation Anything that a 3rd party would need to know to submit or extract such data to or from the platform Not in scope: Matters internal to ENTSO-E or its suppliers Material that would be considered confidential to ENTSO- E or its members 8
Structure The aim is that the handbook does not duplicate material published elsewhere. If such material is required it is included by reference only. For example reference to definitions in the Regulation on submission and publication of data in electricity markets and in Network Codes, existing standards documentation. The handbook will be constructed as an on-line resource (which facilitates the cross-referencing of material) but a pdf reference version can be exported for download. Only the on-line copy will be definitive. 9
Article 5 requirements: ENTSO-E shall develop a manual specifying Details and format of the submission of data Standardised ways and formats of data communication and exchange between concerned parties Technical and operational criteria for providing data Appropriate classification of production types To be developed under open and transparent consultation with stakeholders To be made available to the public To be updated when necessary To be submitted to ACER who will provide an opinion 10
Details and format of the submission of data Detailed data descriptions (next topic for today) Implementation Guides: to be produced for each business domain under the Regulation (Load, Generation etc.) Implementation Guides Provide XML schemas for encoding of the data Are developed by the ENTSO-E WG EDI already in existence for the present www.entsoe.net platform Currently published through the EDI library on www.entsoe.eu 11
Standardised ways and formats of data communication and exchange Connection and submission methods: Web Services Market Data Exchange System (MADES) Secure ftp Payload expected to be XML documents compliant with the XML schemas of the relevant Implementation Guide 12
Other topics Management of standing (reference and master) data Establish data ownership & accountabilities Devolve responsibility and control as far as possible to data owners Establish clear procedures for distribution of updates to standing data Support routes (resolution of technical and business queries) 13
Comments on detailed descriptions
Load Total load per bidding zone per market time unit (6.1.a, 6.2.a) Actual total load Net generation: Net or gross: net is suitable but use gross if high accuracy Real-time measures (SCADA) + estimated dispersed generation Real-time measurements are enough. No additional measures after H+1 Storage resources: Only significant storage resources to be provided H+1 is obliged by the Regulation. In case of absence of measures, estimation is needed. 15
Load Day-ahead forecast of the total load per market time unit (6.1.b, 6.2.b) Market time unit harmonization not needed as data is per bidding zone Replacement: The total load refers to the same definition as in Article 6.1.a. ; by The day-ahead forecast is calculated (estimated) on the historic load profile on similar days, taking into account the variables that affect electricity demand, such as weather conditions, climate and socioeconomic factors Need for national agreements between TSOs and DSOs regarding procurement of information to perform the forecast by TSOs. Forecasts can be updated is weather conditions changes. 16
Load Week-ahead total load forecast per day (6.1.c, 6.2.c) Replacement: The total load refers to the same definition as in Article 6.1.a. ; by The week-ahead forecast is calculated (estimated) on the historic load profile on similar days, taking into account the variables that affect electricity demand, such as weather conditions, climate and socioeconomic factors Need for national agreements between TSOs and DSOs regarding procurement of information to perform the forecast by TSOs. Forecasts can be updated is weather conditions changes. 17
Load Month-ahead total load forecast per week (6.1.d, 6.2.d) Replacement: The total load refers to the same definition as in Article 6.1.a. ; by The month-ahead forecast is calculated (estimated) on the historic load profile on similar days. Need for national agreements between TSOs and DSOs regarding procurement of information to perform the forecast by TSOs. Forecasts are not influenced by weather conditions as it is long- term forecast. 18
Load Year-ahead total load forecast per week (6.1.e, 6.2.e) Replacement: The total load refers to the same definition as in Article 6.1.a. ; by The year-ahead forecast is calculated (estimated) on the historic load profile on similar days. Rolling year consistency. Need for national agreements between TSOs and DSOs regarding procurement of information to perform the forecast by TSOs. Forecasts are not influenced by weather conditions as it is long- term forecast. 19
Load Planned unavailability of consumption units and Actual availability of consumption units (7.1.a,b, 7.2, 7.3) Reason for the unavailability have to be clearly defined. To be checked with generation unavailability. Decision time reporting seems to be needed for monitoring purposes under Transparency Regulation and REMIT. Replacement of DP by Data Provider Need for national agreements between TSOs, DSOs and consumers to report unavailability. Immediately publication: EMFIP will support it, being immediately understood in terms of information systems (probably seconds). 20
Load Year-ahead forecast margin (8.1, 8.2) Deletion of "Total load is defined as in Section 2. Only one value will be provided per year. TSOs are also Primary Owner of the calculated data. Updates of this data: not clear. To be discussed. No, as it is a year-ahead forecast (recommended). Yes, as it can change during the year. 21
Generation - Objective of the document Main points raised in the comments received need to be discussed General comments UMM and unavailabilities Production type Criteria for data provider Master data Kind of filing rate of water reservoir and hydro storage plant to be reported 22
Generation General Comments Comments on the content and the wording of the regulation No modification of the regulation is possible. All the comments made on the regulation are rejected. Location 2 kind of proposal for describing the location: - GPS coordinates - Country, Town : lower level of precision 2 questions to define the relevant level of description: - What is the additional value for the market to know exactly the location of the generation/production unit? - Is there strategic defence restriction which apply for this information ? =>To be discussed 23
Generation - UMM and Unavailabilities List of reason for unavailabilities A Predefined was first drafted in the data description: maintenance failure (permitted for changes in actual availability only) shutdown (permitted for Consumption, Generation and Production Units only) other Additional list suggested: Outage, External factors, redispatch to be completed => to be discussed Change in actual availabilities and unplanned unavailabilities in the same document In the data description ENTSO-E already suggested to have only one document. If the actual unavailability have been planned and already reported with the correct available capacity, it s not necessary to deliver again the data. But it is still in discussion inside ENTSO-E => To be discussed 24
Generation UMM and Unavailabilities Free Text for UMM 2 different requirement for the UMM : REMIT and the draft Transparency regulation 2 proposal on 2 different levels could be used for publishing open comments 1) On the unavalaibilities required by the regulation: The text is related to an outage with a specific period covered 2) Outside any outage The text is an open comment not linked directly with an outage. =>To be discussed No aggregation for unavailabilities It was suggested to make aggregation on the unavailabilities (per control area or per production type) This aggregation is not required by the regulation. => Comment rejected 25
Generation - UMM and Unavailabilities Decision taken to be defined? In the regulation a planned unavailability is published as soon as possible, but no later than one hour after the decision regarding the planned unavailability is made. Some comments suggested to define the decision Is it necessary to define clearly what is a decision? =>To be discussed Example of interval pattern mode In the data description it is mentioned that In some cases, if an unavailability is repeated several times it could be described with an interval pattern mode. For an outage on a generation unit which is unavailable every Friday for one year, This outage could be described in only one document, The period covered by the document will be one year, and the unavailability of every friday will be described. It will be clearly explained in the BRS and IG. =>To be discussion when the BRS will be presented 26
Production Type Proposal to replace production type by fuel type: rejected No modification of the regulation is possible. All the comments made on the regulation are rejected. Proposal received for the production types To be discussed Primary owner of data Owner of production units or operators of production units? =>To be discussed 27
Criteria for being data provider Question raised in the comment Data provider have to belong to the area of the data concerned => to be discussed 28
Master Data Which master data to be used in EMFIP One comment raised that the production name , the install capacity for a generation unit is not needed to be reported each time if it is a master data This question is still open in ENTSO-E. It involves lots of questions: - legal issues : who is responsible for the data, What kind of validation is required from EMFIP - how to manage the data, - if some master data are not previously recorded in EMFIP, some data sent could be rejected - To be discussed when the BRS will be introduced 29
Kind of filing rate of water reservoir and hydro storage plant to be reported Question raised in the comment What kind of water reservoir and hydro storage to be reported Proposal from Eurelectric: refer to UNIPED definition 30
Transmission section Article Comments Answers from experts Group general comment: The used term definition in the Entso-e network code should be as well the basis for this term definition OK we will align the data description with Network code as much as possible General Status of unavailability of transmission assets It is meant here the status of the information/message and not the status of the unavailability. The note in the definition is not clear. What does it mean? terms => definition will be clarified Another status, for instance forced could be added. For all articles referring to reason for the unavailability (i.e. consumption, generation), the same list should be used. => to be clarified to add in the terms section terms ok it will be done Remedial actions: As defined in the draft CACM NC: means a measure activated by SOs, manually or automatically, that relieves or can relieve Physical Congestions. They can be applied pre-fault or post- fault and may involve costs. ok it will be done terms 31
Transmission section Article Comments Answers from experts Group The publication time will be published but decision time has low added value for the market. Data provider is responsible to deliver the information on time. Statistics could be calculated on a year basis about the level playing field of data providers. Unavailability of transmission infrastructure 10.1 a,b,c In order to follow that the requirement to publish within one hour is fulfilled, the decision time and publication time must be submitted. Planned unavailability of offshore grid infrastructure is missing in the Regulation requirements !? 10.1 Yes, not required by the regulation As set in the terms part that will work only for NTC capacity calculation approach. How the FB calculation would be impacted? reasons for the unavailability For the time being It was decided to wait regarding the FB publications as there are no current implementation in Europe 10.1 Are the reasons the ones that are set in the term part "Reason for planned unavailability or change in actual availability"? ok it will be done 10.1 a,b,c Reference to "terms" part should be added. 32
Transmission section Article Comments Answers from experts Group Note: in case of unplanned outage , there cannot be status canceled No, it is not the meaning of the "status . 10.1.b The definition of "status of unavailability of transmission asset should foreseen a status for this unplanned outage. Why not using the term "forced? If due to the technical reasons a transfer capacity for a given bidding zone is calculated for the whole technical profile of this bidding zone, then the transfer capacity between bidding zones means the transfer capacity on the technical profile The status related to the information/message and not the status of the unavailability There are two options for TSOs either NTC values or technical profiles 11.1 Not sure the meaning is clear here. TSO has to provide the NTC available per border and per direction. A smaller granularity means that the submission could be done with a more accurate information, f.i. a value per day even if it is request per week submission of the data can be done with smaller granularity What does that mean? NTC variation within a month? And/or specifying value for base peak off peak product? The term granularity should be explained. 11.2 We will align the wording. 33
Transmission section Article Comments Answers from experts Group BRS = Business Requirements Specifications for the transparency platform (EMFIP). It will be removed from the doc. 11.2 BRS should be defined A yearly offered capacity may include some sub periods where the value may differ. A sub-period is a time interval within the whole period (Eg a month is a sub-period in a year) 11.2 To what the term "sub periods" is referring to? The sub period should be explained. intraday capacity limit value taking into account the technical capacity of the interconnector and the security constraints of the grid. It will be added in the document intraday transfer limits 11.3 To be defined in the "terms"section ASAP without undue delay. Regulation has been modified several times. It will be changed. 11.3 The regulation foreseen "not later than one hour"" Is this wording foreseen an improvement? Market Committee to decide on the way of creating/publishing this report internal ENTSOE comment, it will be removed 11.4 Which market committee? The report should be publicly available. 34
Transmission section Article Comments Answers from experts Group all possible measures that could be implemented to increase the offered transfer capacity, together with their estimated costs of all possible measures. 11.4 There is no harmonization on that topic The detailed descriptions should develop on what are the possible measures. Total capacity nominated means aggregated capacity nominated,by market participants from time horizons (Y, M, W, D, ID) corresponding to explicit allocations , agreed between the TSOs (i.e. where a TSO-TSO matching process applies) and confirmed to the market. ok we will remove the TSO common wording and the text will be clarified 12.1.b TSO-TSO matching process should be explained It should be specified as soon as the nomination has been approved/validated by both TSO? 35
Transmission section Article Comments Answers from experts Group Amount of MW nominated capacity per border and direction CACM network code foresees both options (per border or in net position) 12.1.b This option per border should be used, more useful information. The regulation as well as the data description states that the information on Day-Ahead Prices should be published no later than one hour after gate closure. The gate closure is a set time but the publication time for the outcome of price calculation is not. In some rare situations the price calculation may take longer time than expected and this will affect the time for when it s sent to the platform. This should be taken in to account in the restrictions of publication deadline for ENTSO-E. Is operational period the same as operating period? This period should be defined in the "terms" section When a publication deadline is reached it will not block a publication afterwards. The publication deadline is a monitoring feature which will send alarms to the data provider if the deadline is passed 12.1.d 12.1.g ok it will be done 36
Transmission section Article Comments Answers from experts Group Information relating to countertrading per market time unit, specifying: The comments field should not be used for duration. A Period could be added 13.1.b -comments Comment should specify the period of countertrading action? For their control areas TSOs shall provide to ENTSO-E for publication a monthly summary report detailing the costs incurred to them separately for measures taken as referred to in paragraph 1(a), paragraph 1(b) and any other remedial action. An Explanation on the costs will be given but not a specific methodology 13.1.c Is an explanation on how these costs are calculated will be provided? An explanation on the methodology to calculate the cost should be published in the summary report. Publication in M+3 Regulation has been modified several times. It will be changed 13.1.c The regulation foreseen a publication no later than on month after the end of the referred month 37
Balancing Finalised Balancing Network Code will be used as basis for terms and definition. Rules on balancing should be published by TSOs. All balancing data should be sent by TSOs or Market Operators (primary owners). Market participants (generators, consumers) don t have to send such data. Bilateral balancing contracts should be handled the same way as other balancing contracts. According to the regulation, cross control area balancing and international assistance between TSOs shouldn t be distinguished only under point 17.1.j and 17.2.i 38
Feedback on data provider technical and operational criteria
Feedback on data provider technical and operational criteria (1) Technical criteria for data providers: Communication shall be done by using MADES, web services, SFTP (reference to the detail descriptions) Information exchange must be done in accordance with formats defined in Implementation Guide (EDI library) Data provider should be capable to resend data 41
Feedback on data provider technical and operational criteria (1) Operational criteria for data providers: Approval by local TSO is needed Prequalification period is recommended. Prequalification should be done by using EMFIP test platform Audit by local TSO Communication in English Data providers and TSOs should nominate Single Point of Contact (SPoC) for all data related issues. Market participants should collaborate with TSO in defining data providers for EMFIP in a way to ensure cost efficiency, optimize data flow, avoid duplication of tasks and data flows. Data providers should provide data for substantial (not less than1/3) part of the local market. The number of data providers for EMFIP should not exceed 200 (this 200 should be proved in The Proposal concerning the operation of the central information transparency platform and the associated costs ). Generation units, production units and consumption units should send data to the EMFIP via the local TSO or other data provider approved by the local TSO. The number of data providers to the EMFIP shall be limited and optimised. 42
Monitoring of Local Projects Data providers ENTSO-E collects information about Local Projects via TSOs Local projects on Data provider side Aggregators Aggregators Aggregators Aggregators Aggregators GenCo s Local Monitoring Dashboard (LMD): Identified Data providers for each Data item; Status of the project on Data provider side; Date, when data is expected to be ready for submission Aggregators Aggregators Aggregators Aggregators Aggregators DSOs Aggregators Aggregators Aggregators Aggregators Aggregators PXs, AOs, CAs SPOCs of TSOs (TPCs) provide necessary info for LMD; New TP Close dialog between TSO and Data provider is needed Aggregators Aggregators Aggregators Aggregators Aggregators TSOs Information flow from Data owner to the New TP has to be defined Aggregators Aggregators Aggregators Aggregators Aggregators Aggregators 43
Feedback on Production types Required in the manual of procedure To be specified by ENTSO-E Reviewed by ACER ERGEG FEDT Guidelines (2010) Thermal power plants Hydro power plants Renewable energy plants Nuclear Reservoir Wind ENTSO-E approach: Our goal is to keep it simple The information must be useful for the market (fuel type vs technology type) Possible use of existing lists or for coherency in other reporting (e.g. statistical reporting, REMIT ) List to be clarified and discussed in further meetings Run-of-river plant Solar Lignite Hard coal (Pump) Storage Other renewable energy Brown coal Tide Gas Oil Waste EC Peat Should not be too detailed but also not too simplistic. Reasonable mixture between generation technology and fuel. E.g. It is not enough to determine that it is a thermal generation. People would want to know whether it is lignite fired, coal fired or gas fired or fuel oil fired. This would have to be combined with the technologies used. Combined cycle, open cycle, boiler, etc. An additional indication of CHP may also be interesting 45
What do existing ENTSO-E publications have? Thermal Nuclear Fossil Lignite Hard coal Gas Oil Mixed fuel Hydro Run of River Storage and pump storage Renewable Non Renewable Other Renewable Wind onshore Wind offshore Solar Biomass Not identifiable Existing data in ENTSO-E statistical publications Not detailed enough?? 46
What standards are already published? EECS Rules Fact Sheet 5 TYPES OF ENERGY INPUTS AND TECHNOLOGIES: Technology TECHNOLOGY Level 1 Description Solar TECHNOLOGY Level 1 Thermal Level 2 Description Unspecified Photovoltaic Level 3 Description Unspecified Unspecified Classic silicon Level 2 Unspecified Combined cycle gas turbine with heat recovery Level 3 Unspecified Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Unspecified Unspecified Unspecified Unspecified Unspecified Steam turbine with back-pressure turbine (open cycle) Thin film Unspecified Unspecified Onshore Offshore Unspecified Unspecified Unspecified Unspecified Concentration Unspecified Steam turbine with condensation turbine (closed cycle) Wind Gas turbine with heat recovery Hydro-electric head installations Unspecified Run-of-river head installation Storage head installation Pure pumped storage head installation Mixed pumped storage head Unspecified Tidal Internal combustion engine Micro-turbine Unspecified Unspecified Unspecified Onshore Offshore Unspecified Onshore Offshore Unspecified Unspecified Marine Stirling engine Fuel cell Wave Steam engine Currents Pressure Organic rankine cycle Nuclear Unspecified Heavy-water reactor Light water reactor Breeder Graphite reactor Unspecified Too detailed? Other 47
What standards are already published? EECS Rules Fact Sheet 5 TYPES OF ENERGY INPUTS AND TECHNOLOGIES: Fuel Type FUEL (or heat source) Level 1 Description Unspecified Renewable FUEL (or heat source) Level 1 Fossil Level 2 Description Unspecified Unspecified Solid Level 3 Description Unspecified Unspecified Municipal waste Industrial and commercial waste Wood Animal fats Biomass from agriculture Unspecified Municipal biodegradable waste Black liquor Pure plant oil Waste plant oil Refined vegetable oil Unspecified Landfill gas Sewage gas Agricultural gas Gas from organic waste digestion Process gas Solar Geothermal Aerothermal Hydrothermal Process heat Level 2 Solid Level 3 Unspecified Hard coal Brown coal Peat Municipal waste Industrial and commercial waste 0 Unspecified Crude oil Natural gas liquids (NGL) Petroleum products Unspecified Natural gas Coal-derived gas Petroleum products Municipal gas plant Process gas Unspecified Process heat Radioactive fuel Liquid Liquid Gaseous Gaseous Heat Nuclear Solid Heat Mechanical source or other Unspecified Too detailed? Wind Hydro & marine Unspecified Unspecified 48
What is required under REMIT? What will be the requirements under REMIT for UMM (outages)? The ACER Guidance notes (2ndedition, 28 Sept) include the following Annex: 49
A balanced approach Fuel type 1 Fuel type 2 Biomass Thermal Unspecified Combined cycle gas turbine with heat recovery Fuel Type Unspecified Hard coal Brown coal/Lignite Peat Municipal waste Industrial and commercial waste Unspecified Crude oil Natural gas liquids (NGL) Petroleum products Gaseous Unspecified Natural gas Coal-derived gas Petroleum products Municipal gas plant Process gas Heat Unspecified Process heat Solid Municipal waste Industrial and commercial waste Wood Animal fats Biomass from agriculture Liquid Unspecified Municipal biodegradable waste Black liquor Pure plant oil Waste plant oil Refined vegetable oil Gaseous Unspecified Landfill gas Sewage gas Agricultural gas Gas from organic waste digestion Unspecified Solid Non CHP CHP Unspecified Steam turbine with back- pressure turbine (open cycle) Unspecified Renewable Unspecified Non CHP CHP Unspecified Solar Unspecified Photovoltaic Liquid Steam turbine with condensation turbine (closed cycle) Unspecified Classic silicon Thin film Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Unspecified Non CHP CHP Concentration Unspecified Onshore Offshore Unspecified Run-of-river head installation Storage head installation Pure pumped storage head installation Mixed pumped storage head Unspecified Tidal Gas turbine with heat recovery Wind Internal combustion engine Hydro-electric head installations Micro-turbine Marine Stirling engine Unspecified Onshore Offshore Unspecified Onshore Offshore Fuel cell Wave Steam engine Currents Pressure Geothermal Aerothermal Hydrothermal Biomass Organic rankine cycle Process heat Unspecified Heavy-water reactor Light water reactor Breeder Graphite reactor 50
