feat: allow cross overs both in and out of the same compressor train … #709
Conversation
| if self.crossover is None: | ||
| return self | ||
| for index, crossover in enumerate(self.crossover): | ||
| if crossover >= max(self.crossover[: index + 1]) or crossover == 0: |
There was a problem hiding this comment.
| if crossover >= max(self.crossover[: index + 1]) or crossover == 0: | |
| if self.crossovers_exhausted(index, crossover) or self.has_no_crossovers(): |
or similar? more fluent and easier to read? too use more of those types of fluent typing/syntactic sugar?
olelod
force-pushed
the
feat/allow-cross-overs-both-in-and-out-of-a-compressor-train
branch
from
cf7be3f to
c75f830
Compare
…in a compressor system This can be done if it is made sure that the compressor trains in the compressor system are processed in the right order. You can only pass rates to a compressor train that has not been processed yet. Hence, the indexes in the list specifying the cross overs must be larger than the index of the compressor train where the cross over comes from (or zero, meaning no cross over).
olelod
force-pushed
the
feat/allow-cross-overs-both-in-and-out-of-a-compressor-train
branch
from
c75f830 to
5ce2f63
Compare
| f"Crossover: {self.crossover}\n" | ||
| "The compressor trains in the compressor system are not defined in the correct order, according to " | ||
| "the way the crossovers are set up. eCalc can now try to pass excess rates to compressor trains in " | ||
| "the system that has already been evaluated. \n\n" |
There was a problem hiding this comment.
Is this correct? Or should it be not evaluated?
There was a problem hiding this comment.
The way it works now if you have crossover: [0, 1, 0], you first evaluate the first consumer (here it has no crossover). The next consumers can pass excess rate to the first one, potentially exceeding the maximum rate there, and the operational setting will be chosen even if it is invalid.
There was a problem hiding this comment.
The sentence eCalc can now try to pass excess rates to compressor trains the system that has already been evaluated confused me. Is the intention to inform the user why the current crossover setting isn't allowed? So If we were to allow this crossover setup, eCalc™ could try to pass excess rates to compressor trains in the system that has already been evaluated?
There was a problem hiding this comment.
Poorly phrased, I guess... Yes, that was happening in one model. The first train is within capacity, the second one outside capacity, so rate was passed to the first one (which then with the additional rate was outside capacity).
| "To avoid loops and to avoid passing rates to compressor trains that have already been " | ||
| "processed, the index of the crossovers should be either 0 (no crossover) or larger than the index " | ||
| "of the current compressor train (passing excess rate to a compressor train not yet evaluated). \n\n" | ||
| "CROSSOVER: [2, 3, 0] is valid, but CROSSOVER: [2, 1, 0] is not. \n" |
There was a problem hiding this comment.
v2 does the sorting for the user, just sayin'
| f"Crossover: {self.crossover}\n" | ||
| "The compressor trains in the compressor system are not defined in the correct order, according to " | ||
| "the way the crossovers are set up. eCalc can now try to pass excess rates to compressor trains in " | ||
| "the system that has already been evaluated. \n\n" |
There was a problem hiding this comment.
The sentence eCalc can now try to pass excess rates to compressor trains the system that has already been evaluated confused me. Is the intention to inform the user why the current crossover setting isn't allowed? So If we were to allow this crossover setup, eCalc™ could try to pass excess rates to compressor trains in the system that has already been evaluated?
…in a compressor system
This can be done if it is made sure that the compressor trains in the compressor system are processed in the right order. You can only pass rates to a compressor train that has not been processed yet. Hence, the indexes in the list specifying the cross overs must be increasing (or zero, meaning no cross over).
Why is this pull request needed?
A case with a compressor system with three compressor trains (A, B, C). Send everything to A first, if it is too much pass the exceeding rate on to train B, if it is too much for train B also, pass the remaining rate on to train C.
Have you remembered and considered?
docs/drafts/next.draft.md)docs/docs/migration_guides/)BREAKING:in footer or!in header, if breakingECALC-XXXX)