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

Microoptimizations causing out-of-bounds writes #91

Closed
akva2 opened this issue Nov 13, 2013 · 6 comments
Closed

Microoptimizations causing out-of-bounds writes #91

akva2 opened this issue Nov 13, 2013 · 6 comments

Comments

@akva2
Copy link
Member

akva2 commented Nov 13, 2013

Some micro-optimalizations in opm-porsol are having unforseen consequences. To avoid reallocating cell-level entities for each cell, these entities are reused across cells with size according to the cell with the most DOFs attached.

the problem is that code further down the line assumes that these have the same size as the number of faces for a particular cell. for complex meshes, this is not a constant, and out of bounds writes is the consequence. in particular, the out of bounds writes happen in IncompFlowSolverHybrid.hpp, computePressureAndFluxes and buildCellContrib.

people are already on top of this (PR#89 was a first attempt), but i was asked to open this issue for tracking purposes, so here it is.

@bska
Copy link
Member

bska commented Nov 13, 2013

Thanks for starting this discussion. I have a candidate solution in my (new) fix-out-of-bounds-indexing branch at https://github.com/bska/opm-porsol. I think this solves the same issues as the previous PR #89, but additionally also solves the computePressureAndFluxes() problem.

Would you or anyone else care to test it?

@akva2
Copy link
Member Author

akva2 commented Nov 14, 2013

seems to do the job just fine.

@bska
Copy link
Member

bska commented Nov 14, 2013

seems to do the job just fine.

Thanks for testing. PR #92 contains the solution.

@bska
Copy link
Member

bska commented Nov 14, 2013

PR #92 was merged into master. I take it this issue can be closed?

@akva2 akva2 closed this as completed Nov 15, 2013
@akva2
Copy link
Member Author

akva2 commented Nov 15, 2013

indeed. thanks for your work on this

@bska
Copy link
Member

bska commented Nov 15, 2013

indeed [this issue can be closed]

Thanks. I was honestly hoping issue 91 would be closed automatically by GitHub upon merging #92, but it seems I used the wrong command word (https://help.github.com/articles/closing-issues-via-commit-messages).

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

No branches or pull requests

2 participants