EclipseGrid Extented for LGR and Extended CARFIN Object to read and store parent's labels #4255
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! |
arturcastiel
changed the title
…rotected, unecessary saveguard removed
| { | ||
| init_father_global(); | ||
| lgr_label= self_label; | ||
| lgr_level = father_lgr_level + 1 ; |
There was a problem hiding this comment.
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
CARFINreads 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,JandKlists of the elements parents' elements refined.EclipseGridClass has been extended to also describe LGR cells:LGR Children are a collection of objects of the
EclipseGridLGRa class type derived fromEclipseGridthat appends information required by the LGR method.EclipseGridLGRmay also have as children otherEclipseGridLGR, i.e.,EclipseGridis compatible with Nested LGR.getActiveIndexLGRmaps fromLGR_LabelandI,J,Konto the Comprised Index.LgrTests.cpptest all these features.