More robust open boundaries II
Codecov Report
:x: Patch coverage is 32.00000% with 17 lines in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 89.42%. Comparing base (4a2810a) to head (663a18a).
| Files with missing lines | Patch % | Lines |
|---|---|---|
| src/schemes/boundary/open_boundary/system.jl | 32.00% | 17 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #998 +/- ##
==========================================
- Coverage 89.59% 89.42% -0.17%
==========================================
Files 120 120
Lines 8579 8603 +24
==========================================
+ Hits 7686 7693 +7
- Misses 893 910 +17
| Flag | Coverage Δ | |
|---|---|---|
| total | 89.44% <34.78%> (-0.15%) |
:arrow_down: |
| unit | 64.65% <8.00%> (-0.17%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
I am not sure deleting is the best solution here. So you argue that the particle experience too much shifting? Or not enough shifting? Or that the distribution is deficient and then upon entering the shifting zone it experience too much shifting?
Yes, the latter. It only occurs with shifting. The particles will not be deleted but deactivated (so the particle is not "lost").
One could consider whether ramping the shifting would be beneficial here. However, this would require a longer boundary zone and would also increase complexity. We would need to examine more closely how the particle distribution behaves with ramped shifting. In my opinion, all this is a bit too much for a very rare edge case. As I said, it happens once in several thousand time steps. Furthermore, it shouldn't happen at all with a clean inlet. I only chose this example to provoke the case.
One could consider whether ramping the shifting would be beneficial here.
I implemented my suggestion in #1011 and it is very promising