Repository navigation
Conversation
link_res(l) intersects the resources of the two nodes of a link and was evaluated for every operational period (index sets of link_in/link_out, the coupling condition, link constraints); link_sub filtered all links for every node. While create_model runs, both are now computed once and then taken from a cache local to the task, which exists only during create_model, so a later model sees changed nodes. No change to the API or to any caller. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
JulStraus
left a comment
JulStraus
left a comment
There was a problem hiding this comment.
Just two clarification comments. I think we have to improve on the description. Regarding the caching: I would prefer if the current lines 58-72 are at the end of the file. That makes the understanding easier.
| # period. The cache is local to the task building the model and exists only while | ||
| # `create_model` runs, so a later model sees changed nodes and links. The cached |
There was a problem hiding this comment.
I do not see the reason for that. Does that imply we change the case file or is the constant _LINK_CACHE not cleared after the model is created? That is also a comment for the test where we see CO2 as a resource.
Thinking about it, I think the wording is confusing: It essentially says that if we have a changed case, we have a changed model, and hence, the new cached items. I think the wording should be improved.
|
|
||
| # Outside `create_model`, there is no cache: the resources are computed anew | ||
| @test isnothing(EMB._link_cache()) | ||
| @test EMB.link_res(l) !== EMB.link_res(l) |
There was a problem hiding this comment.
The explanation for this behavior is not clear to me. I can see that the vector could be different, but the resources should remain with the same instance? Otherwise we would have problems.
What would be the result of issetequal?
This is the other alternative to #110 (and #111). This version is without adding further dependencies.
Pros:
Cons: