-
Notifications
You must be signed in to change notification settings - Fork 111
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
EclipseGrid Extented for LGR and Extended CARFIN Object to read and store parent's labels #4255
base: master
Are you sure you want to change the base?
Conversation
…ls returns the number of parent cells that were refined under the same label 3 - method parent_cellsIJK() return I J K lists of the elements parents elements refined
jenkins build this please |
Can someone please give me access to Jenkins? |
I don't have that power, but at least can run jenkins now :) I took a quick look and got the impression that we have a similar computation on opm-grid, but maybe it's necessary to have it here too. I'll take a deeper look next week! |
jenkins build this please |
Thank you, @aritorto ! |
… GLOBAL, and code is properly formated where needed
@akva2 thank you for your kind review. let me know if I got the alignment correct. |
yes, perfect. i have granted jenkins access. |
jenkins build this please |
hmm. try again please. |
jenkins build this please |
The content of the PR looks correct to me. I just wonder where we need to use this. Could you maybe give me a hint? If it's in a context where "the grid is not available", then it's perfect to have such methods (parent_cellsIJK(), and num_parent_cells()). Potentially, the analogous methods for refined cells would be needed too: num_refined_cells() is almost for free (NXxNYxNZ), refined_cellsIJK() require a tiny computation involving NX, NY, NZ, and the dimension of the block of parent cells (I2-I1, J2-J1, K2-K1). If that's not the case ("the grid is available"), you can get these values through the grid's CartesianMapperIndexm or more general, LevelCartesianMapper (pending review/marge OPM/opm-grid#765 OPM/opm-grid#766 OPM/opm-simulators#5633 OPM/opm-simulators#5649) |
@aritorto I am devising an extension to the EclipseGrid object that will treat and store the LGR refined cells hierarchically. The endgame here is to extend the |
Thanks for the explanation @arturcastiel. I look forward to the coming draft PR! |
- Introduced `EclipseGridLGR` class, derived from `EclipseGrid` - Implemented a hierarchy to represent LGR cells within the EclipseGrid structure - Improved organization and maintainability of the grid representation
this was supposed to be a draft to my local repository. for some reason I do not understand it got pushed to this PR. I will try to set the last commit as draft. |
…current level and refine lgr cells
…iveIndex uses children method instead of the father
…fixed. assert method to verify if LGR cell IJK represented is in inative cell
jenkins build this please |
I've left some minor comments, but I will need more time to complete a detailed review. Thank you! |
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.
Mostly cosmetics but also a few code pattern questions.
…rotected, unecessary saveguard removed
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 haven't finished yet. I left a few more comments. Brief documentation would be very appreciated and might speed up the review process. Thanks!
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.
A few more comments/questions
{ | ||
init_father_global(); | ||
lgr_label= self_label; | ||
lgr_level = father_lgr_level + 1 ; |
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 might not be a problem for now, but... Dune's Grid interface follows this scheme where children of a cell ive in "parent cell level +1". However, currently, for CpGrid, "LGR1" is stored in level 1, "LGR2" stored in level 2 and so on... even though all parent cells belong to level zero.
…IndexLGR renamed activeIndexLGR
CARFIN
reads and stores LGR parent namenum_parent_cells()
returns the number of parent cells that were refined under the same labelparent_cellsIJK()
return a tuple containing 3 listsI
,J
andK
lists of the elements parents' elements refined.EclipseGrid
Class has been extended to also describe LGR cells:LGR Children are a collection of objects of the
EclipseGridLGR
a class type derived fromEclipseGrid
that appends information required by the LGR method.EclipseGridLGR
may also have as children otherEclipseGridLGR
, i.e.,EclipseGrid
is compatible with Nested LGR.getActiveIndexLGR
maps fromLGR_Label
andI,J,K
onto the Comprised Index.LgrTests.cpp
test all these features.