Feature/result dict wrapper #1195
Conversation
Compatibility is according to documentation and not fully tested.
To allow this esp. with detailed Components that feature custom variables, all data is treated as sequential if not stated otherwise.
|
This one revealed a problem we currently have: Multiple blocks (in particular In fact, we might not want to define the variables multiple times but have one set include the other. |
Do you mean |
|
For example, we have in NonConvexFlowBlock and oemof-solph/src/oemof/solph/flows/_invest_non_convex_flow_block.py Lines 100 to 102 in ab83844 InvestNonConvexFlowBlock (which is a child class of NonConvexFlowBlock).
|
|
Turns out that I misinterpreted as one Block as the child class of the other. We have the following situation:
Now, there are two possible ways:
In my opinion, way 2 is more versatile and easier to implement. Independent from this, I'd suggest to separate the Blocks so one is no longer the child of the other. (We can of course still reuse functions.) |
This is to make clear that NonConvexFlowBlock and InvestNonConvexFlowBlock are responsible for disjunct sets of Flows. Historically, NONCONVEX_FLOWS were not allowed to have an investment, but with INVEST_NON_CONVEX_FLOWS around, the name is now confusing. Thus, the set name NONCONVEX_FLOWS is replaced by FIXED_CAPACITY_NONCONVEX_FLOWS, which clearly complements INVEST_NON_CONVEX_FLOWS. Additionally, InvestNonConvexFlowBlock is no longer inheriting from NonConvexFlowBlock. Mistakenly assuming that NONCONVEX_FLOWS could have an investemnt, one might have expected that some things were done for all of these in NonConvexFlowBlock.__init__(). This, however was never the case. Both classes do not share data. To still avoid code duplicaton, re-usable methods in NonConvexFlowBlock are now staticmethods.
This reverts commit b69aed3.
Historically, NONCONVEX_FLOWS were not allowed to have an investment, but with INVEST_NON_CONVEX_FLOWS around, the name is now confusing. Thus, the set name NONCONVEX_FLOWS is replaced by FIXED_CAPACITY_NONCONVEX_FLOWS, which clearly complements INVEST_NON_CONVEX_FLOWS. However, there are sets in the flows with names that are present in both, NonConvecFlowBlock and InvestNonConvecFlowBlock (e.g. STARTUPFLOWS). Thus, it still makes sense to derive one class from the other.
The constrained ignored flows with a capacity investment.
As the Blocks are created uninitialised, they might not have the sets created. This then causes a crash. This works around this. (However, it was cleaner to create the sets on initialisation, if possible.)
I would also vote for 2 |
NaN values should no longer cause errors.
This changes the results object to be able to handle variables with the same name (present in different Blocks) as long as the indexes are disjunct. Analysis of the situation: * We have the convention that one Entity (Node or Flow) is only covered by one Block. * The status of a Flow is defined either in NonConvexFlowBlock or in InvestNonConvexFlowBlock. As the function _create(self, group=None) is not called by the Constructor, the variable exists only once per Flow.
|
I just implemented the approach in #1202. (It's a separate PR as it fixes a problem also present even if we do not merge this one.) |
This changes the results object to be able to handle variables with the same name (present in different Blocks) as long as the indexes are disjunct. Analysis of the situation: * We have the convention that one Entity (Node or Flow) is only covered by one Block. * The status of a Flow is defined either in NonConvexFlowBlock or in InvestNonConvexFlowBlock. As the function _create(self, group=None) is not called by the Constructor, the variable exists only once per Flow.
Allow local variable names for Results
|
What is now missing is just the support for experimental features (TSAM and multi-periods). |
This adds a drop-in replacement for
processing.resultsthat uses the newsolph.Resultsclass. It means to provide backwards compatibility while radically simplifying the processing code.