Skip to content
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

Level global cell for CpGrid with LGRs #762

Merged
merged 8 commits into from
Oct 1, 2024
Merged

Conversation

aritorto
Copy link
Member

@aritorto aritorto commented Sep 25, 2024

This PR is relevant for including wells on LGRs (CpGrid). Potentially relevant for output files too.

For CpGrid with LGRs, we determine the global_cell_ values for refined level grids.
If an LGR has NX * NY * NZ dimension (amount of cells in each direction x,y,z respectively), then each refined cell can be associated with a (local) IJK and its (local) Cartesian index.
For a leaf grid view, we assign the global_cell_ values of either the parent cell or the equivalent cell from level zero.

Not relevant for the Reference Manual.

@aritorto
Copy link
Member Author

jenkins build this please

@aritorto
Copy link
Member Author

jenkins build this please

@aritorto aritorto force-pushed the globalCellLgr branch 2 times, most recently from 9ba2308 to f1f25d0 Compare September 26, 2024 12:46
@aritorto
Copy link
Member Author

jenkins build this please

@aritorto aritorto changed the title Modify global_cell_ for lgrs Local Cartesian Indices for LGRs Sep 26, 2024
@aritorto
Copy link
Member Author

@blattms maps for global cell from level grids and the leaf index set have been added. Could you take a look?

@bska do you think these changes - apart from potential use for wells location on LGRs - are also relevant for including LGRs in output files?

@aritorto aritorto changed the title Local Cartesian Indices for LGRs Level global cell for CpGrid with LGRs Sep 27, 2024
@blattms
Copy link
Member

blattms commented Sep 27, 2024

If we refine without LGRs, what size and values does globalCell have for the levels?

Copy link
Member

@blattms blattms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.
Just a few suggestions for better code reuse.

There are also comments on checks that won't hold if there are inactive cells. Maybe that is tested elsewhere and irrelevant?

opm/grid/cpgrid/CartesianIndexMapper.hpp Outdated Show resolved Hide resolved
opm/grid/cpgrid/CpGrid.cpp Show resolved Hide resolved
Comment on lines 653 to 660
std::array<int,3> childIJK = {0,0,0};

childIJK[0] = idx_in_parent_cell % cells_per_dim[0];
idx_in_parent_cell -= childIJK[0]; // k*cells_per_dim[0]*cells_per_dim[1] + j*cells_per_dim[0]
idx_in_parent_cell /= cells_per_dim[0]; // k*cells_per_dim[1] + j
childIJK[1] = idx_in_parent_cell % cells_per_dim[1];
idx_in_parent_cell -= childIJK[1]; // k*cells_per_dim[1]
childIJK[2] = idx_in_parent_cell /cells_per_dim[1];
Copy link
Member

@blattms blattms Sep 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Such computations are done a lot. It might be good to refactor them out to a separate function and reuse it elsewhere (e.g. CpGridData::getIJK)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now in CpGridData::getInParentCellIJK()

opm/grid/cpgrid/CpGrid.cpp Show resolved Hide resolved
opm/grid/cpgrid/CpGridData.cpp Outdated Show resolved Hide resolved
Comment on lines 211 to 214
auto itMin = std::min_element((data.back() -> global_cell_).begin(), (data.back()-> global_cell_).end());
auto itMax = std::max_element((data.back() -> global_cell_).begin(), (data.back() -> global_cell_).end());
BOOST_CHECK_EQUAL( *itMin, 0);
BOOST_CHECK_EQUAL( *itMax, data.front()-> size(0) -1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe change this test to work also for grid with inactive cells?
You could check that each value is between zero and the maximum cartesian index possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are checks in opm-grid/tests/cpgrid/inactiveCells_lgr_test.cpp, e.g. here. However, #761 intends to remove all the implementation details, in particular the previous check.

In this case, we can replace data.front()-> size(0)-1 by grid.logicalCartesianSize()[0]...[1]....*[2]

Comment on lines 377 to 380
auto itMinLevel = std::min_element((data[level] -> global_cell_).begin(), (data[level] -> global_cell_).end());
auto itMaxLevel = std::max_element((data[level] -> global_cell_).begin(), (data[level] -> global_cell_).end());
BOOST_CHECK_EQUAL( *itMinLevel, 0);
BOOST_CHECK_EQUAL( *itMaxLevel, data[level]-> size(0) -1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here and below. There could be inactive parent cells in the region to refine and hence missing kids (in the future?).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now the check is done with inequalities, meaning that the maximum value of global cell should be between 0 and the maximum Cartesian Index (the later might vary for each LGR, and it's equal to the maximum Cartesian Index from level zero for the leaf grid view)

@aritorto
Copy link
Member Author

aritorto commented Sep 30, 2024

If we refine without LGRs, what size and values does globalCell have for the levels?

Good point. I didn't comment on that in the PR description.

When we refine without LGRs, the size of global_cell_ coincides with the total amount of cells on the level grid/leaf grid view. For refined level grids, the values are 0,1,2,..., total amount of cells in that refined level grid.

For the leaf grid view, both refine-methods (with or without LGRs) do exactly the same: <leaf_grid_view>.global_cell_[ leaf cell index ] = global_cell_ value of the oldest ancestor from level zero.

One idea to make these two refine-approaches compatible is to detect minimum and maximums ijk values of marked cells, and mimic what's done for LGRs in the without-LGRs refinement, with these "fake startIJK and endIJK"

@blattms
Copy link
Member

blattms commented Sep 30, 2024

One idea to make these two refine-approaches compatible is to detect minimum and maximums ijk values of marked cells, and mimic what's done for LGRs in the without-LGRs refinement, with these "fake startIJK and endIJK"

I don't think we should make them compatible as they are not. cartesian indices on the level only makes sense for LGRs. In the long term we should probably throw if useers use them in adaptively refined grids. Let's postpone this, though,

@aritorto
Copy link
Member Author

There are also comments on checks that won't hold if there are inactive cells. Maybe that is tested elsewhere and irrelevant?

Now there are a few lines in inactiveCell_test.cpp checking that the max value of global cell is below the max Cartesian Index for level grids, and for the leaf (which corresponds to the max Cartesian Index value of level zero grid)

@aritorto
Copy link
Member Author

jenkins build this please

@aritorto
Copy link
Member Author

@blattms thanks for your feedback! (which is now incorporated)

/// (total amount of children of a parent cell minus one since starting index is zero).
/// @param [in] cells_per_dim
/// @param [out] ijk In-parent-cell Cartesian index triplet
void getInParentCellIJK(int idx_in_parent_cell, const std::array<int,3>& cells_per_dim, std::array<int,3>& ijk) const
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this much more general than the name and the documentation suggests? It seems to convert a cartesian index to ijk and has no relation to refinement. You just happen to use it during refinement, currently. Why not simply name it getIJK?

In addition we could just return the ijk directly and only have two parameters.
Then you can do this in line 306: ijk = getIK(c, logical_cartesian_size_); and that method is done.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds doable. I kept both methods since CpGrid::getIJK uses current_view_data_ ->getIJK (which is CpGridData::getIJK), and the integer argument "c" then it's used to get global_cell_[c] and then with this new integer, the "usual repeated deduction of ijk is done"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably your comment combined with ijk = getIJK(global_cell_[c], logical_cartesian_size_)

@aritorto
Copy link
Member Author

aritorto commented Oct 1, 2024

jenkins build this please

@blattms blattms merged commit 057de17 into OPM:master Oct 1, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants