Fixed bug related to matching perforations to reservoir elements #1206
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes a bug related to matching perforations to reservoir elements in the well code.
In the previous approach, I was using the location of the previous perforation as an "initial guess" to find the reservoir element containing the next perforation along the wellbore. This approach does not work well when the perforations are far from each other, or when the mesh is too fine, and as a result the algorithm cannot match the perforations to any reservoir element. To circumvent this issue, I now use the location of the reservoir element that is the closest to the perforation as "initial guess".
I also made some well error messages less cryptic.
This reminds me that I should at some point improve the "geometry" part of the well code by computing the intersections of the well polyline with the reservoir elements to make this piece of code more efficient on large meshes.
Thanks @tang39 for reporting this problem (and for using the wells).