-
Notifications
You must be signed in to change notification settings - Fork 143
fix(spdis): add the no-flow cell boundary faces to the specific discharge calculation #2507
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
base: develop
Are you sure you want to change the base?
Conversation
…into spdis-rework
- check spelling, style, etc.
| npoly = this%dis%get_npolyverts(n, closed=.false.) | ||
| this%nr_faces = npoly + 2 | ||
|
|
||
| ! horizontal faces |
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.
i.e., top and bottom
| this%n(:, 1) = (/DZERO, DZERO, DONE/) | ||
| this%anglex(1) = DNODATA | ||
| this%dist(1) = (this%dis%top(n) - this%dis%bot(n)) / 2.0_DP | ||
| this%n(:, 2) = (/DZERO, DZERO, -DONE/) |
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.
maybe rename this%n to avoid potential confusion with reduced node number n
| alpha = this%dis%con%anglex(isym) | ||
| end if | ||
|
|
||
| if (abs(alpha - this%anglex(iface)) < DSAME) then |
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.
perhaps this is the best we can do with the information that's (reasonably) available. but just noting that the geometric matching criterion appears to have two disadvantages. one is obviously that there's a threshold involved. such thresholds are used elsewhere in modflow, so it's not a huge deal, but all else being equal it would be nice not to use one here. the other is that it requires doing the geometry for all the faces, whereas i think in the end all we really want from this is the boundary faces. this has me wondering whether it might be possible to identify the boundary faces (at least among the internal faces considered in this loop) in a way that's conceptually similar to the way the Connections module builds a sparse matrix of connections in disv1dconnections_verts and vertexconnectl. if so, it would seemingly eliminate the two drawbacks i mentioned, since it would be based on connectivity, not geometry
| end if | ||
| ! match to (unmatched) faces | ||
| do iface = 3, this%nr_faces | ||
| if (abs(alpha - this%anglex(iface)) < DSAME) then |
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.
could something similar to what i proposed for the internal faces be done for the exchange edges? i realize it might be even harder, if not impossible, to get all the necessary information
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.
some comments ahead of our conversation tomorrow (9/17)
- fix: add vertical conns to max. connection count - and fix typo in uzf test
More documentation will have to follow.
Checklist of items for pull request
ruffon new and modified python scripts in .doc, autotests, doc, distribution, pymake, and utils subdirectories.fprettifyFor additional information see instructions for contributing and instructions for developing.