To execute the Core DA FB capacity calculation process and obtain precise results, correct inputs are required. These inputs are mainly provided by TSOs, RCCs & JAO. After the delivery of the inputs, merging of the data takes place to create a starting point for the whole region.

The main inputs for the FB DA capacity calculation process are:

• Congestion Forecast two days in advance (D2CF Individual Grid Model) provided by each Core TSO:
  • This D2CF Individual Grid Model reflects the TSOs’ best two days ahead prediction of their power system characteristics: generation, load and grid topology and planned outages (maintenances). Each TSO shares 24 predictions, one for every hour of the day. D2CF Individual Grid Models are also used for Switzerland and Italy due to their proximity to the Core region and consequent influence on the Core grid. For other non-Core TSOs, one day in advance congestion forecast models (DACF Individual Grid Model) are used.
  • The D2CF Individual Grid Model is among the most important inputs for the capacity calculation process as it serves as basis for a) the reference flows and b) the PTDFs. Both the reference flows and PTDFs are essential to determine the flow-based domain as such.
• Generation and load shift keys (GLSKs): This input allows to translate a change in a bidding zone net position into a specific change of injection or withdrawal of a generating unit or load (in the CGM). Therefore, the GLSK contains the relation between the change in net position of the market area and the change in output of generation and load units in the same market area.
  • The GLSK is defined by Core TSOs individually based on different strategies. The GLSK nodes and values can vary for every hour.
  • This input is used by the merging operator when a change of net position of a given bidding zone is needed to create the CGM.
  • The GLSK files are also used during the flow-based computation to translate nodal PTDFs to zone to slack (Z2S) PTDFs. Z2S PTDs describe the influence of net position changes on individual CNECs.
  • If this input cannot be provided, a replacement strategy is applied.
• An input defining the Critical Network Element Contingencies (CNECs) and non-costly remedial actions per TSO. This list holds the Critical Network Elements (CNEs) with associated N-1 contingencies (CNECs) per TSO. Furthermore, this input also includes the non-costly remedial actions and monitored network elements (MNECs) used in NRAO.
  • CNECs are grid elements (under N-1 contingency) that TSOs deem relevant for cross-zonal exchanges and are to be considered during capacity calculation
  • CNEs can be overhead lines, cables, or transformers and are defined in both directions (A → B and B ← A)
  • MNECs are additional network elements that are monitored during the NRAO process and cannot be loaded more than a certain threshold. MNECs are not CNECs and cannot limit the flow-based domain.
  • If this input cannot be provided, a replacement strategy kicks.
• External Constraints (ECs) and Allocation Constraints (ACs): constraints provided by some TSOs that impose limits on Core or SDAC net positions respectively for a specific bidding zone.
  • These constraints can be used only in specific cases when operational security limits cannot be translated effectively into network elements limitations and need to be approved by competent NRAs.
• Long Term Nominations (LTNom) are provided by TSOs for bidding zone borders with Physical Transmission Rights (PTRs) in the long-term timeframe. Currently, the only bidding zone border issuing PTRs is HR-SI.
• Long-Term Allocation (LTAs) values are provided by JAO. These LTAs are the result of the long-term allocated cross-zonal capacities in the yearly and monthly long-term auctions.

The merging entity (Coreso) and the Core Capacity Calculation tool (CCCt) perform data quality checks (DQCs) on the provided individual TSOs inputs to secure correct data is used during the capacity calculation process. These concerns:

• Syntax check
• Coherence check

In case an error is identified, TSOs can adapt and resend their input data.

During the merging step, the Individual Grid Models (IGMs) are merged by the merging entity (Coreso) to create a Common Grid Model (CGM) which is the best prediction of the grid. The main difficulty is to get all the individual grid model to converge and reach balance in terms of production and consumption in line with the common Core forecasted net positions – see below.

To achieve a balanced CGM, during the merging, the merging entity provides a common Core Net Position Forecast (NPF). In case the net position of the IGMs show significant deviations from this Core forecast, the net position of the IGMs is shifted toward the common Core NPF. Also, in case of issues in the merging process, individual inputs can be updated or replaced.

When all the merged input data have been collected in the Core Capacity Calculation tool, a data quality check is performed. The quality of individual GLSK, CNEC files and RAs are checked against the merged CGM for various issues. Based on the feedback received via the Data Quality Check, TSOs have the option to correct and resend their input files. A new data quality check is generated after every new upload of input data.

The CCCt computes the initial FB parameters based on the merged input files. These initial FB parameters consist of the sensitivity of the network elements on net position changes, PTDFinit (initial Power Transfer Distribution factors) and RAM (Remaining Available Margin) for each CNEC.

Afterwards, the CNEC selection is performed for every timestamp of the business day and CNEC. CNECs with a maximum zone-to-zone PTDFinit for any exchange within Core of smaller than 5% are removed. Hence the purpose of the CNEC selection is to identify those critical network elements that are not sensitive to cross-border exchanges and to remove these from the CNEC list, so these will not limit the FB domain.

Non-costly remedial actions as provided by the TSOs are used in the NRAO process to enlarge the FB domain. The NRAO process is based on the objective to maximize the smallest relative RAM. For example, topological measures are applied or changes in tap position of a phase shifting transformer (PST) are made to increase the smallest relative RAM. This process continues until NRAO cannot increase the relative RAM any further on any CNEC. Note: The resulting application of non-costly remedial actions after NRAO does not pre-determine the state of non-costly remedial action in the D-1 operational security analysis.

Core FB DA CC uses two different NRAO optimization tools with different algorithms but the same objective: a closed remedial action optimisation and a heuristic approach. The CCCt compares the outcomes of both NRAOs per time stamps and selects the best results during the RAO selection step. The resulting set of preventive RAs is applied to the CGM which is used for later FB Computation. Applied curative RAs are considered by having tow entries of the same CNEC in the FB domain – one without the curative RA and one with the curative RA.

The CCCt computes the intermediate FB parameters including the selected remedial actions after the RAO selection.

Furthermore, the intermediate computation enlarges the RAM by adjustment for minimum RAM (AMR). The AMR is the translation of a) the requirement of 20% of Fmax minimum RAM for Core exchanges and b) the 70% of Fmax for cross-zonal exchanges (both Core and non-Core) to a value in MW per CNEC. Given the enlargement of the cross-zonal capacities, the remaining available margin (RAM) per CNEC is calculated.

During the simple coordinated validation step, Core TSOs provide list of their remedial action potential for other TSOs to consider in their individual validation step. This remedial action potential is comprised of both costly remedial actions (redispatch and countertrading) and non-costly remedial actions (topological measures and tap positions of phase shifting transformers/auto transformers). The day-ahead capacity calculation process will be further enhanced with a full coordinated validation when implemented.

During the individual validation phase, each Core TSO (or Core TSO consortium) validates cross-zonal capacities to ensure operational security. The approaches and methodologies applied by Core TSOs (or consortia) fulfill requirements set in the CCM but differ in details and there is not one single way to conduct individual validation. In any case, if TSOs deem operational security to be at risk, i.e. that congestions cannot be solved using all remedial actions that are expected to be available , they may apply individual validation adjustments (IVAs). These IVAs can be applied on CNECs and lead to a reduction of the RAM on the CNEC. In the context of the Core day-ahead capacity calculation process, a positive IVA means a reduction of RAM. Note that an increase of the RAM (i.e. a negative IVA) is not allowed in the Core day-ahead capacity calculation process.

The pre-final computation takes onboard any adjustments that were made during coordinated or individual validation. If CVAs and/or IVAs were applied, these CVAs and/or IVAs are considered, and the RAM is reduced accordingly. Note that in case a CVA or an IVA that would lead to a negative RAM, the RAM is kept at 0 MW.

If no CVA or IVA were applied, the pre-final domain is exactly the same as the intermediate domain. The pre-final domain is published on the JAO publication tool.

This process phase is designed to receive two inputs:

• Latest status of long-term allocated capacities (LTAs)
• Long-term nomination (LTNs)

The LTAs based on yearly and monthly auctions are received from JAO. These LTAs reflect curtailments if applied by TSOs.

Long-term nominations are received for bidding zone borders where physical transmission rights (PTRs) are issued. As of 2023, the only Core bidding zone border with PTRs is the Slovenian – Croatian bidding zone border. These long-term nominations are not netted (i.e. they nominations in either oriented bidding zone border are kept) and netting is done directly in the capacity calculation tool.

Once these final inputs have been received, the final computation is triggered. During the final computation, long-term nominations are considered, and the flow-based and LTAs domain are shifted from zero balance to long-term nominations.

The final flow-based domain and LTAs, both shifted to long-term nominations are published on the JAO publication tool and provided to SDAC along with the allocation constraints.

The SDAC market clearing process uses the Core Flow-based domain combined with the LTAs to create constraints that limit a market clearing point – point where supply meets demand. Market clearing point can be at the same time limited by the allocation constraints used by some Core TSOs.