Q&A post go-live
The Nordic CCM project publish questions (and answers to them). Questions during stakeholder meetings are published as part of the meeting notes, available under Stakeholder meeting material. The other questions, for instance by e-mail, are published here. To post new questions, please email ccm@nordic-rcc.net.
For the abbreviations used, please see the List of abbreviations.
Please note that the questions and answers below are arranged from newer to older.
Questions answered in 2024 from 2024-10-29
Explanation to the shadow price randomly switching between AC CNEC and PTC CNEC.
Answer provided 11 December
Between days 29.11. – 01.12., there was two planned outages on Fennoskan with two seemingly different outcomes on the resulting shadowprice. The start of the outages were on a short notice due to weather dependency. First outage was forwarded as an IVA in the domain and the second with a zero-capacity outage in the IGM.
When the IVA was applied on the PTC we see that the shadowprice is assigned only to the PTC due to IVA being clearly the reason for reduced capacity. However, when the outage was done on the IGM, the shadowprice seems to be spiking for the PTC.
The shadowprice was not in fact spiking and was rather being randomly assigned to either the PTC or the allocation constraint. This is because the FB solution does not know whether the limitation is due to the allocation constraint or the PTC CNEC as both of them are present with the same capacity. Therefore, we see shadowprice randomly on either the AC CNEC or the PTC CNEC during the second outage.
Can the TSOs request to recompute the ENTSO-E border flow (i.e. scheduled exchange, commercial flows) to physical border flows, starting from the 29/10, i.e. Nordic DA FB go-live?
Answer provided 6 December
I have a questions regarding F_ref. How can it be higher than F_max? I would guess it has to do with one being calculated implicitly and one not? But that's only a vague guess. From the "simple" definition it sounds like F_max is the cap:
• F_ref reference flows on all CNECs and combined dynamic constraints
• F_max maximum flow on all CNECs and combined dynamic constraints
Answer provided 20 November
Both Fmax and Fref are calculated.
Fmax is calculated based on the current limit provided by TSOs, that can be either temporary or permanent current limit. The specific calculation is Fmax = sqrt(3) * U_average * I_max * PF_avg (where PF _avg is maximum of either 0.95 or the average of the two substation values). Fmax then lays the basis for RAM, RAM = Fmax– FRM– F0 + FRA + AMR– FAAC– IVA.
Fref is the reference flow calculated based on the CGMA NPs multiplied with the z2sPTDFs of the CNEC, to give an estimate of the reference scenario flow on the CNEC. However, the CGMA prognosis does not take the FB limitations into account and there are therefore cases of the CGMA NP prognosis not being a possible market outcome (and Fref being larger than Fmax). The Fref value in itself is not used further, but the CGMA NP lay the basis for our linearization down to the zero scenario and the value of F0.
Is there any official timeline when IDA auctions and continuous market will be under flowbased-domains?
Answer provided 15 November
No, there is no official timeline for FB IDA auctions or continous market yet. However, we are in the process of setting the ID project up right now and news updates will be shared continously on our website, newsletter and the open stakeholder meetings: https://nordic-rcc.net/flow-based/
When the Nordic TSOs plan an outage of a DC cable, e.g. 2 weeks before the operation, what kind of information will the TSOs share with the market participants? What about when two cables will be out of service?
Answer provided 15 November
We’ll publish the outage information on NUCS and via UMMs. In terms of the impact of the outage, we will not publish the updated FB domain at this stage, because it is very a complex process. The TSOs don’t have capabilities, processes or platform to facilitate the publication of updated FB domain. At this stage, we continue using the NTC way of publication, e.g. using the border level capacity reduction to reflect the (HVDC) outages.
Please also be aware of the development of the long-term capacity calculation (LT CC) implementation project, where the TSOs will publish the long-term grid models that capture the outages that are planned cross the period of interest. For example, a planned outage from late January to early March, the monthly grid model of February should already label this outaged element as ‘out of service’, as input to the LT CC. Consequently, the impact of the outage should already have been considered in the result LT FB domain of February.
Can you estimate the impact of an HVDC outage on the grids?
Answer provided 15 November
Without an actual computation of FB CC and MC on an HVDC outage scenario, it is difficult to estimate the impact of the outage. However, please consider running a comparative analysis with and without an HVDC. To be specific, one may look for a market time unit (MTU) of an energy delivery day (EDD) with a HVDC being in ‘outage’ status and its adjacent MTU with the same HVDC being ‘in service’, assuming the grid topology does not change dramatically. By comparing the FB CC and MC results, one may grip some ideas on the impact of an outaged HVDC.
From the operational perspective, sometimes we see that there are UMMs on outages of HVDCs after the publication of the PTDFs for the next day. An example would be 02/11 at 09:40 SN announced that they would limit the capacity on DC cables to DK, DE and UK. Is there an updating process of PTDFs when major outage occurs?
Answer provided 15 November
Process-wise, 09:30 is the publication deadline under normal circumstances. 11:00 is the deadline for extraordinary circumstances. At 09:40, there should be/is still time to do a recalculation of FB CC. One example from last week, Svk got new details close to 11am. The NRCC published the final FB domain at 10:57am.
How to understand the commercial flows and the physical flows?
Answer provided 15 November
Commercial flows being published on the NordPool website refers to the outcome of the so-called ‘FlowDetermination’ method, which is part of the SDAC algorithm, but after the market clearing. In the NTC world, the commercial flows are an optimization outcome using the NTCs as upper bounds and the cost coefficients. In other words, the commercial flows cannot go beyond the NTC limits, but how the commercial flow is distributed on borders depends on the cost coefficient of each border. In the FB world, there are no NTCs on the border level, but net positions on the bidding zone level. The ‘FlowDetermination’ algorithm takes the net positions as the upper bound and distribute the border flows according to the cost coefficients. Consequently, it is possible that the resulting commercial flow of a border is (close to) zero, because its cost coefficient is higher than other borders, i.e. mathematically too expensive to flow on this border. Because the cost coefficient does not reflect properly of the physical reality, e.g. the impedance of the grid, the TSOs do not recommend using the commercial flow in the FB-related computations.
The expected flow after the DA market coupling can be found on the JAO publication, tab ‘Shadow Price and Flow_FB’. Please refer to the publication handbook for reference. https://publicationtool.jao.eu/nordic/Nordic_PublicationHandbook
Can you please help us in understanding the major differences between physical and commercial flows on the following borders after the launch of FB?
NO1>SE3 - apparently physical flow on this very border is allowed but commercially currently we are at 0
NO2>NO1
NO5>NO2
NO3>NO5
Answer provided 13 November
In general, there is a big difference between the physical flow and the commercial flow after flowbased go-live. The physical flow you refer to is the calculated/estimated physical flow based on the PTDFs multiplied with the net position from the market outcome (plus the F_0 flow). This is our best guess on how the physical flow will be in real-time (although we are aware the other markets after the day-ahead results will affect these values). These values are found on JAO.
The commercial flows are Nordpool/EPEX's way of calculating flows based on the net positions, but they don't use PTDFs here. Instead, they use a cost factor that was also in use before flow-based go-live. However, after go-live, we no longer have NTC values to limit the "flow" on the borders, and therefore, the values will be very different from the physical flow. Our recommendation is to not use the commercial flows, as they are not really used anymore with the introduction of flow-based.
How is the System-price being calculated with flow-based?
In the previous methodology, a second optimization would be carried out fixing the external borders and giving infinity internal transfer capacity.
So, how is it now with flow-based? Would you have any material explaining the new methodology?
Answer provided 6 November
The system price in FB will be calculated the same way as the NTC. Please note that the optimization for computing the system price is done by the NordPool, who is also responsible for the optimization.
I would like to verify if the go live for Nordic Flow Based Market coupling for delivery 30th of October 2024 will apply also for the intraday continuous market?
Answer provided 4 November
The intraday capacities (both IDA and continuous market) will not be calculated with the flowbased methodology. They will still be given as NTC-like capacities (border-level). However, to go from flowbased domains in the day-ahead market to NTC-like capacities in the intraday market, we have to translate the flow-based domains. This is done using ATC extraction. Here, we try to maximize the capacity for all borders, while maintaining operational security. So the intraday capacities will change in both IDA and continuous market, but they will not be flowbased-domains.
Answer provided 31 October
Thank you for notifying us regarding the missing values in the csv download. We have sent the details to JAO so that they can implement a fix, after the go-live freeze period. We checked the API download function and that is working as expected.