-
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
Props norm #597
Props norm #597
Conversation
- properties at norm state
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #597 +/- ##
===========================================
+ Coverage 90.49% 90.84% +0.35%
===========================================
Files 139 139
Lines 10549 10996 +447
===========================================
+ Hits 9546 9989 +443
- Misses 1003 1007 +4 ☔ View full report in Codecov by Sentry. |
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.
Wow, great to see how the differences between the pandapipes and the stanet results vanish here. A few thoughts:
- How can we ensure that the formulations that we use are correct? I see that you changed a lot of the structure of the derivative calculation, I might have to work through it once more.
- I think we should also test performance and the number of iterations to convergence in both approaches (v vs. m).
- Renaming m to mf might help to clarify the meaning of this variable (MFINIT).
Otherwise just a few small comments. I will think about the aspect of calling a property with just a float for another while... don't know if it should be allowed or not.
Otherwise just a few small comments. I will think about the aspect of calling a property with just a float for another while... don't know if it should be allowed or not.
|
I am very happy with MDOTINIT. I just thought that we should have something different than MINIT and came up with MF for mass flow. Regarding the number of iterations: In many cases, the number of iterations increases if we use bad derivatives. In some cases, the NR might not even converge. Therefore an increased number of iterations is always a hint for errors in the derivative implementation. So I will double check these formulations. And having this information from the tests would be very helpful. Maybe it's even best if we do a test that ensures that a certain number of iterations for a given setup is not exceeded. It should not depend on the working environment. If this number is exceeded, the test fails and we know that we have to address this issue. |
I changed it now from MINIT to MDOTINIT! |
- decreasing the default tolerance
@dlohmeier, did you come up with a solution for calling a property with just a float? |
…egative derivation in build_system_matrix.py
- remove unnecessary np.abs
…ing the pipeflow (especially relevant for the bidirectional pipeflow)
# Conflicts: # src/pandapipes/component_models/abstract_models/branch_w_internals_models.py # src/pandapipes/component_models/pipe_component.py # src/pandapipes/idx_branch.py # src/pandapipes/pf/build_system_matrix.py # src/pandapipes/pf/derivative_calculation.py
…r is general specification, however, is overwritten by max_iter_hyd and max_iter_therm if given.
# Conflicts: # src/pandapipes/component_models/heat_exchanger_component.py
No description provided.