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

Get xyz from vertices in LGRs and 8-corners-of-refined-cells #792

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

aritorto
Copy link
Member

@aritorto aritorto commented Nov 5, 2024

This PR aims to contribute to the generation of output files for simulations involving Corner Point Grids (CpGrid) with Local Grid Refinement (LGR). It demonstrates how to extract the necessary values for defining COORD and ZCORN in CpGrids with LGRs. Note that the ordering presented here does not follow the "pillars" construction. To correctly output COORD and ZCORN, a reordering step must be implemented.

Not relevant for the Reference Manual.

This commit translates one of the test cases from OPM/opm-common#4255 using the grid interface.

@aritorto aritorto marked this pull request as draft November 5, 2024 12:11
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 great (from a short glimpse).

//
std::vector<std::vector<std::array<double,3>>> xyz_for_zcorn(grid.currentData()[level]->size(0)); // size total amount of cells in the level refined grid.
for (const auto& element : elements(grid.levelGridView(level))) {
xyz_for_zcorn[element.index()].reserve(8);
Copy link
Member

Choose a reason for hiding this comment

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

Maybe also get the local global index. Similar to above. That together with the order you documented above will be all the information needed.

Copy link
Member Author

Choose a reason for hiding this comment

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

I will add that here then. Thanks for your feedback!

Comment on lines +172 to +178
// Expected values in each LGR: 8*refined_cells_in_that_lgr
// Each refined cell has its 8 corners stored in <refined_level_grid>.cell_to_point_[ refined element index ]
// in the following order:
// BOTTOM FACE TOP FACE
// 2 --- 3 6 --- 7
// / / / /
// 0 --- 1 4 --- 5
Copy link
Member

Choose a reason for hiding this comment

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

It typically does not matter, but for what it's worth, the default coordinate system is right-handed with the origin in the upper, left, back corner and Z axis pointing down. In other words, the typical node ordering is as outlined in the picture in MRST's processGRDECL function.

Copy link
Member Author

Choose a reason for hiding this comment

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

I see, in the grid, we follow the described ordering. Therefore, for output, we need to re-order them according to your description. Thanks for your feedback!

Copy link
Member

Choose a reason for hiding this comment

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

Therefore, for output, we need to re-order them according to your description.

Sorry for being too brief: It's not that we need to do anything in particular to the order–it's actually the same in both views–it's just that in terms of labelling the top face is normally comprised of vertices 0..3 while the bottom face normally comprises vertices 4..7.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for clarifying! I added your comment into the documentation.

@aritorto aritorto marked this pull request as ready for review November 6, 2024 12:26
@aritorto
Copy link
Member Author

aritorto commented Nov 6, 2024

Printed values: coord_zcorn.log

@aritorto
Copy link
Member Author

aritorto commented Nov 6, 2024

I will run Jenkins and leave the decision to merge this PR up to you (@blattms, @bska), as it is more illustrative than testing actual features.

@aritorto
Copy link
Member Author

aritorto commented Nov 6, 2024

jenkins build this please

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.

3 participants