• Equations are not rendered correctly, (Markus: related to new katex version, additional escape backslash required, see dpsim-docs for correct latex rendering)
• Although Hugo seems to support syntax highlighting via pygments, the code contained in the documentation is currently not correctly highlighted (Markus: we just need to mark the code blocks correctly)
• The doxygen-documentation seems to not be generated correctly: https://sogno.energy/dpsim/doxygen/index.html
• The Dockerfile included in the docs/hugo folder does build but does not include Go, so hugo does not work in there
• The docs cannot be built in the current Fedora34 DPsim-Dev container, because the versions of Go / Hugo in the repos are too outdated
• The actual markdown files are contained in many nested folders which do not directly correspond to the generated HTML page tree. This makes it hard to track changes, especially when most of the files are named index.html
• The links between pages only work in the built HTML version, but cannot be used to jump between markdown files on GitHub.

Some of these issues could be solved by using other tools better suited for building code documentation, e. g. mdbook. This results in a file structure similar to here: https://github.com/rust-lang/nomicon/tree/master/src

The integration of powerflow and dynamic simulation (SP,DP,EMT) should be improved.
The idea is to

• store more information in the Topological classes, not just parameters e.g. from CIM but also powerflow results of nodes and terminals
• replace the call to Reader::initDynamicSystemTopologyWithPowerflow() with something more intuitive where the same SystemTopology is used from PF to dynamic simulation

The picture below shows the proposed class structure.

Are these files duplicates?

• https://github.com/sogno-platform/dpsim/blob/master/Source/pybind/dpsim-villas.cpp
• https://github.com/sogno-platform/dpsim-villas/blob/main/src/pybind-dpsim-villas.cpp

Apparently, only the latter is used.

@JTS22
@m-mirz

Attributes should be declared as member variables of the component class to avoid something like attribute<Complex>("V_ref")->get() during the simulation. This is not efficient and the attributes of a component class are not easily deduced from looking at the component class declaration.
mInductance = addAttribute<Real>("L", Flags::read | Flags::write);

Each attribute should include

• name
• physical unit
• fixed / variable, where variable is used for attributes that may be changed by the simulation

Accordingly, the python print should include more columns for this information.

Attribute list for object with name cs:
name                          type                size           value                         
-----------------------------------------------------------------------------------------------
I_ref                         Complex                            10.000000<0.000000            
f_src                         Real                               50.000000                     
i_intf                        MatrixReal          1x1            [...]                         
name                          String                             "cs"                          
right_vector                  MatrixReal          0x0            [...]                         
uid                           String                             "cs"                          
v_intf                        MatrixReal          1x1            [...] 

To make the work with the attributes more comfortable in the component classes, some operators like cast () and assignment operator might be overwritten but this should be limited as much as possible.

We also need to improve the mechanism for describing the output - input relation between two components.
Currently, it is possible to change the map value for a key calling something like this:
voltageSource->setAttributeRef("V_ref", attribute<Real>("V_ref"));
If you store are reference to an attribute inside a component like below, the stored reference might be invalid after calling the function above.
voltageRef = attribute<Complex>("V_ref");

We could add one member variable to the Attribute class that points to referenced Attributes, which describes an input output relation. Still, the value pointer address should be overwritten for the input Attribute to minimize the overhead when reading the value during simulation time.

Naming of SG models has become quite heterogenous. We envision the following nomenclature:
SynchronGenerator<OrderNumber><OptionallyModelVariant><SolutionMethod>
Example: SynchronGenerator6aVBR

Abbreviations for possible solution methods:

• Delayed Current Injection Method (DCIM)
• Predictor Corrector Method (PCM)
• Voltage Behind Reactance (VBR)

Also GeneratorType has become quite heterogenous. We could envision the following:
enum class GeneratorType {PVNode, IdealVoltageSource, IdealCurrentSource, [DifferentialEquationSystemModels]}

Where [DifferentialEquationSystemModels] enumerates the models describing the synchronous generator in terms of a differential equation system. The entries could look as follows:
Order<OrderNumber><OptionallyModelVariant><SolutionMethod>
Example: Order6aVBR

Instead of setting many parameters in the Simulation class and later again in the Solver class, we want to group all these parameters in on class called SimulationParameters. Then, the simulation needs basically only two inputs: SystemTopology and SimulationParameters

Since reworking the attributes entails reading through a lot of DPsim's current code, here are some random things I noticed that might be worked on later on:

• In the EMT::Ph3::NetworkInjection class, the attribute references are set in the constructor as well as in every setParameters method. As long as setParameters does not recreate the sub-VoltageSource, the first call to setReference in the constructor should be sufficient.

  • solved in 3b5c21b

• The Base::Ph1::PQLoad class is never used. Delete it.

  • solved in 24c1e20

• The DP::Ph1::SynchronGeneratorTrStab has an option for setting a reference for Omega and Delta (mUseOmegaRef). This can probably be implemented better using the new dynamic attributes (see comments in the code).

  • solved in 90a31a8

• The SP::Ph1::PiLine defines attributes that access individual Matrix sub-components. While this can be implemented using dynamic attributes, this seems kinda overkill. Especially since these attributes only seem to be used in one example and only for logging purposes (which has derive-methods already)

  • mark with FIXME
  • solved in 0977184

• Base::Ph1::Resistor and Base::Ph3::Resistor have a property mConductance. It is always the inverse of the resistance (as it should be?). Maybe make these derived attributes or calculate them directly in the code using them.

  • solved in 512537a and d2061fb

• From the various SynchronGenerator classes, some of them have no header file at all while others derive from Base::SynchronGenerator in the header, but try to call the child constructor of some nonexistant class SynchronGeneratorBase. Currently, none of these classes should compile: DP::Ph3::SynchronGeneratorDQSmpl, DP::Ph3::SynchronGeneratorVBR, DP::Ph3::SynchronGeneratorVBRStandalone, EMT::Ph3::SynchronGeneratorDQSmpl, EMT::Ph3::SynchronGeneratorDQSmplCompSource, EMT::Ph3::SynchronGeneratorVBRSmpl, EMT::Ph3::SynchronGeneratorVBRStandalone

  • will be deleted by Jan
  • These still exist on the current master commit
  • solved in d638c01

• Move small methods currently implemented in header files into the corresponding cpp files when the class is not header-only

  • changed in 62710d5, 8973cc2, and bd38116
  • Exceptions: Constructors, Empty Methods, Methods of Sub-classes (as declared in the same header file, e. g. tasks), Methods with unknown template types

• The MNASolver uses different attributes depending on if it computes multiple frequencies in parallel (expressed through mFrequencyParallel)- The corresponding attributes mLeftSideVectorHarm and mLeftSideVector should probably be unified

• Many of the basic components (Capacitor, Resistor, Inductance...) are (partly) derived from a base class which contains only the components main parameter (C, R, L...). Since these base classes are currently not derived from AttributeList, their attributes can not be initialized in the usual way, rather the initialization has to be moved into the subclasses.

  • This happens so often it is the norm rather than the exception. For the generator classes, it is probably unreasonable to delete the entire base class, so this should either be left as is or the registration of attributes in the mAttributes list has to be changed somehow.

• The clone and setParameters methods are very similar for many basic components. Maybe a clone could just clone all attributes that have a certain "parameter" flag set. However, this could lead to problems because setParameters often has side effects. Maybe make a new issue for reforming the whole parameter system?

• For some DP and SP components (e.g. {DP,SP}::Ph3::VoltageSource), the component code is nearly identical. One might consider reusing the relevant computation tasks.

• Use a standardized formatter and check for formatting in the CI pipeline

• The DP::Ph1::PQLoadCS sets its right_vector attribute (which is declared in MNAInterface) to reference the right_vector of its sub-component. The right_vector should not be set to dynamic, so is there a better alternative here? This also happens in {DP, EMT}::Ph1::VoltageSourceRamp.

• There exists many attributes which are either never used at all or only written to but never read. Many of them are marked with FIXME or CHECK comments and can probably be deleted.

• Perform a dead-code analysis.

• #131

  • SImPowerCom list should be used, mark with FIXME

• The SP::Ph1::Load::updatePQ method references attributes P_nom and Q_nom that are never declared

  • Is marked with FIXME

• Some of the Signal-Components (e. g. FIRFilter, Integrator, PLL, PowerControllerVSI) rely on attributes being explicitly set by outside code. While possible, this requirement should be documented or facilitated through an explicit setter method.

  • add comment

• #132

• create new MQTT example based on this one using the new villas interface, like for the newer examples in the villas folder
  • call InterfaceVillas() instead of InterfaceShmem()
  • run only the simulator, starting and stopping villas node is not required
  • load grid data like here
• this should work on the master branch but all changes/fixes related to villas should be done on this branch
• replace MQTT by IEC104 in another new example in the villas directory

The DPsim documentation for a Docker-based setup refers to the rwthacs/dpsim-dev image which hasnt been updated for 7 months:

https://dpsim.fein-aachen.org/docs/getting-started/build/

I think it would also be much nicer if a user could start without building the image himself.
The current instructions seem far to complex.

System Matrix Stamp of DP_Ph3_VoltageSource

In DP_Ph3_VoltageSource Line 69 the stamp for phase C differs from A and B:

`if (terminalNotGrounded(0)) {
...

	Math::addToMatrixElement(systemMatrix, matrixNodeIndex(0, 1), mVirtualNodes[0]->matrixNodeIndex(PhaseType::B), Complex(-1, 0));
	Math::addToMatrixElement(systemMatrix, mVirtualNodes[0]->matrixNodeIndex(PhaseType::B), matrixNodeIndex(0, 1), Complex(-1, 0));

	Math::addToMatrixElement(systemMatrix, matrixNodeIndex(0, 2), mVirtualNodes[0]->matrixNodeIndex(PhaseType::C), Complex(-1, 0));
	Math::addToMatrixElement(systemMatrix, mVirtualNodes[0]->matrixNodeIndex(PhaseType::C), matrixNodeIndex(0, 2), -Complex(-1, 0));
}`

This leads to phase C beeing shifted when transformed into EMT frame and unintended model behaviour:
Bug ( with -Complex(-1,0)); )

Fixed (with Complex(-1,0)); )

The DP_Ph1_VoltageSourceRamp and EMT_Ph1_VoltageSourceRamp classes should be superseded by the SignalGenerator in the normal VoltageSource. The classes are only used in one example and not bound to Python, so they can probably be deleted.

Here &**mSubInductor->mRightVector should be changed to &**mSubCapacitor->mRightVector.

• Currently not supported NICSLU codes
  • nicslu solver updates: https://git-ce.rwth-aachen.de/acs/private/research/rte/nicslu-customlu
  • dpsim nicslu branch: https://github.com/sogno-platform/dpsim/tree/syngen-vbr-nicslu
    • should be replaced by a NICSLUAdapter or using MNAPlugin

• FIXME
• CHECK
• TODO
• DEPRECATED
• THISISBAD

Hello @m-mirz,

cim:PowerTransformer are ignored when they are imported and have 3 cim:PowerTransformerEnd. Implementing the 3 winding transformer model would be useful for large scenarios and complex networks where they are quite common.

In the Examples.h, we should add for each set of parameters a literature reference whenever possible.

It should look like:

@martinmoraga @gnakti Please go through Examples.h, add a literature reference whenever possible and leave a comment here and a PR when you are done.

Refactor options of CommandLineArgs

Hi in order to build DPsim on the OPAL-RT opalrtlinux target we need to find a way to build it without linking against libstdc++fs as this dependency is not available on this target:

/usr/lib/gcc/x86_64-poky-linux/8.3.0/../../../../x86_64-poky-linux/bin/ld: cannot find -lstdc++fs

It appears to me that the filesytem library is not a hard requirement for building DPsim.
Can we disable certain features of DPsim which require it with "#ifdefs"?

https://dpsim.fein-aachen.org/docs/getting-started/install/

• Update pypi package comment
• Update docker build -t sogno/dpsim:dev -f Packaging/Docker/Dockerfile.dev .

All villas related examples should be located in examples/villas and included in the tests if possible.
Examples using old interface can be moved to a villas-deprecated folder.

Focus for the examples should be on:

• MQTT
• simple circuit with import + export
• CIGRE-MV with node voltage export
• new villas interface

Could be based on this implementation:
https://moodycamel.com/blog/2013/a-fast-lock-free-queue-for-c++.htm

Requirements:

• provide lock-free communication between two threads in dpsim, independent of communication interface implementation
• C++ not C

I tried to run one of examples, but I have got the following error:

import dpsimpy
ModuleNotFoundError: No module named 'dpsimpy''

What means dpsimpy?

It would be better to group the GitHub Actions jobs for each OS.

The version currently used in the DPsim docker images (Villas commit b94746effb015aa98791c0e319ef11223d18e8b0) uses VILLAScommon on commit 25cd53ee6882c3f66746d6d8c27790ef22d18322 as a submodule. This version cannot be compiled with GCC version 12+. Apparently, the repos used in the new ManyLinux Docker image (added in #139 ) changed during the last days to now download GCC 12 instead of 11. This broke the Docker image build between https://github.com/sogno-platform/dpsim/actions/runs/3480565146/jobs/5821064882 and https://github.com/sogno-platform/dpsim/actions/runs/3565405165/jobs/5990523552. Because the current master commit of VILLASnode also still uses the same subcommit of VILLAScommon, just updating the version of VILLASnode in dpsim will not suffice, but either dpsim needs to manually checkout a newer subcommit of VILLAScommon (probably not a good idea) or the VILLASnode master needs to include a newer subcommit.

At least the basic tests should be migrated from gitlab-ci (https://git.rwth-aachen.de/acs/public/simulation/dpsim/dpsim) to github workflow before we can completely migrate the DPsim development to github. This issue tracks the progress of implementing the workflow.

This documentation should build upon #133 and include

• "sync on start" as well as "sync on each read/write"
• the "external" attribute dependency that voids dropping tasks by the scheduler

• Check that explicit subcomponent tasks are only defined when reasonable in terms of expected computational effort, otherwise let the subcomponent's pre- and poststep routines be handled by the supercomponent
• Every SimPowerComp has a vector mSubComponents of subcomponents but most classes derived from SimPowerComp have their subcomponents as separate member variables, not utilizing this list.
  • Make use of mSubComponents to harmonize calling pre- and poststep routines, as for example shown here
• Document the different concepts of how to handle pre- and poststep routines of subcomponents

• Reuse the order-specific auxiliar constants in the domain specific VBR models

  • Example 4th order:
    • EMT_Ph3_SynchronGenerator4OrderVBR
    • The same constants are also used by DP_Ph1_SynchronGenerator4OrderVBR and SP_Ph1_SynchronGenerator4OrderVBR
  • Instantiate and calculate the order-specific auxiliar constants already in Base_ReducedOrderSynchronGenerator
  • Same goes for 3rd and 6th order
  • Stick for 3rd/4th order model to nomenclature for auxiliar constants introduced in 6th order model, i.e. use _t as subscript e.g. mAd_t

• Specify and reuse the order-specific resistance matrix constants in the domain specific VBR models

  • Example 4th order
    • DP_Ph1_SynchronGenerator4OrderVBR
    • The same constants can also used by EMT_Ph3_SynchronGenerator4OrderVBR and SP_Ph1_SynchronGenerator4OrderVBR
  • Instantiate and calculate the order-specific resistance matrix constants already in Base_ReducedOrderSynchronGenerator
  • Same goes for 3rd and 6th order

• Remove Ef from auxiliar constants

  • Example 4th order:
    • EMT_Ph3_SynchronGenerator4OrderVBR
  • Remove Ef

• Rename Cq to Dq

  • Example 4th order:
    • EMT_Ph3_SynchronGenerator4OrderVBR

• Reconsider zero component in EMT_Ph3 models

• Use resistance matrix constants A and B in EMT_Ph3_SynchronGenerator4OrderVBR

• Simplify the DP-DQ interface to obtain armature voltage (and armature current), which currently looks as follows
  

  dpsim/models/Source/DP/DP_Ph1_SynchronGeneratorVBR.cpp

  Lines 97 to 102 in 2499325

  	// convert armature voltage into dq reference frame
  	Matrix parkTransform = get_parkTransformMatrix();
  	MatrixComp Vabc_ = mIntfVoltage(0, 0) * mShiftVector * Complex(cos(mNomOmega * mSimTime), sin(mNomOmega * mSimTime));
  	Matrix Vabc = Matrix(3,1);
  	Vabc << Vabc_(0,0).real(), Vabc_(1,0).real(), Vabc_(2,0).real();
  	mVdq = parkTransform * Vabc / mBase_V_RMS;

  
  Instead of applying DP-EMT and EMT-DQ transformation, directly apply DP-DQ transformation, as e.g. done for the voltage behind the reactance
  

  dpsim/models/Source/DP/DP_Ph1_SynchronGenerator3OrderVBR.cpp

  Line 93 in 2499325

  mEvbr = (mKvbr * mEh_vbr * mBase_V_RMS)(0,0);

  
  using
  

  dpsim/models/Source/DP/DP_Ph1_SynchronGeneratorVBR.cpp

  Lines 65 to 67 in 2499325

  	mKvbr = Matrix::Zero(1,2);
  	mKvbr(0,0) = Complex(cos(mThetaMech - mBase_OmMech * mSimTime), sin(mThetaMech - mBase_OmMech * mSimTime));
  	mKvbr(0,1) = -Complex(cos(mThetaMech - mBase_OmMech * mSimTime - PI/2.), sin(mThetaMech - mBase_OmMech * mSimTime - PI/2.));

• Harmonize implementation of DQ-DP and DQ-SP interface implementation
  

  dpsim/models/Source/SP/SP_Ph1_SynchronGeneratorVBR.cpp

  Lines 80 to 82 in 15657fe

  	dqToComplexA <<
  	cos(mThetaMech - mBase_OmMech * mSimTime), -sin(mThetaMech - mBase_OmMech * mSimTime),
  	sin(mThetaMech - mBase_OmMech * mSimTime), cos(mThetaMech - mBase_OmMech * mSimTime);

• Simplify definition of VBR resistance matrix in DP_Ph1 models according to equivalent derivation
  

  dpsim/models/Source/DP/DP_Ph1_SynchronGeneratorVBR.cpp

  Lines 47 to 50 in e6f3776

  	resistanceMatrix(0,0) = mR_const_1ph.real() + mKa_1ph.real() + mKb_1ph.real();
  	resistanceMatrix(0,1) = -mR_const_1ph.imag() - mKa_1ph.imag() + mKb_1ph.imag();
  	resistanceMatrix(1,0) = mR_const_1ph.imag() + mKa_1ph.imag() + mKb_1ph.imag();
  	resistanceMatrix(1,1) = mR_const_1ph.real() + mKa_1ph.real() - mKb_1ph.real();

• Rename DP_Ph1_SynchronGeneratorVBR and SP_Ph1_SynchronGeneratorVBR to be consistent with EMT_Ph3_ReducedOrderSynchronGeneratorVBR

• Make SGModel of type String. Then you can use '6a' and '6b' instead of 6 and 7, which can become confusing in particular if we have models 6c, 6d etc. in the future

• We can add another case distinction during calculation of constants in Base::ReducedOrderSynchronGenerator, since mAd_t and mBd_t are only used within the fourth-order model.
  

  dpsim/dpsim-models/src/Base/Base_ReducedOrderSynchronGenerator.cpp

  Lines 216 to 217 in 2cca71a

  	mAd_t = mTimeStep * Zd_t / (2 * mTq0_t + mTimeStep);
  	mBd_t = (2 * mTq0_t - mTimeStep) / (2 * mTq0_t + mTimeStep);

Currently, DPsim can not be built with Eigen3 installed as a submodule as the CMake imported target Eigen3::Eigen3 is only available after the find_package(Eigen3) call which gets only executed if Eigen3 is not installed via the submodule.

I propose to call find_package(Eigen3) regardless whether the submodule is used or not

@martinmoraga We should add a common namespace in Examples.h for the newly introduced SMIB examples of #64 in order to ensure that all examples have a consistent parametrisation.

This could look like

namespace Examples {
namespace Grids {
namespace SMIBType2 {
  struct Line {
    ...
  }

  struct Fault {
    ...
  }
  
 ...
}
}
}

Current state (02.12.21):

• MnaSolver::initialize
  • identifyTopologyObjects
    • classification of power/signal comps and variable comps
  • MnaSolver::createEmptySystemMatrix
    • is abstract and implementd by MnaSolverEigenDense and MnaSolverEigenSparse
      • creates empty matrices mSwitchedMatrices and mLuFactorizations (number depends on number of switches)
      • MnaSolverEigenSparse::createEmptySystemMatrix additionally creates mBaseSystemMatrix (number also depends on number of switches)
  • MnaSolver::initializeComponents
    • initializeFromNodesAndTerminals
    • initialize (here only signal comps, currently initialize of SimPowerComps in SystemTopology)
    • mnaInitialize
  • MnaSolver::initializeSystem
    • calls either initializeSystemWithParallelFrequencies or initializeSystemWithPrecomputedMatrices
      • MnaSolver::initializeSystemWithPrecomputedMatrices: stamps static elements by calling switchedMatrixStamp (implemented by Sparse or Dense)
        • MnaSolverEigenSparse::switchedMatrixStamp stamps all static elements to mSwitchedMatrices and calculates corresponding mLuFactorizations
    • called and extended by MnaSolverSysRecomp
      • saves static switch matrices as base matrices
      • add variable elements to currently active mSwitchedMatrices according to mCurrentSwitchStatus
      • recalculates correspondingly mLuFactorizations according to mCurrentSwitchStatus
• PFSolver::initialize
  • PFSolver::initializeComponents
    • initializeFromNodesAndTerminals
    • calculatePerUnitParameters
  • PFSolver::determinePFBusType

We require a Python example that demonstrates the export and import functionality based on villas-node. So, far there is only an example available that exports data to MQTT:
https://github.com/sogno-platform/dpsim/blob/master/Examples/Python/Shmem/shmem-cigre-mv-pf-profiles.py

This is a CPP example that includes import and export:
https://github.com/sogno-platform/dpsim-villas/blob/main/examples/cxx/ShmemDistributedVillas.cpp
Two DPsim instances are interconnected via one villas-node that is configured more or less like here:
https://github.com/sogno-platform/dpsim/blob/master/Configs/villas-shmem.conf

This example can based on the shmem-cigre-mv-pf-profiles.py example and should go in the same folder.

DPsim started as a GPL3 project, partly due to its dependency on VILLASnode, which is licensed under the GPL3 as well. Since the GPL3 is a strong barrier for many potential contributors, I would like to relicense the whole project under the MPL2 license.

The MPL2 is not as viral as the GPL3 and also Eigen3, one of the core libraries used in DPsim is licensed under the MPL2. Of course, I would move the code associated to VILLASnode to an external repository.

Some of the Jupyter-Notebooks using the new Python Interface (see #22 ) take multiple minutes for a full run-through, which causes the test pipeline to run quite long. This table aims to summarize the current run times (using the notebooks in #22 ) for evaluation and adaption of simulation run times and pipeline tests. The full notebook runtime is measured in a single run of pytest --durations=0 -v , the simulation run times are measured using the iPython %%timeit cell magic with the time calculated as the average over seven runs. Simulation run times contain the full setup and run of the dynamic simulation without PowerFlow or later data evaluation / plotting. Please note that this is not meant as a complete, accurate benchmark but rather as an overview over which notebooks should be tweaked when tested in the CI-pipeline.

Overall

61 notebooks in Circuits, Components or Grids
7 notebooks skipped in pytest(11,5%)
25 notebooks with asserts (41,0%)

Circuit-Examples

Full pytest-run in 760.53s (0:12:40)
26 passed, 2 skipped (92.9% tested)
10 of 28 notebooks with asserts (35,7%)

Component examples

Full pytest-run in 133.57s (0:02:13)
10 passed, 1 skipped (92.9% tested)
7 of 11 notebooks with asserts (63,6%)

Grid examples

Full pytest-run in 223.14s (0:03:43)
18 passed, 4 skipped (81,8% tested)
8 of 22 notebooks with asserts (36,4%)

Related PRs / tasks:

• #107
• #112
• #138

This interface should take advantage of a deeper VILLASnode integration compared to the shmem interface making it easier to use.
A branch of VILLASnode should be used here which includes a CPP version of the node class:
https://git.rwth-aachen.de/acs/public/villas/node/-/tree/node-cpp

This is mainly implemented in the dpsim-villas module / project:
https://github.com/JTS22/dpsim-villas/tree/villas-interface

It would be convenient to able to print the complete lists of attributes of each component from the Python interface including each attribute's type, e.g. real or complex.

Because it causes the buildbot to OOM kill arbitrary processes because of memory contraints:

Example: https://git.rwth-aachen.de/acs/public/simulation/dpsim/dpsim-github/-/jobs/1951371

Enable sonar cloud scan for C++ code.

Motivation
To test basic unsymmetric simulations an unsymmetric input signal is needed.

Implemented Solution
As a preliminary solution I implemented a new EMT_Ph3_NetworkInjection1ph and EMT_Ph3_VoltageSource1ph which basically connects to just one phase in the 3ph EMT domain and provides unsymmetric behaviour.

Alternatives?
Are such additional components necessary or is there an easier way e.g. combining EMT 3ph and EMT 1ph components?

Extensions
If the solution is suitable the concept can be extended by enabling a connection to a combination of phases as well as different signals for each phase. Possible implementations would be a new class (like in the basic implementation) or a extension of the basic EMT_Ph3_NetworkInjection and EMT_Ph3_VoltageSource classes.

procps is required for hybrid C++ Python debugging.

@m-mirz

• Getting started by sketching content

• error - all errors
• warn - all warnings
• off - recommended to use e.g. when running case studies where exclusively the simulation results should be logged
• info - logging of information that are basic and that are logged only once before/after the simulation
• debug - logging of information for debugging (extended static information, e.g. initialization values, matrix stamps, subcomponents)
• trace - logging of information in each simulation step