Fix issues related to attributes
Opened this issue · 1 comments
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 everysetParameters
method. As long assetParameters
does not recreate the sub-VoltageSource, the first call tosetReference
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
andBase::Ph3::Resistor
have a propertymConductance
. 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. -
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
-
The MNASolver uses different attributes depending on if it computes multiple frequencies in parallel (expressed through
mFrequencyParallel)
- The corresponding attributesmLeftSideVectorHarm
andmLeftSideVector
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.
- 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
-
The
clone
andsetParameters
methods are very similar for many basic components. Maybe aclone
could just clone all attributes that have a certain "parameter" flag set. However, this could lead to problems becausesetParameters
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 inMNAInterface
) to reference theright_vector
of its sub-component. Theright_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.
-
- SImPowerCom list should be used, mark with FIXME
-
The SP::Ph1::Load::updatePQ method references attributes
P_nom
andQ_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
Things that may be converted into new, full issues:
- Rework the parameter system to replace the setParameters and clone methods
- Look for and delete dead / unused code (related to unused variables, methods and classes)
- Define and enforce a consistent code format / style