-
Notifications
You must be signed in to change notification settings - Fork 112
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
Sutherlands Law for temperature dependent viscosity #1808
Conversation
Review checklistThis checklist is meant to assist creators of PRs (to let them know what reviewers will typically look for) and reviewers (to guide them in a structured review process). Items do not need to be checked explicitly for a PR to be eligible for merging. Purpose and scope
Code quality
Documentation
Testing
Performance
Verification
Created with ❤️ by the Trixi.jl community. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1808 +/- ##
==========================================
- Coverage 96.30% 93.07% -3.23%
==========================================
Files 440 441 +1
Lines 35793 35798 +5
==========================================
- Hits 34470 33317 -1153
- Misses 1323 2481 +1158
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
This looks good to me - I am only familiar with Sutherlands law though and not anything else more complex. |
Thanks for working on this! I haven't looked at your changes in detail yet, but I'm wondering if really a second set of equations is required or desirable. Would it also be possible to implement this as a equation-of-state-like property of the original NSE implementation? That is, make the viscosity type a type parameter of the NSE struct, or even just allow passing different I am worried about code duplication what I perceive (maybe wrongly) as an implementation detail in many other NSE codes I've seen. Maybe @andrewwinters5000 has a different take on this? |
That is a good idea, I will think about this. In principle, it should not be to difficult to pass in a function |
I would just pass the entire state such that the user can freely decide what to do with it.
If a function is defined that ignores it's input and just returns a constant value, it should in virtually all cases just be optimized away. A question remains though as to whether we can efficiently provide a convenience layer that auto-generates the constant function for a given numerical value of mu, such that a user may just pass the constant value and does not have to always wrap it in a function. |
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.
LGTM! This is a nice extension to the Navier-Stokes capabilities.
03c7c88
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.
Minor formatting change, then LGTM!
Co-authored-by: Michael Schlottke-Lakemper <[email protected]>
…nto SutherlandsLaw
It would be really nice if this gets merged sometime soon as I am currently working on the computation of drag & lift due to viscous terms (following up on #1812) for which the viscosity |
@andrewwinters5000 OK to merge? @DanielDoehring I only checked a few of the CI failures - they look spurious. Did you see any actual failing tests? |
@jlchan No, not except for codecov to fail. |
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.
@jlchan Yes, everything looks good to me.
Great, then unless someone objects, I'm ok with force merging this. Do I need to disable auto-merge to do so? |
Yes, you need to disable auto-merge. Then there will be an override option |
Thanks @jlchan ! |
Closes #1195