Resolve FIXME, CHECK, TODO, DEPRECATED and THISISBAD comments

[dinkelbachjan]

• FIXME
• CHECK
• TODO
• DEPRECATED
• THISISBAD

[JTS22]

I started working on FIXMEs in #142

Comments on the non-solved FIXMEs:

[JTS22]

dpsim/dpsim-models/src/DP/DP_Ph1_VoltageSourceRamp.cpp

Lines 66 to 67 in 0a9d00c

	/// FIXME: Can we avoid setting right_vector to dynamic?
	mRightVector->setReference(mSubVoltageSource->mRightVector);

dpsim/dpsim-models/src/EMT/EMT_Ph1_VoltageSourceRamp.cpp

Lines 63 to 64 in 0a9d00c

	/// FIXME: Can we avoid setting right_vector to dynamic?
	mRightVector->setReference(mSubVoltageSource->mRightVector);

The VoltageSourceRamp should be superceded by the SignalGenerator in the normal VoltageSource. The classes above are only used in one example and not bound to Python, so they can probably be deleted. The issue comes up once more in the DP_Ph1_PQLoadCS:

dpsim/dpsim-models/src/DP/DP_Ph1_PQLoadCS.cpp

Lines 96 to 97 in 0a9d00c

	///CHECK: Can we avoid setting the right_vector attribute to dynamic? Maybe just copy the current source's right_vector somewhere? Or make a new attribute?
	mRightVector->setReference(mSubCurrentSource->mRightVector);

I dont know if this class is still needed as it is also not bound to Python. Even if there is probably a way to get around setting the right_vector to dynamic. Since the class implements mnaApplyRightSideVectorStamp I do not know whether the mRightVector is even read at all...

[JTS22]

dpsim/dpsim/src/MNASolver.cpp

Lines 40 to 52 in 0a9d00c

	///FIXME: This is kinda ugly... At least we should somehow unify mLeftSideVector and mLeftSideVectorHarm.
	// Best case we have some kind of sub-attributes for attribute vectors / tensor attributes...
	if (mFrequencyParallel) {
	mSLog->info("Computing network harmonics in parallel.");
	for(Int freq = 0; freq < mSystem.mFrequencies.size(); ++freq) {
	mLeftSideVectorHarm.push_back(
	CPS::Attribute<Matrix>::create("left_vector_"+std::to_string(freq), mAttributes)
	);
	}
	}
	else {
	mLeftSideVector = CPS::Attribute<Matrix>::create("left_vector", mAttributes);
	}

This is probably harder to solve because one needs to rework the MNA Solver for parallel frequencies (if that is even a working usecase right now)

[JTS22]

dpsim/dpsim-models/include/dpsim-models/Signal/DecouplingLine.h

Lines 49 to 50 in 0a9d00c

	///FIXME: workaround for dependency analysis as long as the states aren't attributes
	const Attribute<Matrix>::Ptr mStates;

dpsim/dpsim-models/include/dpsim-models/Signal/DecouplingLineEMT.h

Lines 49 to 50 in 0a9d00c

	///FIXME: workaround for dependency analysis as long as the states aren't attributes
	const Attribute<Matrix>::Ptr mStates;

I dont know what states this is talking about. The Matrix attribute itself is only used as a task dependency but never read or written to...

[JTS22]

dpsim/dpsim-models/src/DP/DP_Ph1_ResIndSeries.cpp

Lines 16 to 17 in 0a9d00c

	///FIXME: The resistance is never used anywhere...
	mResistance(Attribute<Real>::create("R", mAttributes)) {

Removing the R attribute seems to go against the purpose of the class. But then again, the class is never used / not even compiled so maybe we can just delete it altogether?

[JTS22]

dpsim/examples/Notebooks/Components/Trafo.ipynb

Lines 69 to 71 in 0a9d00c

	"trafo_snubber_res_hv_side = dpsimpy.sp.ph1.Resistor('trafo_snub_res_mv') ##FIXME: Is the naming correct here?\n",
	"trafo_snubber_res_mv_side = dpsimpy.sp.ph1.Resistor('trafo_snub_res_hv')\n",
	"trafo_snubber_cap_mv_side = dpsimpy.sp.ph1.Capacitor('trafo_snub_cap_mv')\n",

I cannot comment on this, should be easy to resolve though.

[JTS22]

dpsim/examples/Notebooks/Components/SynGenDq7od_ParameterStudy.ipynb

Line 454 in 0a9d00c

"# FIXME: Requested log files are not generated by the simulation\n",

The notebook does not even run the simulation to completion, so this seems like a secondary issue...

[JTS22]

dpsim/examples/Notebooks/Components/SynGen_trStab.ipynb

Line 35 in 0a9d00c

"# FIXME: Why does this have to run in a seperate function for the simulation to produce the Left- and RightVector log files?\n",

I can confirm this is still an issue, there is even an entire notebook for examination: https://github.com/sogno-platform/dpsim/blob/master/examples/Notebooks/Components/SynGen_trStab_logger_test.ipynb
The core issue remains unsolved though, probably something to do with the logger only writing out files when the object is deleted from memory...