Skip to content
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

add friction model "Hofer" #683

Open
wants to merge 7 commits into
base: develop
Choose a base branch
from
Open

Conversation

jkisse
Copy link
Collaborator

@jkisse jkisse commented Jan 6, 2025

The friction factor "Hofer" is introduced. It is an explicit implementation of Colebrook, used by some established Gas Grid Simulation tools.
Please refer to the added paragraph in the docs for more details.

@jkisse jkisse requested review from dlohmeier and kbensafta January 6, 2025 18:08
@jkisse jkisse changed the title add documentation for Hofer, add transition area approach add friction model "Hofer" Jan 7, 2025
@dlohmeier
Copy link
Collaborator

Looks interesting. I just thought that the transition area is relevant for different models. Maybe we should think about how to correct equations for laminar / turbulent flow. I think there is an issue on this topic and this implementation could be a nice approach.

dlohmeier
dlohmeier previously approved these changes Jan 7, 2025
@jkisse
Copy link
Collaborator Author

jkisse commented Jan 8, 2025

Thanks @dlohmeier!
I'd also appreciate your opinion on the usage of np.divide etc. in numba functions, e.g. here. It seems to me as if the advantage of array-processing cannot be used in the for-loops, thus it might be slightly more efficient to use the native "/" directly instead of np.divide? Did you investigate that a bit when you implemented the numba-functions?

(analogously for np.abs and np.power)

@dlohmeier
Copy link
Collaborator

As far as I can recall, numba was good at exactly this: identify numpy code within jit-decorated functions and compile them correctly. I always found it more readable and wrt. timings I remember that I found no difference or a slight advantage of the numpy ufuncs over native code. It might have changed with newer numba versions.

(:math:`Re < \underline{Re}`) and :math:`\lambda_H` is used for high Reynolds numbers (:math:`Re > \overline{Re}`).
In the transition area :math:`\underline{Re} \leq Re \leq \overline{Re}`, :math:`\lambda_H` is interpolated linearly.
By default, the boundaries of this transition area are set to :math:`\underline{Re}=2000` and :math:`\overline{Re}=3000`.
Note that the derivative used for Hofer is the same as for Prandtl-Colebrook.
Copy link
Contributor

@kbensafta kbensafta Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the PC-derivative indeed applicable in this case or is it an approximation, since Hofer is just an explicit form of Prandtl-Colebrook?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure - I found it acceptable, also because of the quite complicated derivative of the Hofer formula. Apparently it is working ; )
Maybe the convergence behaviour could be strengthened if a separate "Hofer-derivative" is implemented, but I find it sufficient so far.

@jkisse
Copy link
Collaborator Author

jkisse commented Jan 15, 2025

We found out that max_iter has been renamed rather silently a year ago, thus I'd like to use this PR to add a warning for those who still use it.

When calculating large transmissions grids, we often need more than 10 iterations. Therefore, I'd appreciate it if we could set it to 30 by default. It shouldn't have any significant effects on the runtime.

@dlohmeier
Copy link
Collaborator

We found out that max_iter has been renamed rather silently a year ago, thus I'd like to use this PR to add a warning for those who still use it.

When calculating large transmissions grids, we often need more than 10 iterations. Therefore, I'd appreciate it if we could set it to 30 by default. It shouldn't have any significant effects on the runtime.

Increasing the default number of iterations is indeed necessary in quite some calculation scenarios for us, so I would welcome that change. Wrt. the max_iter kwarg, I am a little surprised, since I thought we really intended to make this change backwards compatible. A warning is indeed appropriate then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants