Replace constraint tests #1080
Replace constraint tests #1080
Conversation
Adjust indexing to be same as for content of storage without investment.
For Python 3.10+, "|" should be used instead of "or", but or is also incorrect for Python 3.9 (a typing.Union can be used). However, as date is superclass of datetime, giving the superclass shuld imply that the childs are also possible.
BaseModel was an unused superclass just for Model. At the moment it is not planned to have other models. Thus, it makes sense to merge both. Signed-off-by: Patrik Schönfeldt <[email protected]>
It seems to be a desired (and tested) feature to do so, but a typical user will probably not want to do this. So, a warning makes sense.
The function "test_optimal_solution" didn't actually test anything, so I deleted it. The function "test_infeasible_model" now only tests for the infeasibility warning.
Argument "energysystem" to Model should not be a list anymore.
…ace-constraint-tests
The multi-period version is not tested, as both versions will probably be unified. (And multi-period is experimental anyway.)
|
As I did not want to write a test assuring wrong results, I merged |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
The remaining missing test coverage of the |
As the experimental multi-period code (hugely untested and to be refactored) counts for the coverage, lowering it should be in order.
|
Codacy complains because I have slightly changed the signature of a complex function: It says that I introduced a complex function. (In fact, I slightly reduced the complexity by the change.) |
I agree that it makes sense to exclude discounting. In general, this should be harmonized across all cost types, but I think since this is a rather rare, probably unused use case here, I think it is safe to remove it here. |
There was a problem hiding this comment.
Dear @p-snft,
thanks for this pull request and the very good effort that I highly appreciate. I left a lot of comments, but most of them are rather editorial remarks and/or questions of understanding that should be easy to address. I also like the new test framework and the examples you created, esp. concerning the non convex flow constraints that were rather untested before (though officially covered). Thus, I am happy to approve the pull request.
Nonetheless, I'd like to raise two points. I don't see them as critical, but rather want to raise awareness:
- It seems to me that not yet all of the constraints are tested one by one as they actually should. I didn't find an explicit test for bus balance constraints or the converter efficiencies for instance. These were at least implicity contained in the tests before, because at least I also checked these when comparing the LP files.
- Some experimental components did have testing before, but now they don't have it anymore.
I think it is legitimate to proceed since I do not want to interfere with your development agenda, but rather raise awareness for this issues. I think both aspects can be covered in dedicated pull requests.
Once again, many thanks for the great effort. Besides vastly improving maintainability, in my view also a further improvement in code quality.
src/oemof/solph/_helpers.py
Outdated
| """ | ||
| if number is None: | ||
| if calendar.isleap(year): | ||
| hoy = 8784 |
There was a problem hiding this comment.
Though it has just been moved, I suggest to rename to the more speaking hours_of_year instead of the abbreviation hoy.
|
|
||
| if reference_bus in oc_outputs: | ||
| f = oc_outputs[reference_bus] | ||
| get_slope_and_offset = slope_offset_from_nonconvex_output |
There was a problem hiding this comment.
I did not understand this function reference in the first place. Is there any counter argument against renaming the function in the _offset_converter module where it is imported from?
| flow = solph.flows.Flow( | ||
| nominal_value=10, | ||
| min=0.1, | ||
| max=[i * 0.1 for i in range(10)], |
There was a problem hiding this comment.
I think, the range object should be redefined to start with 0.1. A max value below a min value is generally indicative for a modelling error in my view.
There was a problem hiding this comment.
This enforces the flow to be inactive. But you are right, this is not what we wanted. I'd suggest to have an input validation that minimum <= maximum.
| solph.constraints.generic_integral_limit( | ||
| model, | ||
| "my_factor", | ||
| limit_name="limit_my_factor", | ||
| limit=low_emission_flow_limit, | ||
| ) |
There was a problem hiding this comment.
There is no equivalent thing for the high_emission_flow_limit.
| nominal_value=2, | ||
| min=0.5, | ||
| nonconvex=solph.NonConvex(), | ||
| custom_attributes={"keyword1": "also group 1"}, |
There was a problem hiding this comment.
Yeah, I also like the sense of humor, but suggest to use "group 1" as the value.
There was a problem hiding this comment.
I want to make the point that the value is not relevant, here.
Replaces lp diff constraint tests by granular unit tests for functionality.
Reasoning:
I would suggest to have unit tests that