Strict_L_Conservation logical bug fix #364
Conversation
|
Just a note to @tukss -- this is ready for review now. I fixed my logic issue. |
feathern
changed the title
|
Small comment on this. I also modified a line related to one of Ryan's PR in the changelog. That was filed as an addition, but it was really a bug fix. |
|
I've just tried it out and the logic works here, showing the expected result in Just a semantic remark: The message we send to the user is called |
|
I will change to 'Warning.' That occurred to me as well. Also, I just pulled an update from master, then repushed my changes. Hopefully taht will force the new conda environment to be used. The tests appeared to be failing for the same reason before I did that. We'll see how this goes. |
Changed 'Error" to "Warning"
|
@tukss OK, the checks just passed, and then I changed the wording. Assuming these checks pass, I think you're good to merge/approve. Only thing I could imagine is that I goofed a quotation mark. |
| stress_free_bottom = .not. no_slip_bottom | ||
|
|
||
|
|
There was a problem hiding this comment.
I think these blank lines were added by accident.
|
Other than the blank lines it looks good to me. I'll approve already. Feel free to merge having removed the lines or not. |
This small PR fixes a bug that allowed Strict_L_Conservation to be set to True when no_slip_boundaries or no_slip_top were also set to True. Physically, this flag is inconsistent with no_slip_boundaries. Numerically, it overrides the no_slip_top boundary condition, so is also incompatible with that BC. Note that Strict_L_Conservation IS compatible with no_slip_bottom, though that use case would be rare.
Through this bug fix, no_slip_boundaries and no_slip_top take precedence over Strict_L_Conservation. A warning message indicating that this is happening is produced if a conflict is detected at runtime.