CharL issueshttps://collaborating.tuhh.de/iet/CharL/-/issues2019-09-02T11:14:10+02:00https://collaborating.tuhh.de/iet/CharL/-/issues/6Further improvements of the object oriented approach2019-09-02T11:14:10+02:00Mathias AmmonFurther improvements of the object oriented approachFollowing the lead authors request the recommendation for reusing `Solar` and `CSP` classes were moved to this issue.:
> These classes were originally designed utilizing a strict object oriented paradigm. Using the Solar class as an enc...Following the lead authors request the recommendation for reusing `Solar` and `CSP` classes were moved to this issue.:
> These classes were originally designed utilizing a strict object oriented paradigm. Using the Solar class as an encapsulating class for holding separate classes for each subsystem respectively. Subsystem in the sense of logical grouping of algorithms involved to model power generation using a solar park ( as identified by the author) (i.e. solar position algorithm, irradiance algorithms, shading algorithms photovoltaic array, inverter and an electrochemical energy storage (optional)) or a power generation using a power tower ( again as identified by the author) (i.e. solar position algorithm, heliostat field, receiver tower, thermal energy storage and power cycle).
> Due to different opinions about how a modular, open source, easy to reuse implementation should look like, the original approach was dropped in favor of a flat implementation. The original class boundaries can still easily be identified by the component markers (`//Component`) and namings used. In case anyone wants to reuse the code written here, the author strongly encourages the developer(s) to reinstate a class of classes like behavior utilizing further abstraction while outsourcing any functionalities not necessary for calling Solar::iterate.
As stated in comments, this is of course just a personal recommendation for people reusing the classes in separate projects. This project has its own guidelines and thus the code was changed accordinglyhttps://collaborating.tuhh.de/iet/CharL/-/issues/5Implement Nodes in Optimisation Schedule2019-08-01T10:46:52+02:00Gerrit ErichsenImplement Nodes in Optimisation ScheduleThis is a four way process:
First: Refactor current PowerFlow code
Second: Actually Implement into Optimisation Schedule the missing equations
Third: Adapt set-definitions of everything else in OptimisationSchedule
Fourth: Feed results b...This is a four way process:
First: Refactor current PowerFlow code
Second: Actually Implement into Optimisation Schedule the missing equations
Third: Adapt set-definitions of everything else in OptimisationSchedule
Fourth: Feed results back to PowerFlowGerrit ErichsenGerrit Erichsenhttps://collaborating.tuhh.de/iet/CharL/-/issues/2correct correctFromStorage2019-06-07T13:35:56+02:00Gerrit Erichsencorrect correctFromStorageAt this point the function shows some weird behavior, when a runThrough is attemptedAt this point the function shows some weird behavior, when a runThrough is attemptedGerrit ErichsenGerrit Erichsen