-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: handle requested pressures for compressor systems #215
chore: handle requested pressures for compressor systems #215
Conversation
709a82d
to
ddec1b9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we drop this and say requested pressures are good enough until v2? Wouldn't this cause confusion? If I understand it correctly this is not necessarily correct?
No problem for me. Maybe disable requested pressure plots for systems then. Right now e.g. |
Did you discuss this today? Should we just drop it for now? It just turns out to be "full of holes" because of all the different edge cases? |
@TeeeJay and @jsolaas : Discussed with @HeddaSvendsen, she reminded me of the Have checked the model (advanced model) that was used to flag the problem with zero requested inlet pressure, it now runs with expected output (for the requested pressures). |
53a9339
to
367915a
Compare
src/libecalc/core/graph_result.py
Outdated
@@ -215,50 +216,90 @@ def _parse_emissions(emissions: Dict[str, EmissionResult]) -> Dict[str, libecalc | |||
for key in emissions | |||
} | |||
|
|||
@staticmethod | |||
def get_operational_setting_index(timestep: datetime, operational_settings_used: TimeSeriesInt): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
def get_operational_setting_index(timestep: datetime, operational_settings_used: TimeSeriesInt): | |
def get_operational_setting_index(timestep: datetime, operational_settings_used: TimeSeriesInt) -> int: |
src/libecalc/core/graph_result.py
Outdated
def get_operational_setting_index(timestep: datetime, operational_settings_used: TimeSeriesInt): | ||
timestep_index = operational_settings_used.timesteps.index(timestep) | ||
|
||
operational_setting_index = operational_settings_used.values[timestep_index] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to use a different name. This is easily confused with the index in the list. How about operational_setting_used
? Or perhaps you have sth better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or Id?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like operational_setting_used
, as it refers to one entry in the in the time series operational_settings_used
, or?
This is getting overly complicated. Not your fault, it is just very difficult to get this good and right. I am afraid that we do not have enough overview of edge cases, where this will work and not etc, and whether the user can always trust the results? If we are to merge this, we should make sure that the code is isolated (doesnt break anything else), and possibly give a warning about this being experimental (using Feature.experimental, in case it fails?) which also gives a warning.... Also, we do not have any other tests than the standard tests to test this. What do you think? |
I agree that it is complicated, and difficult to control edge cases - with few tests really checking. On the other hand, the code that is already merged in is trying to handle the requested pressures for systems in a wrong way - and this will not make it worse I think. Is it an idea to create some targeted tests for this, especially for operational settings in compressor systems - and checking for different pressures for different compressors in the system etc.? |
I would say it is better to wrap with |
So, also, we need to patch it then... |
2ebc77b
to
c34e728
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
* chore: handle requested pressures for compressor systems (cherry picked from commit 6b05439)
* chore: handle requested pressures for compressor systems
Why is this pull request needed?
Extracting requested inlet- and outlet pressure does not work correctly for compressor systems:
When using
SUCTION_PRESSURES
orDISCHARGE_PRESSURES
there are one pressure per component in the system. This list of pressures is not captured and the pressures are set to nan, and then nan to num (0).What does this pull request change?
get_requested_compressor_pressures
ingraph_result
, to select correct pressures for compressors in systemIssues related to this change:
https://equinor-ecalc.atlassian.net/browse/ECALC-252?atlOrigin=eyJpIjoiYTJiZGUwNmY5MjlhNGMwMjg5YTc1Y2FiNTY0ZTkxNDQiLCJwIjoiaiJ9