Internal Solver

<< Click to Display Table of Contents >>

Navigation:  »No topics above this level«

Internal Solver

ATPDraw version 7.7 has an embedded, limited solver.

The solver is invoked from the ATP menu under Run Solver.

 

The main purpose of the embedded solver is right now for demonstration purposes and future developments towards 2030 and beyond.

The main objectives for the solver are:

Robust simulation of power electronics

Accurate modeling of nonlinearities

Support state-of-the-art Cable Models

User-expandable with DLL features

More flexible scripting feature with support of Python and MatLab (ref. Python4Delphi and Dew Research Scripting).

Maintain the simplicity and speed of ATP. Maintain support of ATP for one-to-one comparisons. Write PL4-file.

 

The solver has the following characteristics

Controls are implemented in Version 7.7 (both TACS and MODELS). This is a huge and significant part that needs further testing and improvements. Limitations in MODELS are COMBINE/DIFFEQ. Limitations in TACS is proper sorting of devices and logics in front of or after the linear and nonlinear parts.

Electrical machines (SM, UM_1 and UM_3), BCTRAN and XFMR components are supported in Version 7.7. No saturation or machine control is supported. Doubly fed induction machines (UM_4), single phase (UM_6) and DC machines (UM_8) is not supported.

It uses interpolation of all states and history sources in its core. Identifies exact switching instances and gives a (potential) robust handling of power electronics. Uses Interpolation also for (pseudo-)nonlinear resistors and inductors, including type 96.

Implements steady-state initialization and Frequency Scan for all components.

Supports the universal line model (ULM) for cable and overhead line modeling.

The solver itself is based on partial LU-factorization and sparse matrix storage. No limits on the system size. Scales well with the number of nodes.

Multiple runs is supported with execution of the solver in parallel threads. The solution is thread-safe as no external files is involved in the process.

Progress report is added also for single simulation.

The following procedures are called for each component

oPreCalc. Before the calculation starts. Give timestep.

oGetFreqDomain. In the steady-state initialization or in Frequency Scan. Given frequency. Sets the complex system description.

oInitialize. After the steady-state initialization and before the timestep loop. Complex phasor solution given. Sets the history sources and initial states.

oGetTimeDomain. In the timestep loop for most components. Updates history sources and potential the system matrix.

oCheckInterpolate. In the timestep loop for selected components. Check if switching could occur in (the remaining part of) the timestep.

oSwapState. In the timestep loop for selected components. Perform the actual change in states that happens first in time (switches, nonlinear etc.)

oDoInterpolate. In the timestep loop. Perform interpolation for all components.

oGetPlot. In the timestep loop for selected components.

The solver plots result in a debug window that gives all plots, debug info, simulation speed plot. This will be optionally turned off in future releases, but makes sense now.

The solver creates a PL4-file and a LIS-file (not complete at this stage).

 

Maintaining the speed of ATP is very challenging as ATP is highly optimized with apparently a fixed and flat data structure. The embedded Solver uses an object oriented data structure with dynamic memory management that facilitates expansion and development, but slows down performance somewhat. Lists of components need to be iterated in the time-step loop for interpolation requests, history vector updates and this steals some microseconds here and there. Still, the speed of the solver is quite fast (speed is approximately half of ATP, but faster for ULM due to the TYPE94 interface). A potential time-saver taking advantage of transmission line decoupling is not implemented. The partial LU-factorization could probably also be optimized. Using compiled scripts is another potential development step for increased speed.