-
Notifications
You must be signed in to change notification settings - Fork 63
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
Small correction in heat consumer for mode MF_TR #652
Conversation
…er anymore, but calculated based on an exact estimate of qext from inlet and controlled return temperature
Dear @dlohmeier, I'm currently exploring the new return temperature control feature for heat_consumer, introduced in v0.11. Previously, I utilized a custom controller to adjust the controlled_mass_flow in heat_consumer based on a given output temperature. Now, I’m transitioning to the new approach, but my calculations fail under certain configurations. I examined the provided functionality and corresponding tests in src/pandapipes/test/api/test_components/test_heat_consumer.py. While experimenting, I observed the following:
Below is a minimal example demonstrating the issue:
Observations: When both HeatConsumers are set to Thank you in advance for your clarification and any advice you can provide! |
Hi Jonas, I looked at your example and got it working. Two things I encountered here: Here is the code I used to make it work: def test_heat_consumer_result_extraction():
|
Hi Simon, Thank you very much for the quick help! The solution works perfectly for the simple test case. Building on this, I encountered a similar issue during time-series calculations, which might stem from the same underlying problem, but I’m not entirely sure how to handle it in this context. After verifying the simple network works, I returned to my more advanced network functions. The initialization and Previously, I handled this by setting a small minimum mass flow through the To illustrate the issue, here’s a chart showing this behavior (the chart is in German, but I think it’s clear enough). Heat demand and mass flow drop to zero, and the output temperature falls to 20 °C, which seems to be a default value when the heat_consumer is inactive (that 20 °C is the return joint to the circ_pump_const_pressure, which indicates that the whole net is 20 °C on the return line). However, in subsequent time steps, when I suspect that this default behavior (20 °C as a fallback temperature) may be the root cause here, but I couldn’t find the relevant part in the source code to confirm or modify this behavior. Do you have any suggestions for handling this corner case? For example:
Thank you again for your support! |
Hi Jonas, seems for me like a bug. However, without a code example, it is difficult to reproduce. Could you please provide an example. |
Hi Simon, I'd like to, but currently the net where the problem occurs is way to data dependent (based on geojson input and custom net creation functions). I'm trying to get an easier example (not) working, where the same issue occurs. While doing that, I can show an example for net data. My timeseries call looks like this:
I do not use In the first txt-file the results after a timeseries calculation are shown where all qext_w are >0 and no issue occurs. In the second file the results are shown for one time step later where some of the heat consumers have qext_w=0 which results in the calculation of NaN-Values in all connected junctions, but the calculation finishes. The problem starts to come up on the following time step when qext_w values would be higher again. I get the following output
Which results in It's not really surprising that it fails, as half of the values are NaN. In the other time step I described in the previous comment where all qext_w are zero, it looks basically the same, only that all values are NaN. Interestingly, when I test a small pipeflow calculation with one qext_w=0 value, which would look like the following, the values are also NaN for the heat consumer, but not NaN for the connected junctions. Also the Warning
So in conclusion the question would be why there are NaN values in the junction results in the timeseries calculation, when there are heat consumers with qext_w=0, which should result in an inactive heat consumer in that time step. Maybe this description might give you an idea at what I'm looking at, I'll try to get an easy to test example running. |
Got a "minimal" example running where the same issue occurs. The following code includes all helper functions and classes I'm currently using. In the test function 20 time steps are calculated. When setting one qext_value=0 in the first heat consumer (here in time step 8) The calculation fails in time step 9 with
The more important Information is coming from the output after time step 8:
In my understanding the nodes connected to the first heat_consumer are set out of service as the heat_consumer results in NaN-Values and as this are connection nodes to all other nodes this sets all other nodes out of service? What am I doing wrong?
|
the return temperature of the heat consumer is not fixed for the solver anymore, but calculated based on an exact estimate of qext from inlet and controlled return temperature