-
Notifications
You must be signed in to change notification settings - Fork 350
feat(lgr): add from_parent_grid classmethod to Lgr class #2668
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
Conversation
It's a bit verbose to manually pass all the parent grid props into the Lgr grid initializer, this makes it easier
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2668 +/- ##
===========================================
+ Coverage 55.5% 72.7% +17.1%
===========================================
Files 644 667 +23
Lines 124135 129538 +5403
===========================================
+ Hits 68947 94187 +25240
+ Misses 55188 35351 -19837
🚀 New features to boost your workflow:
|
|
@christianlangevin the main question I had for you is whether there is history to the |
christianlangevin
left a comment
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.
refine_mask makes sense to me because of the reason you mentioned. idomain may be needed to remove parts of the model grid, whereas refine_mask needs to remove/deactivate cells and mark where to refine. Nice change.
|
@christianlangevin do you mind giving this one last look? I tried to clarify the relationship between the refinement region and the resulting child grid idomain in the docstrings. |
christianlangevin
left a comment
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 added a little more description. Not sure if it helps. Feel free to add or jettison. I like the refinet_mask terminology. Keep in mind that this utility may be used repeatedly to create either a parent model with multiple child models or a parent model with a child model, and a grandchild model, etc. I don't recall if we have any tests or examples with this, but we have used it that way in the past.
| child grid will span a rectangular region that spans all idomain | ||
| cells with a value of zero. idomain must be of shape | ||
| (nlayp, nrowp, ncolp) | ||
| refine_mask : ndarray |
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.
This is good, @wpbonelli. Perhaps we can clarify even further.
Array indicating which parent cells to refine (shape: nlay, nrow, ncol). Cells with value 0 will be refined, with value 1 remain as parent cells. When a parent cell is marked to be refined, it will be deactivated in the parent model using the idomain functionality. The region of these refined parent cells will be represented by active cells in the child model. The child grid domain will span the rectangular region covering the zeros. This approach is designed so that a region is only represented by active cells in either the parent or child model grid.
Factored out of #2667
It's a bit verbose to manually pass all the parent grid props into the Lgr grid initializer, this makes it easier. I named the refinement region parameter
refine_maskas this seemed clearer thanidomainpas in the initializer. If others agree maybe worth a deprecation/name change in the initializer too?The original version in #2667 used the parent grid's idomain as the refinement mask, I was thinking because of the naming this might be justifiable, but decided it was better to keep them separate. Someone might want an inactive region to remain in the parent grid when the refinement is applied.