ATC Analysis Methods: Iterated Linear Step (IL) then Full CTG Solution

 

This method takes the solution process a step further than just the Iterated Linear (IL) method. Instead of using linear sensitivities to calculate the impact of contingencies on the transfer limits, full contingencies are implemented and solved with a full power flow solution. Be aware however, that this calculation method can be extremely slow.

The initial iteration process of (IL) then Full CTG Solution method starts by performing the steps outlined in the Iterated Linear (IL) process. As the initial iteration process is performed, the transfer limiter may be different (i.e. the contingency and limiting element pair may be different) during each iteration. Once the Stepsize is determined to be less than or equal to the tolerance (or the maximum number of iterations is met) the order of the limiters is set.

At this point, the first user specified Transfer Limiters to Iterate On are taken from the list of limiters and the steps outlined in the Iterated Linear (IL) process are repeated for each limiter individually, with the contingency and limiting element pair of each limiter remaining set as determined in the initial process. Some limiters that will appear in the list of limiters are not valid for iterating on individually. These limiters include those indicating the full transfer amount could not be ramped in the initial process and those indicating that a reserve limitation has been met on the source or sink. These type of limiters will be skipped when choosing those to iterate on individually.

Once the iterated process has been repeated for an individual limiter, there are two different ways that the processing of the full contingency can proceed. If choosing to NOT Force all transfer ramping to occur in pre-contingency states and repeat full CTG solutions, the contingency of each transfer limiter is then enforced in the power flow topology, and a power flow solution is performed to give a new contingency power flow solution to use as the base for each transfer limiter. If the option to Use Specific Solution Options for Contingencies is checked, then the power flow is solved with the options defined with the Contingency Solution Options. Otherwise, the power flow is solved with the options specified with the Power Flow Solution Options. In either case, the Make-Up Power option specified with the contingency analysis options is used when applying the contingency. The iterative process outlined in the Iterated Linear (IL) method is then repeated again for each individual transfer limiter with the specified contingency of each limiter actually in place in the power flow solution. If the contingency solution fails to converge, the transfer limitation will be reported highlighted in orange with the Iteratively Found field set to CTG_FAIL_IN_FULL, and the Transfer Limit that is reported will be the value determined from the iterated process performed on the individual limiter before the contingency was applied. If the contingency fails to solve because a contingency Abort action has been implemented, the Iteratively Found field is set to CTG_ABORTED_AFTER_LINEAR, and the Transfer Limit that is reported will be the value determined from the iterated process performed on the individual limiter before the contingency was applied.

If choosing to Force all transfer ramping to occur in pre-contingency states and repeat full CTG solutions, after the iterated process is complete for an individual limiter, the contingency of each transfer limiter is fully implemented in the following steps:

• Store the system state following the iterated process on the individual limiter
  • At this point the accumulated transfer amount is the total amount that has been transferred following completion of the iterated process on the individual limiter.
  • The Stepsize is zero for the first iteration.
• Apply the contingency and perform full power flow solution
  • If the option to Use Specific Solution Options for Contingencies is checked, then the power flow is solved with the options defined with the Contingency Solution Options. Otherwise, the power flow is solved with the options specified with the Power Flow Solution Options. In either case, the Make-Up Power option specified with the contingency analysis options is used when applying the contingency.
  • If the option to Iterate on failed contingency is NOT checked and the power flow fails to solve, the iterated process for the individual limiter will stop and a transfer limitation will be reported highlighted in orange with the Iteratively Found field set to CTG_FAIL_IN_FULL. The Transfer Limit that is reported is the accumulated transfer amount that has been ramped as of the last successful solution in which the contingency solved. If the contingency fails to solve immediately following the completion of the iterated process on the individual limiter without the contingency implemented, the Transfer Limit that is reported is the accumulated transfer amount achieved from that process without the contingency implemented.
    • If the contingency fails because a contingency Abort action has been implemented, the Iteratively Found field is set to CTG_ABORTED_IN_FULL. The Transfer Limit that is reported is the accumulated transfer amount that has been ramped as of the last successful solution in which the contingency solved. If the contingency is aborted immediately following the completion of the iterated process on the individual limiter without the contingency implemented, the Transfer Limit that is reported is the accumulated transfer amount achieved from that process without the contingency implemented.
  • If the option to Iterate on failed contingency IS checked and the power flow fails to solve, a new iteration loop is entered to determine the highest transfer level at which the contingency can be solved. This loop attempts to determine a more accurate transfer level at which the contingency fails to solve rather than simply reporting the transfer level at which the last power flow was successful regardless of the current Stepsize. To start the iterative process, the current Stepsize is reduced by half. The ramping is performed and the contingency is solved. The Stepsize will remain the same as long as the contingency can be solved. If the contingency fails to solve, the Stepsize will be reduced by half again. The ramping will continue until the contingency no longer solves, the accumulated transfer during the process meets the original Stepsize, or the Stepsize becomes smaller than the Stepsize tolerance, which is the user specified Transfer Tolerance.
    • An additional check is done if the contingency does solve during this process; the flow on the monitored element is checked to determine if it exceeds its limit. If it is overloaded, the Stepsize will be reduced by half until the monitored element is no longer over its limit. While this check is being done on the monitored element limit, the ramping continues out to the specified amount and the contingency is solved. During this entire process, the Stepsize is limited to be between zero and the Stepsize that was ramped when the contingency failed to solve for the first time. When the iterative process on the failed contingency completes, the iterations are done for this particular limiter. The Transfer Limit that is reported is the accumulated amount that is possible without overloading the monitored element and in which the contingency solves. The limiter will be reported highlighted in red with the Iteratively Found field set to CTG_FAIL_ITERATED if the monitored element is not loaded to its limit. If during this process, the monitored element is at its thermal limit, within the specified stepsize tolerance, and the contingency solves, the Iteratively Found field is set to FULL and the limiter will be highlighted in aqua.
      • Modified in version 22, build on November 9, 2021 It is also possible that the monitored element is still overloaded when the contingency is solved. If so, the limiter will be reported highlighted in red with the Iteratively Found field set to CTG_FAIL_ITERATED_OVERLOAD.
      • Modified in version 22, build on November 9, 2021If the Stepsize is negative when the monitored element is overloaded this means that the Stepsize needs to become more negative to reduce the overload. Instead of reducing the Stepsize by half, the Stepsize remains at the current amount until the contingency does not solve or the monitored element is no longer overloaded.
      • If the contingency fails because a contingency Abort action has been implemented, the Iteratively Found field is set to CTG_ABORTED_ITERATED. An attempt is made to find a transfer level at which the monitored element is not overloaded, but this might not be possible within the constraints of the original Stepsize. The Transfer Limit that is reported is the accumulated amount that is possible at which the contingency is not aborted.
    • If the contingency fails to solve at any transfer level (base case failure), the limiter will be reported highlighted in purple with the Iteratively Found field set to CTG_FAIL_IN_BASE. The Transfer Limit that is reported is the accumulated transfer amount that was achieved from the iterated process on the individual limiter without the contingency implemented.
  • If the power flow solution is successful, update the accumulated transfer with the Stepsize.
• Perform Single Linear Step on the individual limiter
  • The Stepsize is the Transfer Limit found for the individual limiter. If the Stepsize is less than the specified When iterating, Ignore Limiters below value minus the accumulated transfer amount, it is set to zero.
  • If generator limits are being enforced for the selected transactors, generators will be excluded from participating in the linear calculations if they are in the seller and they are at their maximum limit or if they are in the buyer and they are at their minimum limit. It is possible that there are no available participation points during the linear step and the reserve limit is encountered. If a reserve limit is encountered during the step where all transfer limiters are iterated on together, the entire ATC process will stop. If a reserve limit is encountered during the step where a limiter is being iterated on individually, the iterations will only stop for that limiter; other limiters will be processed if they do not hit a reserve limit as well. The reserve limit will be reported in the results.
• If [abs(Stepsize) <= Tolerance] or [Iterations >= 100] then stop
  • If the maximum 100 number of iterations is reached, a transfer limitation will be reported highlighted in lime green with the Iteratively Found field set to OSCILLATING indicating that the iterated process is oscillating. The Transfer Limit that is reported is the accumulated transfer amount that has been ramped as of the last successful solution. The maximum number of iterations is a value that is set internally. It is unlikely that this limit will ever be reached because other mechanisms are in place to prevent oscillations.
  • The iteration count is reset at the beginning of the contingency iteration process for each individual limiter.
• Restore system to the state stored in the first step
  • This step removes the contingency that was implemented so that the transfer ramping occurs prior to the contingency being applied.
• Implement transfer by amount of Stepsize and resolve power flow
  • The power flow is solved according to the options set with the Power Flow Solution Options.
  • When calculating a transfer between injection groups, the Island-Based AGC Power Flow Solution Options applicable to dispatch using an injection group are used when determining which generators and loads will participate in the transfer. These options include whether or not AGC status should be considered when determining which units will participate in the ramping, whether or not to enforce generator MW limits, and whether or not to allow negative loads. The power factor to use when adjusting load is also specified with these options.

  • To prevent oscillation of the solution, the Stepsize may be limited if the sign of the Stepsize changes throughout the iterations. At each iteration, the direction of the Stepsize is checked and the Stepsize is bounded based on the accumulated transfer at each iteration. The accumulated transfer is the total amount that the transfer between the seller and buyer has been ramped. The accumulated transfer is updated with the current Stepsize once it has been determined that Stepsize can be achieved. At the start of the iterated process, LowBound is initialized to a large negative number and HighBound is initialized to a large positive number. At each iteration the following checks are performed:

     If Stepsize > 0 then LowBound = (Accumulated Transfer) 

    Else If Stepsize < 0 then HighBound = (Accumulated Transfer)

    If Stepsize >= (HighBound - Accumulated Transfer)*0.7

    Then Stepsize = (HighBound – Accumulated Transfer)*0.7

    Else If Stepsize <= (LowBound - Accumulated Transfer)*0.7

    Then Stepsize = (LowBound – Accumulated Transfer)*0.7

  • During the implementation of the transfer, if the full Stepsize cannot be achieved, an attempt is made to implement as much of the transfer as possible in smaller stepsizes by reducing the stepsize by half. The stepsize reduction continues until a stepsize is found at which the power flow will solve. Once this stepsize is found, an attempt will be made to ramp to the original full stepsize using the smaller reduced stepsize. If at any point in this process a stepsize cannot be ramped, an iterative process will be used to reduce the stepsize so as much as possible of the full original stepsize can be ramped. An internal tolerance is used to prevent the stepsize from becoming too small.
  • The ramping of the transfer is done so that each step adjusts injection from a common starting point so that the ramping is effectively done in the same direction even if the Stepsize backs off the transfer. Additional details about this are provided in the steps of the Iterated Linear (IL) process.
  • If the power flow fails to solve at this point without being able to implement the full Stepsize transfer, the iterated process for the individual limiter will stop and a transfer limitation will be reported highlighted in fuchsia with the Iteratively Found field set to RAMP_FAIL_IN_FULL. The Transfer Limit that is reported is the accumulated transfer amount that has been ramped as of the last successful solution at which the contingency solved. The Transfer Limit reported does not indicate the portion of the Stepsize that could be ramped before the power flow fails to solve.
  • Reserve limits on generators and loads participating in the transfer will be checked if the option to enforce limits is active for the selected transactors. Reserve limits are checked regardless of how the option to Report Generation Reserve Limits is set with the Common Options. For areas and super areas this means that the global enforcement of generator limits is active, the area enforcement of limits is active, and there is at least one generator whose enforcement of limits is active and this generator is on AGC control. For injection groups this means that the enforcement of limits for the injection group is active. When a reserve limit is found, the current iterations will stop and a transfer limit will be reported with the reserve limit and the area, super area, or injection group that is at a limit.
• Go back to second step and repeat

Transfer limitations found by implementing the full contingency solution are highlighted in aqua in the results with the Iteratively Found field set to FULL.

This method can be applied between combinations of areas and superareas, OR between two injection groups. Combinations of areas/superareas and injection groups are not allowed.

When using this method, the PTDF and OTDF cutoff values are set to (Modified in version 22, build on May 25, 2021) 0.1 times their specified values internally by the ATC process when iterating on individual limiters. Once limiters are in the list as having acceptable distribution factors following the process where all limiters are iterated on as a whole, they should not be eliminated during the process when they are being iterated on individually. Actual implementation of the contingency as opposed to the linear determination of the impact of the contingency could lead to some large differences in the distribution factor post-contingency for some contingency scenarios. The only time that these differences could be a problem is if implementation of the contingency actually causes the monitored element to no longer be limiting, i.e. the distribution factor goes to zero. If this happens for any limiter, that limiter will be marked internally as having an infinite transfer amount, will show up in the results with a very large transfer limiter value, and will be excluded from the count of the number of limiters that have been iterated on. (Modified in version 22, build on May 25, 2021) Additionally, the Iteratively Found field will be set to YES_INFINITE if the full contingency solution was not implemented or FULL_INFINITE if the full contingency solution was implemented. The next limiter in the list will then be processed until the number of Transfer Limiters to Iterate on has been met or there are no more limiters.